On 2 Aug 2005, at 5:41 am, James Cerra wrote:
id
http://example.com/
/id
idhttp://example.com//id
Those are different ids (Processors MUST compare atom:id elements on
a character-by-character basis), and the first is just plain
invalid. Why on earth would you think otherwise?
(oh,
Graham wrote:
On 2 Aug 2005, at 5:41 am, James Cerra wrote:
id
http://example.com/
/id
idhttp://example.com//id
Those are different ids (Processors MUST compare atom:id elements on a
character-by-character basis), and the first is just plain invalid.
Why on earth would you
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
Looks great.
My only suggestion would be to expose the MUSTs etc. little more,
especially where Atom differees from RSS. E.g. right now it would be
easy for someone coming from RSS 2.0 to think that id was the same
as guid.
So in this case maybe:
Identifies the feed in a universally unique 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
The diffs linked below should reflect comments on the first round. No
effort has been made to resolve the ambiguity discovered around
leading and trailing whitespace. Awaiting chairs' instructions for
that.
http://www.franklinmint.fm/2005/08/02/draft-ietf-atompub-format-11-from-10.diff.html
* 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
Robert Sayre [EMAIL PROTECTED] wrote:
The diffs linked below should reflect comments on the first round.
A few more minor nits I'm afraid. (I don't think I've seen these
discussed before.)
http://www.franklinmint.fm/2005/08/02/draft-ietf-atompub-format-11.txt
| Atom allows the use of IRIs
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
37 matches
Mail list logo
