On Jul 15, 2009, at 9:25 PM, Mark Nottingham wrote:
I *think* that #2 isn't allowed, process-wise, because the atom
namespace is reserved for things done on the standards track (IIRC).
I agree with you wholeheartedly.
I'd say #1 is the right thing to do; it'll give us experience with
the issues, use cases, etc.
This is why I am not in favor of making too many rules about the
meaning of ae:inline. So lets stick to using ae:inline as a stop-gap
arrangement until a standards track solution collapses atom:feed
directly into atom:link.
Cheers,
On 16/07/2009, at 2:20 PM, Nikunj R. Mehta wrote:
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
--
Mark Nottingham http://www.mnot.net/
