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.
Disallowing
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
allow
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
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 in elements
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 generation,
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 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
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
* 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
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 terminology and
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
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 it.
* 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 content
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 want to allow
* 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 though
we know
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
On Thu, 2005-08-04 at 17:45 +0200, Danny Ayers wrote:
I don't want to allow whitespace. But this
id
urn:foo
/id
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-users.
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 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 stuff
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
+++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, as
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, that
* 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 support
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 happen if one
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, that
A question...
If I have a store of entries, which of course contain many links, 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
links in my store? What if those particular links had
* Eric Scheid [EMAIL PROTECTED] [2005-08-05 04:55]:
What if those particular links had @rel=in-reply-to, and
per that spec would be the id 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
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 links had @rel=in-reply-to, and
per that spec would be the id URIs. Would updating those URIs
be wrong?
If an atom:id happened to be a dereferencable HTTP
* 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 source
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?
link rel=something-you-don't-know href=... /
You don’t know. Just goes to show once again that
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
31 matches
Mail list logo
