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".
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.
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.
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.
Further, you're basing your argument on an incorrect assertion that the
existing semantics of the format spec supports you use case. 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.
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.
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.
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?
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.
- James
