On Aug 4, 2005, at 21:55, Joe Gregorio wrote:
Some sections of this specification are illustrated with fragments of
a non-normative RELAX NG Compact schema [RELAX-NG]. However, the text
of this specification provides the definition of conformance. A
complete schema appears in Appendix B.
This
On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote:
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,
On Aug 3, 2005, at 6:04 AM, Sam Ruby wrote:
To an Infoset person, this following is a completely different stream
from the example above (please ignore any line breaks that your email
client may insert):
atom:id#104;#116;#116;#112;#58;#47;#47;#101;#120;#97;#109
Tim Bray wrote:
On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote:
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
-Original Message-
From: Tim Bray [mailto:[EMAIL PROTECTED]
Sent: Monday, August 08, 2005 1:58 AM
To: Sam Ruby
Cc: atom-syntax@imc.org
Subject: Re: spec bug: can we fix for draft-11?
On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote:
Tim Bray wrote:
I'm getting
Using Sun's 'relames' [1] it is *nearly* possible to
validate an instance as is intended by the text!
Where (datetime for instance) an element content
must not have whitespace, relames picks it up nicely.
element name=atom:published
s:assert test=normalize-space(.) = .There must be no
this? Brett.
- Original Message -
From: Walter Underwood [EMAIL PROTECTED]
Date: Friday, August 5, 2005 4:37 pm
Subject: Re: spec bug: can we fix for draft-11?
--On August 4, 2005 9:31:55 AM -0700 Tim Bray
[EMAIL PROTECTED]
wrote:
So for now, I'm -1 on an weakening or removing
Robert Sayre wrote:
I'll also note that this requirement has basically zero value for a
desktop aggragator. I have only written three or four Atom parsers,
but I think the approach that has the best mix of performance and
correctness is one where SAX events are treated as input events for a
* Tim Bray [EMAIL PROTECTED] [2005-08-05 14:05]:
Uh, anyone who's lazily concatenating strings is pretty soon
going to end up with a free ampersand or something worse in
their Atom feed. Right?
I think that’s a bit grand of a generalization.
It’s not hard to build XML by concatening strings,
Robert Sayre wrote:
On 8/5/05, Bill de hÓra [EMAIL PROTECTED] wrote:
If you're going to recommend ignoring it in practice, why not recommend
throwing it out? Why equivocate?
You keep saying equivocate, as if there were some hard-to-swallow
truth I'm avoiding.
I've said it twice; don't
A. Pagaltzis wrote:
I suggest simply the following: in 4.2.6 (The atom:id Element),
change
Its content MUST be an IRI, as defined by [RFC3987].
to read:
Its content MUST be an IRI, as defined by [RFC3987], and MUST
NOT contain any whitespace.
It doesn’t change anything, it just
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
+++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
* Tim Bray [EMAIL PROTECTED] [2005-08-03 06:30]:
I personally think the framework of specifications is
crystal-clear, and per the letter of the law
atom:id
http://example.com/foo
/atom:id
is totally illegal because the string
\nhttp://example.com/foo\n does not conform to the
On 3 Aug 2005, at 2:04 pm, 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.
+1
Graham
On 02/08/2005, at 9:15 PM, Tim Bray wrote:
So if the WG really thinks this is a sensible clarification I won't
scream too much.
It's probably necessary any way, because RFC3470/BCP70 Section 4.16
encourages specs to give guidelines about white space;
Implementers might safely assume
On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote:
The design intent of character-by-character cmp as I understood was
for
the URI contained by the element. I think confusing the element
content
with the URI is a spec bug.
From atompub-format-10, 4.2.6: Its content MUST be an IRI
That to
Graham said:
the format. I will figuratively lie down in the road if anyone
suggests whitespace should be allowed around any machine-read content
(uris, @type, @rel, etc).
+1. Possible whitespace would add general check removal calls to any
processor. When you process 100 items, thats not a
Graham wrote:
On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote:
The design intent of character-by-character cmp as I understood was for
the URI contained by the element. I think confusing the element content
with the URI is a spec bug.
From atompub-format-10, 4.2.6: Its content MUST
Sascha Carlin wrote:
Graham said:
the format. I will figuratively lie down in the road if anyone
suggests whitespace should be allowed around any machine-read content
(uris, @type, @rel, etc).
+1. Possible whitespace would add general check removal calls to any
processor. When you
Graham wrote:
On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote:
The design intent of character-by-character cmp as I understood was for
the URI contained by the element. I think confusing the element content
with the URI is a spec bug.
From atompub-format-10, 4.2.6: Its content MUST be
Julian Reschke wrote:
Graham wrote:
On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote:
The design intent of character-by-character cmp as I understood was for
the URI contained by the element. I think confusing the element content
with the URI is a spec bug.
From atompub-format-10,
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. [...] When we say MUST above, we need to be clear on how
we're
Bill de hÓra wrote:
Julian Reschke wrote:
Graham wrote:
On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote:
The design intent of character-by-character cmp as I understood was for
the URI contained by the element. I think confusing the element content
with the URI is a spec bug.
From
On 02/08/2005 10:51, Graham wrote:
That to me is demonstrates a very clear intention of the working group
that the content must be exactly equal to the IRI. Changing this to
allow whitespace would represent a major technical change to the
format. I will figuratively lie down in the road
Ian Davis wrote:
Graham wrote:
That to me is demonstrates a very clear intention of the working group
that the content must be exactly equal to the IRI. Changing this to
allow whitespace would represent a major technical change to the
format. I will figuratively lie down in the road
On 2 Aug 2005, at 12:50 pm, Ian Davis wrote:
The two examples that Bill gave WILL happen in the wild and Atom
consumers will just deal with it by stripping the whitespace anyway
despite what the spec says now. I think this should be endorsed in
the spec for interoperability.
I (and
James Cerra wrote:
Ian Davis wrote:
Graham wrote:
That to me is demonstrates a very clear intention of the working group
that the content must be exactly equal to the IRI. Changing this to
allow whitespace would represent a major technical change to the
format. I will figuratively lie down
On 02/08/2005 14:11, Graham wrote:
I (and probably others) have already put code out into the wild in the
assumption there is no whitespace. As I said before, it's too late for
a solution that changes the meaning of the spec.
Does your code reject the content of atom:id if it doesn't
On 8/2/05, James Cerra [EMAIL PROTECTED] wrote:
Neither of those are strictly legal, since white space is illegal in both IRI
and RFC 3339 (dates) I think. However they are legal with the Relax NG
grammer
used.
Yes, they are. Relax NG regex matching strips leading and trailing
whitespace.
Julian Reschke wrote:
James Cerra wrote:
Ian Davis wrote:
Graham wrote:
That to me is demonstrates a very clear intention of the working group
that the content must be exactly equal to the IRI. Changing this to
allow whitespace would represent a major technical change to the
format. I
Graham wrote:
On 2 Aug 2005, at 12:50 pm, Ian Davis wrote:
The two examples that Bill gave WILL happen in the wild and Atom
consumers will just deal with it by stripping the whitespace anyway
despite what the spec says now. I think this should be endorsed in
the spec for
* Sascha Carlin [EMAIL PROTECTED] [2005-08-02 13:10]:
Agreed. Why not do it? Instead of
item
idsome-uri/id
...
/item
it could read
item id=some-uri
...
/item
I have always wondered why it wasn’t done this way.
Another reason this would have been good is that it would
On 8/2/05, Julian Reschke [EMAIL PROTECTED] wrote:
Me confused.
(http://www.atompub.org/2005/07/11/draft-ietf-atompub-format-10.html#rfc.section.3.3),
how exactly does this allow whitespace around the xsd:datetime value???
http://lists.xml.org/archives/xml-dev/200309/msg00434.html
I'm
Julian Reschke wrote:
Robert Sayre wrote:
On 8/2/05, James Cerra [EMAIL PROTECTED] wrote:
Neither of those are strictly legal, since white space is illegal in
both IRI
and RFC 3339 (dates) I think. However they are legal with the Relax
NG grammer
used.
Yes, they are. Relax NG regex
Sam Ruby wrote:
...
Why would they be legal with the RNG grammar
From http://www.w3.org/TR/xmlschema-2/#dt-whiteSpace:
For all ·atomic· datatypes other than string (and types ·derived· by
·restriction· from it) the value of whiteSpace is collapse and
cannot be changed by
* Sam Ruby [EMAIL PROTECTED] [2005-08-02 16:05]:
I'm not yet sure what the right thing to do here is, but lets
to do the right thing.
The spec as defined already leans in the direction of favouring
simplicity in consumers in many areas, but does so particularly
heavily when it comes to IDs.
Sam Ruby wrote:
Even if we decide that whitespace is not significant, I do believe that
having the feedvalidator issue a warning in such cases is appropriate.
+1
cheers
Bill
A. Pagaltzis wrote:
At the very least, the normalization procedure that the spec
RECOMMENDS should contain language about stripping surrounding
whitespace.
I too would like to see that added to the recommended normalization
rules in section 4.2.6. That would make my job easier if somebody
On Tue, 2005-08-02 at 15:24 +0100, Bill de hÓra wrote:
Sam Ruby wrote:
Even if we decide that whitespace is not significant, I do believe that
having the feedvalidator issue a warning in such cases is appropriate.
+1
What is the IETF version of an errata sheet? Is that the right
place
* Dave Pawson wrote:
Even if we decide that whitespace is not significant, I do believe that
having the feedvalidator issue a warning in such cases is appropriate.
+1
What is the IETF version of an errata sheet? Is that the right
place to tackle this?
For RFCs see
On Tue, 2005-08-02 at 19:11 +0200, Bjoern Hoehrmann wrote:
For RFCs see http://www.rfc-editor.org/errata.html.
Thanks.
Just playing.
With schema
define name=uriTest
element name=test
oneOrMore
element name=uri
attribute name=href
data type=anyURI/
/attribute
data type=anyURI/
On 2 Aug 2005, at 5:46 pm, Sam Ruby wrote:
As it stands now, the spec does NOT clearly outlaw leading and
trailing
whitespace from ids
I've been trying to argue with this but I can't find a normative
reference that explains what the content of an element is. This is
perhaps a bigger
On 8/2/05, Graham [EMAIL PROTECTED] wrote:
On 2 Aug 2005, at 5:46 pm, Sam Ruby wrote:
As it stands now, the spec does NOT clearly outlaw leading and
trailing
whitespace from ids
I've been trying to argue with this but I can't find a normative
reference that explains what the
Robert Sayre wrote:
For me, the most disturbing aspect of this debate is that any
resolution will provide very, very little interoperability gain. URIs,
like XML Elements, cannot begin or end with whitespace. I don't
believe it's worth mentioning in the spec, and I think we're off in
the
On 2 Aug 2005, at 9:07 pm, Robert Sayre wrote:
For me, the most disturbing aspect of this debate is that any
resolution will provide very, very little interoperability gain.
Agreed. All we need to do is decide one way or the other what the
spec should say.
That said, I certainly
On 8/2/05, Graham [EMAIL PROTECTED] wrote:
On 2 Aug 2005, at 9:07 pm, Robert Sayre wrote:
For me, the most disturbing aspect of this debate is that any
resolution will provide very, very little interoperability gain.
Agreed. All we need to do is decide one way or the other what the
On Aug 2, 2005, at 4:37 PM, Robert Sayre wrote:
One way of saying this would be Atom Processors MAY ignore leading
and trailing whitespace in _. That is, no existing
software is buggy, but if you want to be sure your document is
processed accurately, you should trim the space
70 matches
Mail list logo
