On Jul 14, 2009, at 10:44 PM, Mark Nottingham wrote:
On 14/07/2009, at 9:09 AM, Nikunj R. Mehta wrote:
The two approaches, (a) and (b), you suggest below:
1. end up forking the meaning of "feed" and "entry" and future
specs would have to specify applicability of their mechanisms in
the context of the new mechanism in addition to their use in
RFC4287. A lot of the meta data specialized for feeds such as link
relations (paging), identity, and others would have to be repeated
in the new element.
When you say "repeated", are you referring to repeating the
specification of these things, or repeating the content itself in
the feed?
I meant repeating the specification. If atom:feed and ae:feed walk the
same way and talk the same way, then why bother creating different
things?
Assuming that it's the former, this is a concern, although I'd
personally be inclined to try. Of course, if this were a standards-
track extension, we could use the form below (i.e. embedding
atom:feed and atom:document directly as a child of atom:link).
Good to hear that. I would argue that we should work towards the goal
of eliminating ae:inline so that atom:feed and atom:entry can be
directly embedded. What is the best way to get there?
1. An experimental track RFC (in 2009) that uses ae:inline followed by
a standards track RFC that legalizes using atom:feed/atom:entry
directly under atom:link (in 2010/11)
2. An An experimental track RFC (in 2009) that legalizes using
atom:feed/atom:entry directly under atom:link (in 2010/11) and
standardizing this later (in 2010/11)
3. A standards track that legalizes using atom:feed/atom:entry
directly under atom:link (in 2010/11)
2. cause confusion and human errors because of mis-understood
namespaces. I see the following usage quite likely, even though it
is inadvertent:
<atom:link rel="down" href="...">
<atom:feed>
...
</atom:feed>
</atom:link>
No; this is what the feed validator is for. People will make
mistakes -- especially with XML -- no matter what we do.
Let's not make it any more likely for people to make mistakes. This
issue will be moot if we go on approach 2 or 3.
As for the duplication of metadata and content [4], I will go
through and provide explanations for each of the cases identified
in [1]. I agree that this is an important issue and we need to
carefully tread this space. The approach should make it easy to in-
line content if all the content is being homogeneously managed. In
other words, it should be possible to copy bits directly if one
doesn't allow untrusted DTD entities, serializes everything to
UTF-8, starts every Atom document with its own xml:lang and
xml:base (and bi-di) metadata, and so on.
That's very restrictive, and IMO don't belong in the spec itself.
My point is simply that the "embedding case" should be trivial, just
like embedding text in atom:content is trivial. Other cases must be
supported, albeit with appropriate metadata.
The use case for non-Atom content to be in-lined definitely ought
to be given thought. Would a separate mark-up mechanism be best for
addressing this, as opposed to using ae:inline? I am not so sure.
In any case, I am striving to at least be methodical about giving
up on the design approach taken by RFC4287 in how it deals with
arbitrary content and in-lining (an entry document in a feed
document).
I think it largely depends on how the discussion above goes, but I'd
hope that the draft (never mind the specific element used) would
cover this.
Let's first settle the issue of using atom:feed directly inside
atom:link, since that outcome will affect how we deal with this use
case.
Regards,
Nikunj
