On 10/27/05, James M Snell <[EMAIL PROTECTED]> wrote: > > Luke Arno wrote: > > >Spec says it can mean "first availability of the resource". > > > >I did not invent that. > > > > > > > *can* mean does not mean *does* mean, which is precisely the point I am > making. You cannot retroactively change the meaning from "can" to "does". >
No, it means "can". As in, we *can* use it to mean first availability. > >>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. > > > > > > > Sam's entries are not partial representations. Sam's entries simply do > not include a published date in its collection of metadata. You cannot > partially represent something that does not exist. > It is just a feed not an APP collection. > >>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. > > > > > > > So you're arguing that the semantics of atom syntax elements should be > different depending on who is looking at them? I get to redefine the > meaning of atom elements to suit whatever I want to do?! Boy, that'll > make writing extensions easier. > No. I am arguing that we can define logic that acts upon semantics already allowed. Nothing is being redefined here. > >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. > > > > > > > No, you are trying to redefine the syntax to meet the needs of the > protocol and are claiming that it is ok to say that a single syntax > element means two different things depending on who is looking. No. The atom spec says that it can have 2 meanings. I think it should *only* mean published but that is orthogonal. The spec says it *can* mean published. I suggest that when the APP looks at it, it does mean published. I don't understand why the atom spec leaves us this choice, but it does. I have not checked the archives but I would bet it was a compromise to put the language like that because a bunch of people wanted a created element. That is just a guess. If there is some sense to it, please educate me. > Further, you're basing your argument on an incorrect assertion that the > existing semantics of the format spec supports you use case. I continue to disagree with you on this. > It's like > trying to wash a window with a wire scrubbing pad and claiming that > that's ok because wire scrubbing pads can be used for cleaning. Knock > yourself out, but don't complain when you start seeing scratches in the > window. > That is a silly analogy. It sounds like something I would come up with :) I don't do windows. > >>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. > > > > > > > It's a draft in my collection, not Sam's. What we're talking about is a > control parameter that communicates to a collection when to make a > particular member entry publicly available as a member of that > collection. It does not matter if that entry has already been published > as part of another collection. > Why in the world would you do that? If you really wanted to for some reason, I would say use an extension or just put private-remote-entries (or whatever) in their own collection. > >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). > > > > > Which defeats the purpose if what I want is a collection that *does* > feed into a public facing feed. > The idea is that then you move it in to the public collection when you are ready. Or use an extension. That is not really drafting. That is some other pattern. > >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. > > > > > > > why go through such twisted mechanics if a single pub:draft element > would solve the problem? You've argued in other conversations in favor > of extensions. Why is the use of an extension in this case such a bad > thing, especially when it does not requiring mucking around with > existing defined semantics? > It is not "twisted". They are two things with different dispatching needs so they get distinct mime types. There are atom feeds and APP collections. I don't think we are "mucking around" with semantics. We are defining logic around existing semantics. It seems silly to require extensions for the core protocol. The atom syntax needs extensions to work with the atom protocol? > >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) > > > > > > > AFAIK, none of these past discussions have attempted to redefine the > semantics of those elements. > Neither does this one. - Luke
