Re: Feed thread update

[David Powell]

Friday, May 5, 2006, 4:05:15 AM, Tim Bray wrote:

> Give me a break, we're in the first *days* of something that will be  
> used for at least decades.  Todays' APIs will have a vanishingly- 
> small lifespan in comparison

The issue isn't that an implementation is at fault. The issue is that
a implementation is not at fault, is behaving reasonably, and yet
still wouldn't be compatible with the extension.

As I said 12 months ago
:

| The problem with section 6 is that we define 3 different classes of
| non-Atom markup, but don't say why we've done that, or help authors to
| know which type they should choose when they write a document.
| [...]
| It doesn't really make sense we have thought out how to extend
| atom:feed, atom:entry, atom:author etc, but atom:link is a sub-RSS
| free-for-all.

Section 6 was received inadequate review. Perhaps someone can tell me
now, why there are three different classes of non-Atom markup?

Section 6 came about due to a clash between people who see Atom as an
XML document format like XHTML ([1] choice 1), and people who see Atom
as a serialisation of feed and entry concepts, that span multiple XML
documents ([1] choice 2). Section 6 satisfies neither party.

[1] http://www.mnot.net/blog/2004/05/12/on_infosets

The distinction between Simple and Structured extensions was a well
meaning, but misguided, effort to provide a lower bar for extension
support for implementations that would find it unfeasible to preserve
the full Infoset and xml:lang/xml:base context.


> crippling our expressiveness

"...and conservative in what you send".  That is the point here.


What percent of stateful feed stores do you think support all of
Atom's core elements?

How many handle xml:lang and xml:base correctly for core elements? -
less?

How many handle simple extensions? - less?

How many handle structured extensions, including ones that require that the 
xml:base
and xml:lang context is preserved? - less?

How many handle arbitrary attributes on any Atom element, and
arbitrary XML in atom:link? - less?

How many preserve the order of elements for any future extensions that
choose to make order significant? - less?

How many cope with extensions that follow our example of
"inheritance", and maintain feed extensions as they were at the time
of the document that the entry was last delivered with for the benefit
of "inheritable" feed extensions, whilst also maintaining an
association with the latest feed metadata for the benefit of "true"
feed extensions? - less?

How many preserve the namespace mappings for any future extensions
that choose to use QNames in content? - less?

How many preserve PIs and comments for any future extensions that make
use of them? - less?


Atom doesn't define any conformance levels for the preservation of
content and extensions, so extension designers are forced to consider
the consequences themselves.

If you're happy working with XML APIs over a set of polled feed
documents (together with their preserved URIs, Content-Locations,
entity headers and retrieval dates), then none of this matters.

If you see a benefit of providing a higher level abstraction over
feeds and entries, an OO API, an RDBMS schema, an APP implementation,
or any value-added feed processing service, then it is worth
considering the practicalities of such support and employing a bit of
conservatism.


-- 
Dave

Re: Feed thread update

[Tim Bray]

On May 4, 2006, at 7:10 PM, James M Snell wrote:


At issue is whether or not authors of standardized
extensions should extend elements with undefinedContent when we know
full well that there are API implementations out there that have made
the extremely shortsighted decision to completely ignore such content.


Give me a break, we're in the first *days* of something that will be  
used for at least decades.  Todays' APIs will have a vanishingly- 
small lifespan in comparison; crippling our expressiveness in  
deference to them is, frankly, silly. -Tim

Re: Feed thread update

[James M Snell]

Tim,

Just to be clear, when I say that link should have been extensible, I
mean that link should have used extensionElement* rather than
undefinedContent.  In fact, to be completely honest, I don't think
undefinedContent should have been in the spec at all.  atom:link and
atom:category are the only two elements that use it, and there does not
appear to be any rationale given as to why.

With that said, the real question here is not whether namespaced
attributes and elements can or can not appear on the atom:link element.
 As you point out, and as I've mentioned in the past, the spec is very
clear on this point.  At issue is whether or not authors of standardized
extensions should extend elements with undefinedContent when we know
full well that there are API implementations out there that have made
the extremely shortsighted decision to completely ignore such content.

- James

p.s. I wonder how many folks realize that the following examples are
perfectly legal and valid according to the spec.

  http://example.org/foo";>This is some text

  http://example.org/foo>
