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
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
* 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
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
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
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
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
* 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 // http://plasmasturm.org/
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
* 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
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
* 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`
A. Pagaltzis wrote:
It worked for David Powell; his
concerns about technical flaws in the Thread extension convinced
James to revise the draft, where your vociferous unsubstantiated
objections had previously failed.
Speaking of which, I'm not very happy about it, but I just sent off an
13 matches
Mail list logo
