Re: Feed thread update

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

Re: Feed thread update

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 on

Re: Feed thread update

* 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

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

Re: Feed thread update

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

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 review

Re: Feed thread update

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" W

Re: Feed thread update

* 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 th

Re: Feed thread update

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 sugg

Re: Feed thread -09

* 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 ex

Re: Feed thread update

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

Re: Feed thread -09

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 stri

Re: Feed thread -09

* 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 i

Re: Feed thread -09

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. > Qu

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

* 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 sen