Use of <atom:published llup:release="..." llup:expires="...">...</atom:published>?

1 view
Skip to first unread message

M. David Peterson

unread,
Apr 22, 2007, 2:56:29 PM4/22/07
to llup
I've been thinking through how to best approach the time-span:start/stop aspect from an element/attribute usage perspective as it relates to the atom:published element.  As per section 4.2.9 of the specification,

4.2.9  The "atom:published" Element

The "atom:published" element is a Date construct indicating an instant in time associated with an event early in the life cycle of the entry.

atomPublished = element 
atom:published { atomDateConstruct}

Typically, atom:published will be associated with the initial creation or first availability of the resource.


Obviously using atom:published as an indicator of the "first availability of the resource." is completely acceptable, and as such, I have always considered using the value of this element to mark the moment the content should be made available as the proper approach.  That said, I am becoming increasingly convinced that to preserve the proper historical view of a message, using the atom:published element to mark the moment the content was first published and the subsequent blip message generated is the best overall usage of the atom:published element, and adding either an atom:published/@llup:release or atom:published/@llup:start as well as an atom:published/@llup:expires attribute would allow for a much cleaner and clearer approach to ensure there is never any confusion as to what atom:published truly represents.  One of the primary reasons I believe this could become a fairly significant problem is that if the atom:published date of the blip message can be different than the atom:published date of the related blip message, someone, somewhere along the way is going to get the two confused, and published time sensitive data too soon.  While it would be impossible to know all of the problems that could result from the early release of such time sensitive data, the simple fact that it could become a problem I believe is enough to suggest that we implement an llup:release and llup:expires as either,

1) Attributes of atom:published
2) Attributes of an llup prefixed/namespaced time-span (or something similar) element, similar to the way Russ and I wrote the original sample in the overview spec so many years ago. :)
3) Separate elements for both the start and expiration times.

I can see good reasons for using all three,

1) Pro: Builds upon an existing and related Atom element.  Con: Not everyone agrees that using prefixed attributes is a good and acceptable thing.
2) Pro: The prefix is bound to the element, and the attributes belong to the same namespace.  Con: using dates as attribute values breaks away from the convention used in the Atom spec of dates as text nodes of the related element.
3) Pro(s): Sticks with the conventions used in the Atom spec, Easier to read.  Con: A bit more verbose than the usage of a single element with attribute values.

Theres actually three issues that I believe we need to make a determination on,

1) Do we use atom:published to represent the moment in which the content should be made available?
2) If not, do we add them as attributes to atom:published, as attributes to an llup:time-span element, or their own element ( e.g. llup:start or llup:release and llup:expires)
3) Regardless of attribute or element, do we use llup:start or llup:release to represent the moment in time the message content should be made available?


** e.g. see: http://dev.llup.org/wiki/reference/example/blips#AverysimpleBlipwithcustomdomain-specificdataembedded

    <time-span start="2007-05-25T09:00:00" expires="2007-05-26T09:00:00"/>

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155
Reply all
Reply to author
Forward
0 new messages