On 10/27/05, James M Snell <[EMAIL PROTECTED]> wrote:
>
> Luke Arno wrote:
>
> >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.
> >
> >
> >
> 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.
>
Quite right. I don't think we need to say much though.
We have already established that feeds don't have to
have complete entries. The rest is up to the implementer
as far as I am concerned.
> >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 entry
> >>
> >>
> >>
> >
> >I should not have said "intended to provide".
> >
> >How about "perfect for providing"?
> >
> >
> >
> 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.
>
Yes. "Not published" means not in the subscription feed to
me. But why do we need draft?
> >> >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?
> >
> >
> >
> 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".
>
> 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.
>
> You say that we should not recreate semantics already available in the
> atom syntax when no such semantics exist.
>
Thanks. I have read the spec. I don't see an answer to my
question here.
Ok. I will ask you again. Do you have a problem with using
this:
"If an entry does not contain an atom:published
element it is considered not yet published."
?
> >> >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?
> >
> >
> >
> 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.
>
Ok, that was snarky. I'm sorry. :)
> >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?
> >
> >
> >
> Why does the Atom format spec have a section dedicated to how extensions
> are defined and processed?
>
That was seemingly successfully generalized. I don't
see putting control in a box to be striped as a pattern
that serves all cases.
What does the box do other than that?
> >If it is going to vary widely across implementations
> >then if does not belong in the core.
> >
> >
> >
> 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.
>
Those things work. What does pub:control do for us?
> 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 think the atom spec language on extensions is enough.
Saying that control should be handled through extensions
wont hurt. I think it is obvious and I don't know that we need
to say it but it wont break anything.
Maybe it should go in an implementers guide.
> 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.
>
I am all for the myriad of cool extensions that will grow up
for control purposes.
> >BTW, When was the door closed for extensions?
> >
> >
> >
> Who's arguing against using extensions for control metadata?
>
No one I hope. That was not my meaning.
> 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.
>
I was just poking at you. :) The wiki spam thing has made the
recent updates page a pain. Yeah.
- Luke