http://www.w3.org/1999/xhtml";>Foo!
  

  
This entry belongs to category
foo!
  


Tim Bray wrote:
> 
> On May 4, 2006, at 3:43 PM, Thomas Broyer wrote:
> 
>> Things would have been far easier if either a) atom:link were
>> extensible
> 
> This assertion that atom:link is not extensible is simply, flatly,
> completely, wrong.  I just went and reviewed 4287 and I think it is
> perfectly clear on this.  I suggest that interested parties review
> sections 4.2.7, 6.3, and 6.4 and, if they still think there is any
> problem with child elements of , find language in the RFC
> which says something other than what those sections say. -Tim
> 
> 

Re: Feed thread update

[A. Pagaltzis]

* Tim Bray <[EMAIL PROTECTED]> [2006-05-05 03:50]:
> If it turns out to be useful, it'll stick. Otherwise not.

No doubt; but then why did we need so much verbiage in Sec. 6.4.
and subsections anyway?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Feed thread update

[Tim Bray]

On May 4, 2006, at 5:08 PM, A. Pagaltzis wrote:


The assertion is not that atom:link may not have child elements
or namespaced attributes. The assertion is that the list of
locations for Metadata elements in Section 6.4 should have
included atom:link.


Mountain, meet molehill.

If it turns out to be useful, it'll stick.  Otherwise not. -Tim

Re: Feed thread update

[Tim Bray]

On May 4, 2006, at 5:25 PM, Kyle Marvin wrote:


the motivation behind
sometimes using 'extensionElement' and other times 'undefinedContext'
in the Relax-NG schemas for various 4287 elements is a point of
confusion.


Agreed.  Fortunately the schema's non-normative. -Tim

Re: Feed thread update

[Kyle Marvin]

On 5/4/06, Tim Bray <[EMAIL PROTECTED]> wrote:
>
> On May 4, 2006, at 3:43 PM, Thomas Broyer wrote:
>
> > Things would have been far easier if either a) atom:link were
> > extensible
>
> This assertion that atom:link is not extensible is simply, flatly,
> completely, wrong.  I just went and reviewed 4287 and I think it is
> perfectly clear on this.  I suggest that interested parties review
> sections 4.2.7, 6.3, and 6.4 and, if they still think there is any
> problem with child elements of , find language in the RFC
> which says something other than what those sections say. -Tim

I'll admit that I was unclear on this point:  the motivation behind
sometimes using 'extensionElement' and other times 'undefinedContext'
in the Relax-NG schemas for various 4287 elements is a point of
confusion.

But as Tim says, literally speaking I don't think either one precludes
elements in a foreign namespace.

-- Kyle

Re: Feed thread update

[Robert Sayre]

On 5/4/06, Tim Bray <[EMAIL PROTECTED]> wrote:


This assertion that atom:link is not extensible is simply, flatly,
completely, wrong.


I agree that it's not an especially convincing or interesting
argument, given that 6.4 starts with

"Atom allows foreign markup anywhere in an Atom document"

We certainly don't want consumers to barf on foreign markup anywhere,
so it has to be allowed everywhere. Of course, you'd be foolish to put
extension attributes on things like atom:updated, and lots of other
places, because then you're going to force people to dive into the
feedparser/feedtools/gdata/etc implementation layer. Secondly, we
might not like it for strange pseudo-nationalistic reasons, but some
implementers find it convenient to transcode Atom to RSS2. when you're
doing that, it's more difficult to preserve markup in areas left
undefined by the specification. If you want to make a point, and carp
on how crappy those applications are, you'll look for an excuse to do
it. In reality, those extension points haven't proven that interesting
or necessary, and the current thread is a particularly forceful
example of that reality for those of who aren't participating. So, it
really is that most common of syndication archetypes: the tempest in a
teacup.

--

Robert Sayre

Re: Feed thread update

[A. Pagaltzis]

* Tim Bray <[EMAIL PROTECTED]> [2006-05-05 01:50]:
> This assertion that atom:link is not extensible is simply,
> flatly, completely, wrong. I just went and reviewed 4287 and I
> think it is perfectly clear on this. I suggest that interested
> parties review sections 4.2.7, 6.3, and 6.4 and, if they still
> think there is any problem with child elements of ,
> find language in the RFC which says something other than what
> those sections say.

