The intention of Simple Extension Elements is to provide a
simple class of extension that is part of the Atom model, and can
therefore be preserved end-to-end by implementions via publishing
clients, servers, databases, and aggregators.
We say that Simple Extension Elements are not language sens
On 5/8/05 3:07 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> src="http://www.example.com/atom"; />
how about this instead
http://www.example.com/atom";
type="application/atom+xml"
thread:idref="urn:foo:1" />
this way processors that have a basic understanding of wha
A. Pagaltzis wrote:
* James M Snell <[EMAIL PROTECTED]> [2005-08-04 21:15]:
Personally, however, I think that the elegance and simplicity
of in-reply-to and replies link rel values trumps defining them
as elements in a separate namespace or an otherwise perfectly
engineered solution. As for
A. Pagaltzis wrote:
* Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 06:00]:
ah, but how do you know those URIs are id's?
or more specifically, is the following URI an id or a location?
You don’t know. Just goes to show once again that Antone was
right all along to rail against ab
Eric Scheid wrote:
On 5/8/05 1:30 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
* Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 04:55]:
What if those particular had @rel="in-reply-to", and
per that spec would be the URIs. Would updating those URIs
be wrong?
If an atom:id happ
* James M Snell <[EMAIL PROTECTED]> [2005-08-04 21:15]:
> Personally, however, I think that the elegance and simplicity
> of in-reply-to and replies link rel values trumps defining them
> as elements in a separate namespace or an otherwise perfectly
> engineered solution. As for specifying the sou
* Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 06:00]:
> ah, but how do you know those URIs are id's?
>
> or more specifically, is the following URI an id or a location?
>
>
You don’t know. Just goes to show once again that Antone was
right all along to rail against abusing atom:link for th
On 5/8/05 1:30 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> * Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 04:55]:
>> What if those particular had @rel="in-reply-to", and
>> per that spec would be the URIs. Would updating those URIs
>> be wrong?
>
> If an atom:id happened to be a dereferenca
* Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 04:55]:
> What if those particular had @rel="in-reply-to", and
> per that spec would be the URIs. Would updating those URIs
> be wrong?
If an atom:id happened to be a dereferencable HTTP URI and
dereferencing produced 301, what would you do?
The sa
A question...
If I have a store of entries, which of course contain many s, and at
some point I retrieve various of those links and find that some of them
respond with 301 Moved and a new Location ... should I then be updating the
s in my store? What if those particular had
@rel="in-reply-to", a
On 8/4/05, Sam Ruby <[EMAIL PROTECTED]> wrote:
> I believe that the term "content" is open to intelligent dispute.
> Apparently the authors of RFC3470/BCP70 believe so too.
Agree.
> I won't dispute your read on the consensus of the working group
Agree.
> but I
> would like to request that *SOM
Bill de hÓra wrote:
> 0. The validator isn't the spec.
+1 to the sentiment that the validator isn't the spec.
- Sam Ruby
Tim Bray wrote:
>
> I'm getting increasingly grumpy and "just fail" is looking better and
> better. The current normative text, "The element's content MUST be an
> IRI", is clear and simple and supported by other well-understood
> normative text, supported by lots of interoperable software, t
0. The validator isn't the spec.
cheers
Bill
James M Snell wrote:
>
> +++1
>
> Joe Gregorio wrote:
>
>> On 8/4/05, Danny Ayers <[EMAIL PROTECTED]> wrote:
>>
>>
>>> I don't really understand why this should be treated any differently
>>> than the numerous other problematic things that could
* Tim Bray <[EMAIL PROTECTED]> [2005-08-04 20:25]:
> I'm getting increasingly grumpy and "just fail" is looking
> better and better.
The way I read the conversation is that noone will dispute “just
fail” if we do choose to adopt it.
> I claim that text enjoyed strong, not rough, consensus suppo
Tim Bray wrote:
>
> I'm getting increasingly grumpy and "just fail" is looking better and
> better. The current normative text, "The element's content MUST be an
> IRI", is clear and simple and supported by other well-understood
> normative text, supported by lots of interoperable software, t
+++1
Joe Gregorio wrote:
On 8/4/05, Danny Ayers <[EMAIL PROTECTED]> wrote:
I don't really understand why this should be treated any differently
than the numerous other problematic things that could happen if one
doesn't take the spec literally. (I'd suggest spec prose trumps RNG
grammar, a
I definitely appreciate all of the feedback on this. The conversation
has definitely been helpful. Personally, however, I think that the
elegance and simplicity of in-reply-to and replies link rel values
trumps defining them as elements in a separate namespace or an otherwise
perfectly engi
On 8/4/05, Danny Ayers <[EMAIL PROTECTED]> wrote:
> I don't really understand why this should be treated any differently
> than the numerous other problematic things that could happen if one
> doesn't take the spec literally. (I'd suggest spec prose trumps RNG
> grammar, as there's a lot of other
Dave Pawson wrote:
On Thu, 2005-08-04 at 09:31 -0700, Tim Bray wrote:
I'm getting increasingly grumpy and "just fail" is looking better and
better.
So for now, I'm -1 on an weakening or removing "The element's content
MUST be an IRI" or analogous text in any other section. I'll stop
On Thu, 2005-08-04 at 09:31 -0700, Tim Bray wrote:
>
> I'm getting increasingly grumpy and "just fail" is looking better and
> better.
> So for now, I'm -1 on an weakening or removing "The element's content
> MUST be an IRI" or analogous text in any other section. I'll stop
> shouting if
On Thu, 2005-08-04 at 17:45 +0200, Danny Ayers wrote:
> > I don't want to allow whitespace. But this
> >
> >
> > urn:foo
> >
> >
> > is going to happen, is going to cause problems, and working around it
> > does not strike me as being something you can foist entirely onto the
> > spec's end
On Aug 4, 2005, at 6:53 AM, Robert Sayre wrote:
I propose trying harder, but I am open to "just fail".
As am I. I am not OK with a long treatise on whitespace, like the one
Tim suggested. If there is a MUST-breaking error in a feed, that's not
an Atom document and I don't want to talk about
* James Aylett <[EMAIL PROTECTED]> [2005-08-04 15:25]:
> On Thu, Aug 04, 2005 at 02:42:31PM +0200, Bjoern Hoehrmann wrote:
>
> > * Tim Bray wrote:
> > >"Implementors are advised that there is a common class of
> > >error in [...]
> >
> > Sorry but this is ridiculous; if we say X MUST Y even tho
On 8/2/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
>
> Graham wrote:
> > From atompub-format-10, 4.2.6: "Its content MUST be an IRI"
> >
> > That to me is demonstrates a very clear intention of the working group
> > that the content must be exactly equal to the IRI.
My reading too.
> I don't
* Paul Hoffman wrote:
>You can't compare an IRI with a non-IRI. So, if you are handed an
>non-IRI (as in, an IRI-looking string that has whitespace around it),
>should you fail immediately or try harder? I propose trying harder,
>but I am open to "just fail".
Well, if we expect that many conte
On 8/4/05, Paul Hoffman <[EMAIL PROTECTED]> wrote:
> I propose trying harder, but I am open to "just fail".
As am I. I am not OK with a long treatise on whitespace, like the one
Tim suggested. If there is a MUST-breaking error in a feed, that's not
an Atom document and I don't want to talk about
At 2:42 PM +0200 8/4/05, Bjoern Hoehrmann wrote:
* Tim Bray wrote:
"Implementors are advised that there is a common class of error in
[...]
Sorry but this is ridiculous; if we say X MUST Y even though we know
that many X won't Y we are abusing RFC 2119 terminology and make it
much more diffic
On Thu, Aug 04, 2005 at 02:42:31PM +0200, Bjoern Hoehrmann wrote:
> * Tim Bray wrote:
> >"Implementors are advised that there is a common class of error in
> >[...]
>
> Sorry but this is ridiculous; if we say X MUST Y even though we know
> that many X won't Y we are abusing RFC 2119 terminolog
* Tim Bray wrote:
>"Implementors are advised that there is a common class of error in
>[...]
Sorry but this is ridiculous; if we say X MUST Y even though we know
that many X won't Y we are abusing RFC 2119 terminology and make it
much more difficult to evangelize 100% compliance, since this all
Tim Bray wrote:
> I'm strongly -1 on treating this as anything but an error. We may at
> our discretion make it forgiveable.
I really do not understand - it's an error or it's not not. Elsewhere in
their replies, Paul and Robert seem to think this is obviously
meaningful. Clearly I don't get
On Aug 4, 2005, at 3:25 AM, Paul Hoffman wrote:
At 7:37 PM -0400 8/2/05, Robert Sayre wrote:
One way of saying this would be "Atom Processors MAY ignore leading
and trailing whitespace in _."
That works for me. Another idea is "Atom Processors MAY ignore
leading and/or trai
At 11:43 AM +0100 8/4/05, Bill de hÓra wrote:
Paul Hoffman wrote:
At 7:37 PM -0400 8/2/05, Robert Sayre wrote:
One way of saying this would be "Atom Processors MAY ignore leading
and trailing whitespace in _."
That works for me. Another idea is "Atom Processors MAY ignore
On 8/4/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> I don't understand the benefits of MAY. It sounds like this to me:
> "whitespace is not allowed in certain elements, but you may ignore that
> directive by trimming the content".
What's the problem with that? That discourages sloppy feed genera
Paul Hoffman wrote:
>
> At 7:37 PM -0400 8/2/05, Robert Sayre wrote:
>
>> One way of saying this would be "Atom Processors MAY ignore leading
>> and trailing whitespace in _."
>
>
> That works for me. Another idea is "Atom Processors MAY ignore leading
> and/or trailing whitespace
On 4 Aug 2005, at 11:25 am, Paul Hoffman wrote:
That works for me. Another idea is "Atom Processors MAY ignore
leading and/or trailing whitespace in elements whose content does
not allow leading and/or trailing whitespace, such as IRIs and
."
This doesn't describe an interoper
At 7:37 PM -0400 8/2/05, Robert Sayre wrote:
One way of saying this would be "Atom Processors MAY ignore leading
and trailing whitespace in _."
That works for me. Another idea is "Atom Processors MAY ignore
leading and/or trailing whitespace in elements whose content does not
all
Sam Ruby wrote:
> A note that Atom processors may consider leading and trailing space as
> significant in attribute and element values would be enough to alert
> people to the interoperability issues.
But it wouldn't cater for them. That note would need to be a MUST to be
effective.
> Disallowi
38 matches
Mail list logo