On Jun 2, 2009, at 6:28 PM, Mark Nottingham wrote:
On 27/05/2009, at 10:12 PM, Julian Reschke wrote:
I do not agree with that conclusion, but nevertheless, just because
something is syntactically legal doesn't make it a good choice.
+1 - the clearest way to communicate what's going on here is to use
a new child element.
Did you read the I-D being discussed? If not, I would encourage you to
do so. The I-D is specifying a meaning for an atom:entry or atom:feed
found inside atom:link. If this is not how Atom can be extended, then
pray tell me how.
Assuming that the contents of the link element are inlined content
are adding an extension without explicitly identifying it; this may
conflict with future uses.
Our proposal is /the/ future use, so I don't see how it can conflict
with future uses. It is our intention to promote an extension of Atom.
By submitting the I-D to the IETF and by bringing this discussion to
atom-syntax, we have made the intention quite clear, don't you agree?
It is a different story if Atom cannot be extended as we wish. May be
it would be useful if you or others who claim that our approach is
wrong can explain what is the process for extending Atom. Is it
creating a brand new working group?
There isn't a way for an Atom processor to inspect a link element
and know that the content is inlined; they have to guess that this
specification is in effect, therefore the link content is the
inlined content.
The I-D is proposing a backwards compatible extension of Atom. An old
Atom processor would just ignore that in-lined content. Only new Atom
processors would therefore be able to process the in-lined content.
This isn't good practice.
Why so?