The assertion is not that atom:link may not have child elements
or namespaced attributes. The assertion is that the list of
locations for Metadata elements in Section 6.4 should have
included atom:link.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Feed thread update

[Tim Bray]

On May 4, 2006, at 3:43 PM, Thomas Broyer wrote:


Things would have been far easier if either a) atom:link were
extensible


This assertion that atom:link is not extensible is simply, flatly,  
completely, wrong.  I just went and reviewed 4287 and I think it is  
perfectly clear on this.  I suggest that interested parties review  
sections 4.2.7, 6.3, and 6.4 and, if they still think there is any  
problem with child elements of , find language in the RFC  
which says something other than what those sections say. -Tim

Re: Feed thread update

[Thomas Broyer]

2006/5/2, James M Snell <[EMAIL PROTECTED]>:

Regarding the ref vs. href, issue, I really want to discourage client
implementors from using the thr:replies as a link to the comment feed.


Why?


From what I read this week in other threads (about cloning the

atom:link element, etc.), I think it could work.

1. define a "replies" link relation, so there is an atom:link pointing
to the replies feed
2. define a thr:replies element with an @href and additional metadata
(count, updated), clients are invited to use the thr:replies/@href and
*not* to try to match the thr:replies element with an
atom:[EMAIL PROTECTED]"replies"] ; if a "reader" processes thr:replies
elements it should then ignore each and every
atom:[EMAIL PROTECTED]"replies"].

Step 1 is either optional (do not define this "replies" link relation)
or mandatory (require that there is an atom:[EMAIL PROTECTED]"replies"]
matching each thr:replies element).

Those three elements would have equivalent meaning, the last one
adding extra metadata:




Things would have been far easier if either a) atom:link were
extensible or b) xml:base wasn't allowed on every element but only on
"sections" (namely, atom:feed, atom:entry and atom:content) that can
be included from other documents, so that you don't have to rewrite
relative IRIs (I think that's the original rational behind xml:base),
but that's not the case…

To conclude, I think using attributes directly on atom:link is the
thing to do, waiting for an amendment to RFC4287 to invite
processors/parsers not to discard that extra metadata. The other
choice is to totally remove those attributes, which is what you
finally chose, I can't blame you.

--
Thomas Broyer

Re: Feed thread update

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [2006-05-02 17:00]:
> I'll go ahead and make the ref attribute optional.

I think that still needs to be accompanied with verbiage about
global vs local reply count though. There should be guidance on
what it means when elements both with and without `ref`
attributes are present on the same entry.

> Regarding the ref vs. href, issue, I really want to discourage
> client implementors from using the thr:replies as a link to the
> comment feed. Having and href attribute in there is inviting
> headaches. Suggestions on possible ways of wording the spec /
> attribute naming / etc would be greatly appreciated.

Okay, I can see that. Harumpf. Not happy; there has to be a way
to associate links directly with `thr:replies` elements and the
only other way than by comparing `href`s that I can think of is
to put a namespaced attribute on the link, which sucks for
reasons we’ve already been over.

Will have to read this revision and think about it.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Feed thread update

[James M Snell]

Aristotle,

I'm not 100% happy with it yet so it may change at least one more time.
 But I did want to get this out and in front of y'all to get initial
reactions.

I'll go ahead and make the ref attribute optional.  Regarding the ref
vs. href, issue, I really want to discourage client implementors from
using the thr:replies as a link to the comment feed.  Having and href
attribute in there is inviting headaches.  Suggestions on possible ways
of wording the spec / attribute naming / etc would be greatly appreciated.

- James

A. Pagaltzis wrote:
> * James M Snell <[EMAIL PROTECTED]> [2006-05-02 07:15]:
>> As you can see from the example, the thr:replies/@ref attribute
>> points to an atom:id value, and not the URI used by the link.
> 
> So fetching and parsing all relevant links is the only way to
> know which `thr:replies` element applies to which link, and no
> way to indicate a global reply count is available?
> 
> Regards,

Re: Feed thread update

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [2006-05-02 07:15]:
> As you can see from the example, the thr:replies/@ref attribute
> points to an atom:id value, and not the URI used by the link.

So fetching and parsing all relevant links is the only way to
know which `thr:replies` element applies to which link, and no
way to indicate a global reply count is available?

Regards,
-- 
Aristotle Pagaltzis //