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 -09

[A. Pagaltzis]

* M. David Peterson <[EMAIL PROTECTED]> [2006-05-04 23:30]:
> Or is something like this simply inviting WAY TOO MANY little
> things to find justification to plug up the collective inbox of
> the community members?

I don’t know. So far during extension development discussions,
only the missing extensibility for links has stuck out as a real
sore point in RFC 4287. Other than that, the spec has stood up
very well with only a few minor errata reported here and there.

At least, that’s my impression; I don’t know what others think,
of course.

Frankly, I would hope there won’t be much interest – cause if
there is, what else would that mean than that we did a shoddy
job? :-)

Regards,
-- 
Aristotle Pagaltzis // 

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 -09

[M. David Peterson]

Just a note:  When you consider that what people gain is, in essence, a simplified way to gain access to information that is otherwise accessible, just at a higher over-the-wire , and processor intensive cost, then it makes a lot of sense to create an extensible namespace/specification devoted strictly to these types of things.  This would allow for at least two things:
- the ability for experience "from-the-field", or in other words, areas of optimization and/or convenience that have been discovered past the point of a specification last-call, and yet add value to more than one implementor, and as such justification for collaboration on how to go about things in a way that makes sense to more than one implementor.
- The ability to push off controversial, questionable, and/or just plain ugly pieces of any given spec that do little more than cause a need for the spec editor to spend a bit of time to pre-funk before approaching his/her inbox, knowing exactly what it is that requires him/her to get half way to his/her home office before returning to the fridge for an extra two bottles to kill the pain thats bound to ensue WELL after the pre-funk has worked its way through the system. ;)
Something like this could start at the Atom wiki with a "PostSpecOptimizations" page set-up where folks can attach data sheets with test results, or real world use-case studies that showcase needs in particular areas that are not enough to justify their own spec, but enough to offer gains to the community as a whole, and as such, justification to work in a more centralized manner such as this list once it has gotten past the "yeah, this makes sense to me too... lets propose it" stage.
Or is something like this simply inviting WAY TOO MANY little things to find justification to plug up the collective inbox of the community members?On 5/4/06, 
A. Pagaltzis <[EMAIL PROTECTED]> wrote:
* James M Snell <[EMAIL PROTECTED]> [2006-05-04 18:00]:> The only sane answer would have been to make link extensible.There's no doubt about that at this point. Non-extensibility of
links has caused us a lot of pain in several different extensionsat this point.Unfortunately, only hindsight is 20/20…> However, for now, I think I'll proceed by simply dropping the> count and when from the draft.
Okay. It's a pity, since folks were obviously getting value fromthat information, but it's an acceptable move.Regards,--Aristotle Pagaltzis // -- M. David Petersonhttp://www.xsltblog.com/

Re: Feed thread -09

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [2006-05-04 18:00]:
> The only sane answer would have been to make link extensible.

There’s no doubt about that at this point. Non-extensibility of
links has caused us a lot of pain in several different extensions
at this point.

Unfortunately, only hindsight is 20/20…

> However, for now, I think I'll proceed by simply dropping the
> count and when from the draft.

Okay. It’s a pity, since folks were obviously getting value from
that information, but it’s an acceptable move.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Feed thread -09

[James M Snell]

A. Pagaltzis wrote:
>[snip]
> I don’t know if I like it. It really, *really* departs from
> “something that’s as simple to implement as possible,” doesn’t
> it? Not only is this just as hard for consumers to implement as
> previous sketches, it’ll *also* annoy publishers, I think.
> 

Yep.

> Question: what is the reason you are so staunchly opposed to
> cloning `atom:link` for the extension’s purposes?
> 

I am very much against the idea of encouraging extension developers to
go off and clone core Atom elements whenever they want to provide some
additional piece of information.  e.g., Say I create a thr:link.  what
value would that add to end users and feed reader implementors?
OpenSearch already has their own os:link.  Gdata has entryLink and
feedLink (which aren't clones of atom:link, but are still links
nonetheless). The more we clone and duplicate the function of atom:link,
the less valuable and useful atom:link becomes, and the more we put
undue burden on feed consumers.


> I’m starting to think that that is the only sane answer. If you

The only sane answer would have been to make link extensible.  If I
thought it would actually be a fruitful exercise, I would suggest that
we amend rfc4287 to make it extensible, per section 4.1.1 of RFC2026:

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change ... of the specification
   before it advances.

However, for now, I think I'll proceed by simply dropping the count and
when from the draft.  The folks who want those things can add them back
under a different namespace.  It's not worth chasing our tails over two
pieces of optional metadata.  I've already prepared a draft -10 that
removes the attributes complete, I just haven't sent it off yet.

- James

Re: Feed thread -09 (was: Re: Atom Rank Extensions)

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [2006-05-03 03:45]:
> Ok, so how's this (not word-for-word as I would write it in the
> spec, but you should get the idea)
> 
> The ref attribute MUST be an absolute URI that matches a the
> resolved href URI of a replies link character-for-character
> (case sensitive)
> 
> In other words;
> 
>xml:base="http://example.org/foo"; />
> http://example.org/comments.xml"; ... />

I don’t know if I like it. It really, *really* departs from
“something that’s as simple to implement as possible,” doesn’t
it? Not only is this just as hard for consumers to implement as
previous sketches, it’ll *also* annoy publishers, I think.

Question: what is the reason you are so staunchly opposed to
cloning `atom:link` for the extension’s purposes?

I’m starting to think that that is the only sane answer. If you
want to provide additional information about a link, you need to
associate this information with the link somehow. If you want to
stick to the spec mechanisms for extending the format, then you
have to provide this information in extension elements and you
must not add attributes to the link. So you must identify the
link by one of its attributes. The only attribute of `atom:link`
by which you can identify it at all is `href`. However, if you
factor in xml:base, you’re in a world of pain, and I don’t see
any way out of that.

The only other option I see is a very ugly hack: ride on the back
the `rel` attribute, abusing the fact that a relation may be a
URI to provide an identifier, ie. something like

http://purl.org/net/thread/replies?id=x3os882ja";
href="comments.atom"
...
/>

But that’s so awful and dirty on so many levels that that I have
to go wash my hands now. Ugh.

Regards,
-- 
Aristotle Pagaltzis //