Luke Arno wrote:
Yes. "Not published" means not in the subscription feed to
me. But why do we need draft?
draft exist so that the APP client can communicate to the server whether
or not the entry should be published.
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."
?
Again, yes. I don't agree with attempts to reinvent the
semantics/purpose of existing elements, especially optional ones.
atom:published has a specific meaning. If you want to expand its
meaning, propose a change to the Atom format spec.
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?
Once again, I'm not arguing in favor of pub:control. I was responding to
errors I saw in your pace and commenting on your specific proposal to
strip control out completely.
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.
I make no such assumptions as to what is "obvious" or "not obvious".
Maybe it should go in an implementers guide.
-1, control is a generalizable feature that more than meets the 80/20
rule. It should be discussed in the core spec.
- James
