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?
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).
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.
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.
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.
Cheers,
--
Mark Nottingham http://www.mnot.net/
