On 10/27/05, James M Snell <[EMAIL PROTECTED]> wrote: > > Luke Arno wrote: > > >I don't see it as reinvention. Published still conveys the same > >thing: first availability of the resource. We would be making a > >very logical inference based on the existing semantics. If there > >is no time of first availability then it is not yet available. > > > >It is *syntactically* optional. I wonder why. Maybe because it > >needs to be able to sanely represent an unpublished entry. > > > > > > > It *is* reinvention in that you're basing your argument on a semantic > that does not exist. >
Spec says it can mean "first availability of the resource". I did not invent that. > Note: For the sake of this discussion, I am assuming that "published" == > "publicly available" > > Look at Sam Ruby's Atom feed > (http://www.intertwingly.net/blog/index.atom). Are the entries in his > feed published or not? What can you infer from the lack of > atom:published? Is there any logical connection between the state of > his entries being published and the lack of an atom:published element? We have already covered that syndication feed can contain partial representations of entries. > Compare Sam's feed to my Atom feed > (http://www.snellspace.com/wp/wp-atom1.php). My entries do use > atom:published. Does that mean that my entries are published and Sam's > aren't? What if I modified my Atom template so that it no longer > included atom:published? Does that mean my entries are no longer > published? What if only every other entry in my feed uses > atom:published? Does that mean that only half of the entries in my feed > have been published? > Mean to who? To an aggregator: why should it care? To an APP client viewing collections: I vote yes. You are talking about syndication feeds. I am talking about APP collections. How those will work is still open to debate right? If not, I have been tricked and a lot of my time has been wasted. You are making a circular argument "It has to work that way because that is the way it works" and treating syndication and editing as if they were the same thing. You are also blurring the line between protocol and syntax. > atom:published is optional because there is no reason to require feed > publishers to indicate when an entry has been published. It really is > that simple. The lack of atom:published in an entry does not imply that > the entry has not been published. The only logical inference one can > make from the existing semantics defined for atom:published is that the > feed publisher has decided to either specify a published date or not. It > is purely informational. Adding any further semantics is reinvention. > I disagree. For the purposes of APP we can consider this implied meaning. Published would not have this meaning in another context but we can certainly use it this way in the context of APP. > Let's look at it from a different perspective. This is a hypothetical, > but hang with me for a second. Suppose that Sam starts using > atom:published in his entries. Now suppose that I have a collection to > which I add entries that come from other feeds (a link blog of sorts). > I want to take one of Sam's entries and add it directly to my > collection. Sam's entry includes an atom:published element that > specifies when his entry was published. However, I don't want Sam's > entry to be marked as being publicly available yet. Using an approach > that is based on atom:published, I have to strip Sam's atom:published in > order to accomplish what I want. That's bad. Now flip it around, > suppose that Sam's entry does NOT have atom:published, but I want the > entry to be publicly available. Using your suggested approach, I have > to add atom:published to his entry, meaning that I am adding metadata to > the entry that does not accurately reflect the reality of when Sam's > entry was actually published. That's also bad. > Ok, I see your concern now but I am still not sure. Why would you save someone else's entry as a draft? It is not a draft. They have published it. If you really need to do this you could always use a collection that does not feed into any public facing feed (so to speak). If a feed is intended to be republished in this way, is it not participating in APP and now subject to its rules, say a rule regarding the use of published? Should we say aggregatable feed and APP feed? How would we differentiate? Mime type? That has been on my mind anyway, for dispatching to APP clients vs. aggregators. Note that we have talked about rules for how atom syntax is used in the context of APP before without protest being raised. (roundtrip vs. writable) Well, Rob did protest but not on grounds that it violated the atom spec, IIRC. Actually, there has been talk of strait-up violating atom syntax (which I am against unless we have a very very good justification). - Luke
