Luke Arno wrote:
There is another option for control. So far this discussion has assumed that the Atom subscription feeds generated from the members in a collection are showing EXACTLY what is being passed around between the client and collection in the APP. If we disconnect entries in the collection and entries in the subscription feed, this problem actually goes away. Subscription feeds generated over the content of a collection should be nothing more than filtered views of the collection content and may pick and choose what metadata they want to include in the feed. In other words, rather than having a requirement stating that control metadata MUST be stripped, we turn it around and say that there is no requirement for public versions of a collection member to include the complete set of the metadata for the entry. This eliminates the need to structurally differentiate control metadata from other entry extensions.And implementations will want to handle extensions (processing or otherwise) in different ways. 1. The implementation knows what it is and handles it according to its rules. 2. The implementation knows about some flag and handles it according to rules for that flag. 3. The implementation knows about some box and handles it according to its rules for that container. 4. The implementation does not know what it is but sends it on through. 5. The implementation does not know what it is and strips it.
Then I need to ask who those semantics are being communicated to: APP clients or public feed subscribers? If the answer is APP clients, then you are right, we have no argument on this point. The only question is *where* the draft element is located (inside or outside pub:control). If the answer is feed subscribers, then you are wrong. For public feed subscribers, the best way to communicate that an entry has not been published is for the entry to not appear in the public feed at all.etc.>2. The draft element is intended to provide semantics to communicate publication status. Incorrect. The draft element is intended to allow the client to tell the server whether the client believes that the posted representation is a draft or not. It is not used to communicate the actual publication status of the entryI should not have said "intended to provide". How about "perfect for providing"?
I generally oppose all attempts to reinvent the purpose of elements defined in other specifications. The lack of atom:published in an entry means absolutely nothing more than "atom:published is not specified".>This is a DRY violation. atom:published is optional. If an entry does not have published, it is... >not published. We should not recreate semantics already available in atom syntax. Incorrect. The presence of atom:published does NOT indicate the publication status of the entry. atom:published is purely informational and serves no other purpose than to indicate when the server considers the entry to have been published. The semantics that you are claiming we are recreating do not exist.Do you have an argument against using it that way (which is obviously my point) or are you just miffed about the other thread and being pedantic?
4.2.9 The "atom:published" ElementThe "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.
You say that we should not recreate semantics already available in the atom syntax when no such semantics exist.
If I'm still undecided, why would I attempt to refute your point? I generally lean in favor of the significant element but I have not yet made up my mind about whether or not that is the best approach.>3. The significant element is intended to communicate a clients desire to update updated. <snip> I'm currently undecided on this one yet.Thanks for the opinion. Do you wish to refute my point?
Why does the Atom format spec have a section dedicated to how extensions are defined and processed?Your argument for control is nonsensical. "The very fact that control metadata will vary across implementations demonstrates that there is a potential for serious interop issues that we can partially mitigate by included some basic control processing language in the core spec" What does the word "standard" mean to you?
Extensions are going to vary widely across implementations and yet basic extension processing is discussed in the format spec core. By "basic" I mean things such as the "must ignore" rule expressed in section 6.3, the scoping rules discussed in section 6.4 and the various rules about where such extensions may or may not appear within the feed/entry document.If it is going to vary widely across implementations then if does not belong in the core.
The core spec needs to address basically how control should be done lest we run into the potential for serious interop problems. Doing so could be as simple as saying that control elements should be included as extension elements in the atom:entry, subject to all the same processing instructions as other Atom extensions and that public views of an atom:entry are under no obligation to spit out the full collection of metadata contained within a member entry. Doing should should be enough to discourage folks from going out and inventing a bunch of different, incompatible ways of doing control stuff.
I'm not going to argue in favor of pub:control right now. FWIW, the blog control extensions I helped draft would work with or without pub:control.
BTW, When was the door closed for extensions?
Who's arguing against using extensions for control metadata?And oh, just to be clear, this coming up today has nothing to do with that other conversation; it came up today because today is the first day that I've really had the time to sit down and review the Pace. I almost missed it among the recent rash of wiki spam rollbacks.
- James
