Subject: Introduction to The Atom Syndication Format

From: Sam Ruby <[email-masked]>
Date: Mon, 01 Aug 2005 22:38:55 -0400

http://www.atomenabled.org/developers/syndication/

Feedback welcome.

- Sam Ruby

---

From: James Cerra <[email-masked]>
Date: Mon, 1 Aug 2005 21:41:22 -0700 (PDT)

> Sam Ruby annoyed us with:
> 

Interesting examples.  I'm probably missing a few things, so any clarifications
filling the gaps in my head would be appreciated!  :-)

From the Atom spec that I scanned (10) it is unclear if white space in atom:id
and atom:updated elements (among others) is significant.  The only mention is
where the type attribute is allowed, where white space is sometimes
normalizable.  Strictly following the spec, then the following would be
different atom:ids right?

<id>
  http://example.com/
</id>

<id>http://example.com/</id>

Of course that's not what's wanted.  What is reasonable is that they are the
same atom:id.  However normalizing the whitespace is not enough, or even
wanted.  What is required is specifying that leading and trailing whitespaces
are not significant.

Also, the atom:content Processing Model specifies that new lines must be
U+000A.  What about Mac/Windows/other new line conventions?

P.S. Just kidding about the annoying thing.  I actually thought it was
insightful!

--
Jimmy Cerra
https://nemo.dev.java.net

		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

---

From: "Roger B." <[email-masked]>
Date: Mon, 1 Aug 2005 23:46:35 -0500

Sam: I've only given it a quick skim, but at first blush, I think it
looks great.

--
Roger Benningfield

---

From: Eric Scheid <[email-masked]>
Date: Tue, 02 Aug 2005 16:21:11 +1000

> http://www.atomenabled.org/developers/syndication/

"<link> is patterned after html's link element. "
[...]
"rel indicates the link relationship type. "

It would be good to indicate that atom:rel is different from html's rel in
that only one value is allowed, not a space-delimited list.

e.

---

From: Graham <[email-masked]>
Date: Tue, 2 Aug 2005 09:15:24 +0100

> <id>http://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, apparently because the feed validator is broken)

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 02 Aug 2005 10:07:25 +0100

Graham wrote:
> 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?

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. It's unreasonable to expect people to think
they're not the same id and this will be a souce of needless problems
unless we fix it.

cheers
Bill

---

From: Graham <[email-masked]>
Date: Tue, 2 Aug 2005 10:51:42 +0100

On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote:

> with the URI is a spec bug.

 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. Changing  
this to allow whitespace would represent a major technical change to  
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).

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 02 Aug 2005 11:23:32 +0100

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 if anyone  suggests
> whitespace should be allowed around any machine-read content  (uris,
> @type, @rel, etc).

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. Assuming everything you said above is true, we're
responsible for specifying that XML element content that cannot contain
leading or trailing whitespace (to be pedantic, a subset of what XML
allows). When we say MUST above, we need to be clear on how we're
supposed to deal with cases where someone does not follow the spec. For
example, being clear whether the the above fragment is illegal or
requires pre-processing would be useful.

[You capture the essence when you mention machine-readable content.
Really, that stuff should go into attributes not element content for
exactly these kinds of reasons.]

cheers
Bill

---

From: "Sascha Carlin" <[email-masked]>
Date: Tue, 2 Aug 2005 12:20:34 +0200 (CEST)

> (uris, @type, @rel, etc).

+1. Possible whitespace would add general check & removal calls to any
processor. When you process 100 items, thats not a problem. Staring with
10.000 is begins tu hurt, and will blow it up when you reach 100.000 items.

Sascha

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 02 Aug 2005 11:39:10 +0100

> 10.000 is begins tu hurt, and will blow it up when you reach 100.000 items.

Interesting.

1. What should I do when I see this:

<id>
  urn:foo
</id>

2. What should I do when I see this:

<id>
  urn:foo
</id>

100,000 times?

Again to make it clear: I am not arguing for whitespace in atom:id. I am
arguing that whitespace is inevitable in atom:id and I think in that
regard the spec is buggy, one way or another.

cheers
Bill

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Aug 2005 12:34:18 +0200

> whitespace should be allowed around any machine-read content  (uris, 

+1

A potential enhancement would be to explicitly state that whitespace 
*isÜ significant here (and of course to make the feedvalidator check it).

Best regards, Julian

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 02 Aug 2005 11:45:33 +0100

> *isÜ significant here (and of course to make the feedvalidator check it).

That still leaves things unsaid - significant in what way? What does
"make the feedvalidator check it" entail?  And assuming we did this
enhancement how does whitespace square with our MUST be an IRI.

Somebody please convince me the spec is adequate here; I'm not seeing
it. I'm feeling an urge to go through all the elements for any other
machine readable tokens living inside element content and filing bugs
against the lot of them. Then I'll do the same with APP constructs like
'draft'.

cheers
Bill

---

From: "Sascha Carlin" <[email-masked]>
Date: Tue, 2 Aug 2005 12:54:57 +0200 (CEST)

> spec's end-users. [...] When we say MUST above, we need to be clear on how
> we're supposed to deal with cases where someone does not follow the spec.
> For example, being clear whether the the above fragment is illegal or

All of this will just be work-arounds, as pointed out.

> exactly these kinds of reasons.]

Agreed. Why not do it? Instead of

<item>
    <id>some-uri</id>
    ...
</item>

it could read

<item id="some-uri">
   ...
</item>

As being said, this should have to be applied to all directly
machine-generated or machine-readable data.

Sascha

PS: Please accept my apologies for the strange orthography in my last post -
I couldn't get my four espressos this morning :-)

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Aug 2005 13:00:21 +0200

> enhancement how does whitespace square with our MUST be an IRI.

If you put whitespace inside, it's part of the to-be-IRI. As an IRI can 
not contain whitespace, it's an invalid IRI.

> against the lot of them. Then I'll do the same with APP constructs like

Seems that the spec may need to define once what it means to say that 
the content of an element must be something specific, such as an IRI.

Best regards, Julian

---

From: Ian Davis <[email-masked]>
Date: Tue, 02 Aug 2005 12:50:21 +0100

> whitespace should be allowed around any machine-read content  (uris, 

Leading and trailing whitespace should be stripped from the content of 
an atom:id element.

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.

Ian

-- 
http://internetalchemy.org | http://purl.org/NET/iand
Working on... Silkworm <http://silkworm.talis.com/>

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 02 Aug 2005 13:09:24 +0100

Sascha Carlin wrote:

> Agreed. Why not do it? I

Probably because it trades a spec text fix for a design fix. Not that
there's anything wrong with your design, but it would set a WG precedent
that wouldn't be helpful at this point (Bray and Hoffman would come
round our houses...)

cheers
Bil

---

From: James Cerra <[email-masked]>
Date: Tue, 2 Aug 2005 05:40:08 -0700 (PDT)

> Ian Davis wrote:

+1.  But Sam Ruby's first draft at [1] demostrated more than just atom:id.  (He
changed it now so that the examples don't have white space showing! lol!)  They
also included things like:

<id>
  http://example.com/
</id>

<updated>
  2003-12-13T18:30:02Z
</updated>

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.

I think that it also be should be noted for atom:person/* constructs (except
for atom:name) and atom:date constructs that white space is illegal.  Or that
for them and atomURI constructs that leading and trailing whitespace is legal
but should be stripped away.  I'm not sure which is best.

Then there is atom:person/atom:name constructs.  Should leading and trailing
whiespace be stripped or should it be considered significant?  Certainly it is
significant and legal in the middle of a person's name.

[1] http://www.atomenabled.org/developers/syndication/

		
__________________________________ 
Yahoo! Mail for Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail

---

From: Graham <[email-masked]>
Date: Tue, 2 Aug 2005 14:11:41 +0100

On 2 Aug 2005, at 12:50 pm, Ian Davis wrote:

> despite what the spec says now. I think this should be endorsed in  
> the spec for interoperability.

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.

Graham

---

From: Danny Ayers <[email-masked]>
Date: Tue, 2 Aug 2005 15:09:02 +0200

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 permanent way.
=>
Identifies the feed in a universally unique and permanent way, using an IRI.
or perhaps
Identifies the feed in a universally unique and permanent way,
according to rfc3987.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Aug 2005 15:27:21 +0200

> and RFC 3339 (dates) I think.  However they are legal with the Relax NG grammer

Why would they be legal with the RNG grammar????

Best regards, Julian

---

From: Ian Davis <[email-masked]>
Date: Tue, 02 Aug 2005 14:29:19 +0100

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 conform to 
the IRI spec? i.e. does it flag the feed as invalid. If so, then at 
least it mitigates the problem by reducing the number of feeds that will 
  inadvertently include whitespace.

If not, and you're treating the element content as opaque content, then 
you're going to be inadvertently processing invalid feeds. I guess the 
primary consequence is that your users are going to get duplicate items.

Ian

---

From: Robert Sayre <[email-masked]>
Date: Tue, 2 Aug 2005 09:33:58 -0400

> and RFC 3339 (dates) I think.  However they are legal with the Relax NG grammer

Yes, they are. Relax NG regex matching strips leading and trailing
whitespace. Atom Processors will do the same, so we should fix it.
"Comparison operations MUST be based solely on the IRI character
strings", and the URI specs have always suggested that you should
strip leading and trailing space.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Tue, 02 Aug 2005 09:49:21 -0400

Julian Reschke wrote:
>>> Leading and trailing whitespace should be stripped from the content
>>> of an atom:id element.
>>>

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 a schema author; for string the value of
    whiteSpace is preserve; for any type ·derived· by ·restriction· from
    string the value of whiteSpace can be any of the three legal values.

That being said, the RNC grammar for atom contains:

    atomId = element atom:id {
       atomCommonAttributes,
       (atomUri)
    }

    # Unconstrained; it's not entirely clear how IRI fit into
    # xsd:anyURI so let's not try to constrain it here
    atomUri = text

- Sam Ruby

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Aug 2005 15:48:47 +0200

> strip leading and trailing space.

Me confused.

In

atomDateConstruct =
    atomCommonAttributes,
    xsd:dateTime

(<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???

Best regards, Julian

---

From: Sam Ruby <[email-masked]>
Date: Tue, 02 Aug 2005 09:56:15 -0400

> a solution that changes the meaning of the spec.

I have put code out in the wild based on the assumption that whitespace
is not significant.  One or more of us have a bug, and potentially the
spec does too.  Note: the code in the feedvalidators consists entirely
of a single line, and that line was put in there intentionally, and test
cases were coded to ensure that this code behaved as intended.

Note: from an XML point of view, the following are all distinct:

  <id>http://example.com</id>
  <id><![CDATA[http://example.com]]></id>
  <id> http://example.com </id>

However, from the point of view of a tool that expects a xsd:anyURI,
they are the same.

I'm not yet sure what the right thing to do here is, but lets to do the
right thing.

Even if we decide that whitespace is not significant, I do believe that
having the feedvalidator issue a warning in such cases is appropriate.

- Sam Ruby

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 2 Aug 2005 16:05:25 +0200

> Agreed. Why not do it? Instead of

I have always wondered why it wasn’t done this way.

Another reason this would have been good is that it would have
enabled addressing specific entries in a feed document via a URI
fragment. (Sure, the is an IRI, so the fragment would be verbose
and would need escaping; but it would have been possible.)

Maybe I should have spoken up before… I just assumed that There
Are Sound Reasons for the design as chosen.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Robert Sayre <[email-masked]>
Date: Tue, 2 Aug 2005 10:00:39 -0400

>   how exactly does this allow whitespace around the xsd:datetime value???

http://lists.xml.org/archives/xml-dev/200309/msg00434.html

I'm not an expert, but I verifed that it was happening here with Jing
and nxml-mode.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Tue, 02 Aug 2005 10:05:53 -0400

>  how exactly does this allow whitespace around the xsd:datetime value???

Take a look at sections 3.2.7.6 and 4.3.6 of XML Schema Part 2:
Datatypes Second Edition, W3C Recommendation 28 October 2004.

- Sam Ruby

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Aug 2005 16:07:05 +0200

>     string the value of whiteSpace can be any of the three legal values.

Thanks for the XML Schema lesson. I wasn't aware of that.

>     # xsd:anyURI so let's not try to constrain it here

Well, *now* it seems that we really need to clarify.

Best regards, Julian

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 2 Aug 2005 16:30:36 +0200

* Sam Ruby <[email-masked]> [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. Cf. RECOMMENDED normalization and
all.

It seems natural to extend the assumptions about dumb clients
that should be catered to by outlawing whitespace.

I believe the spirit of the spec as it currently stands already
outlaws whitespace. The spec just isn’t explicit about it, hence
the problem we’re facing now.

> Even if we decide that whitespace is not significant, I do
> believe that having the feedvalidator issue a warning in such
> cases is appropriate.

Yes.

At the very least, the normalization procedure that the spec
RECOMMENDS should contain language about stripping surrounding
whitespace.

Regards,

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 02 Aug 2005 15:24:52 +0100

+1

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Tue, 02 Aug 2005 12:46:55 -0400

> RECOMMENDS should contain language about stripping surrounding

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 were
to challenge why I produced a warning in such a situation.

As it stands now, the spec does NOT clearly outlaw leading and trailing
whitespace from ids, and DOES require anybody the string to be kept
character by character equivalent whenever an entry is "relocated,
migrated, syndicated, republished, exported or imported".

If Graham was truly serious about wanting to do his part[1] to ensure
that atom:id is implemented properly, I would expect any atom:ids that
he mints from here on out to contain leading and trailing spaces, tabs,
and newlines (in a variety of Mac, DOS, and Unix styles).

But I wouldn't recommend it.  To me, doing so would be akin to mailing
fragile equipment and paying for insurance, in the hopes of getting the
opportunity to express indignation at the post office.

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg16243.html

---

From: Dave Pawson <[email-masked]>
Date: Tue, 02 Aug 2005 18:02:03 +0100

> > having the feedvalidator issue a warning in such cases is appropriate.

What is the IETF version of an errata sheet? Is that the right
place to tackle this?

I'm with Bill, I'm sure we'll see many instances which have
whitespace included, with a simplistic assumption that the
element contains an IRI, and nothing more.

James makes a good point about whitespace stripping in 
the other elements.

Looking at http://relaxng.org/spec-20011203.html
The anyURI symbol has the same meaning as the anyURI datatype of [W3C
XML Schema Datatypes]: it indicates a string that, after escaping of
disallowed values as described in Section 5.4 of [XLink], is a URI
reference as defined in [RFC 2396] (as modified by [RFC 2732]).

I can't see how the anyURI fits with element content; all the examples
I've seen
use it as an attribute value which I think is clearer due to XML 1.0

regards DaveP

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 02 Aug 2005 19:11:33 +0200

>What is the IETF version of an errata sheet? Is that the right

For RFCs see <http://www.rfc-editor.org/errata.html>.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Dave Pawson <[email-masked]>
Date: Tue, 02 Aug 2005 18:32:14 +0100

> 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"/>
</element>
</oneOrMore>
</element>
</define>

The example below parses well with James Clarks relax tools and the sun
validator.
<test>
<uri href="http://www.example.com">
http://example.com
</uri>

<uri href="   http://www.example.com ">
http://www.example.com
</uri>

</test>

regards DaveP

---

From: Graham <[email-masked]>
Date: Tue, 2 Aug 2005 18:52:21 +0100

On 2 Aug 2005, at 5:46 pm, Sam Ruby wrote:

> 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 problem.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 2 Aug 2005 16:07:31 -0400

> perhaps a bigger problem.

Depends how deeply we want to naval gaze. The normative Infoset term
would be "children", but that includes lots of things we don't care
about. For example, text constructs with a type attribute of "xhtml"
are supposed to a single div as their content. An XML handler
listening closely would notice whitespace characters before and after
the divs in the examples.

It's my belief that the "character-by-character" comparison mentioned
in the atom:id section could reference section "6.2.1. Simple String
Comparison" in RFC3986. In fact, it's a MUST-level requirement of
RFC3987 that they be compared that way. Of course, these comparisons
are based on having a URI/IRI to begin with, and URI/IRIs don't begin
with whitespace.

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 weeds. That said, I certainly wouldn't object to any text warning
people not to do it, or explicitly mentioning that you have to call
the equivalent of String.trim().

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 02 Aug 2005 21:43:47 +0100

> the equivalent of String.trim().

I respectfully disagree. After a day's worth of posting, no-one here has
been able to present a compelling argument one way or another as to whether

<atom:id>
  urn:example.org
<atom:id>

is illegal and if so, how software should behave in the light of that.
Mentioning things like this the why Atom has to exist at all, imvho.

cheers
Bill

---

From: Graham <[email-masked]>
Date: Tue, 2 Aug 2005 22:23:21 +0100

On 2 Aug 2005, at 9:07 pm, Robert Sayre wrote:

> 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 wouldn't object to any text warning

Recommending the former would draw attention to the issue and perhaps  
encourage the latter. (Or make both explicit, with SHOULD and MAY).

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 2 Aug 2005 19:37:26 -0400

> Agreed. All we need to do is decide one way or the other what the

Right. This is not a big deal. Since everyone but me seems to think it
needs fixing, let's do so.
 
> encourage the latter. (Or make both explicit, with SHOULD and MAY).

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 yourself.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Tue, 02 Aug 2005 21:15:54 -0700

> processed accurately, you should trim the space yourself.

Ecch.  Blecch.  Barf.

I suppose.

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 productions for either URI or IRI.

I am less convinced that people are actually going to do this, but I  
do agree that if a substantial number *do* do this, implementors will  
simply ignore us and code around it.  So if the WG really thinks this  
is a sensible clarification I won't scream too much.  -Tim

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 3 Aug 2005 11:05:28 +0200

* Tim Bray <[email-masked]> [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 productions
> for either URI or IRI.

That is the way I thought of it also.

> I am less convinced that people are actually going to do this,
> but I do agree that if a substantial number *do* do this,
> implementors will simply ignore us and code around it.  So if
> the WG really thinks this  is a sensible clarification I won't
> scream too much.

I would say the fact that we’ve had a three-day, 40-message
thread about what the spec really says here is sufficient
precedent to conclude that this needs to be explicit. The
ambivalent comment in the relevant section of the RNC grammar is
not helping matters either; that one *must* be fixed, informal or
no.

Regards,

---

From: Sam Ruby <[email-masked]>
Date: Wed, 03 Aug 2005 09:04:06 -0400

>> processed accurately, you should trim the space yourself.

I think we all feel that way.

> I suppose.

That way too.

> not conform to the productions for either URI or IRI.

As Graham noted, the issue is that differing persons approach this with
differing notions of what the term "content" means in this context.

"Document" and "Data" people approach these things with different filters.

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;&#112;&#108;&#101;&#46;&#99;&#111;&#109;&#47;&#102;&#111;&#111;</atom:id>

Infoset views the below two examples as different:

<atom:id><![CDATA[http://example.com/foo]]></atom:id>
<atom:id>http://example.com/foo</atom:id>

RelaxNG views all of the above as the same.

> I am less convinced that people are actually going to do this, but I  do
> agree that if a substantial number *do* do this, implementors will 

The reason that one line of code exists in the feedvalidator is because
somebody did do it, existing feed readers supported it, and I couldn't
defend the statement that the RSS 2.0 spec unambiguously prohibited it.

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.

Disallowing leading and trailing whitespace in IRI references (including
the isegment-nz-nc production), MIME media types, language tags,
lengths, addr-spec, and date-time productions would lead to improved
interoperability.

I'm fine with either.

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Wed, 3 Aug 2005 14:11:48 +0100

+1

Graham

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Aug 2005 18:37:38 -0700

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 that they can ignore the white  
> space
>    in the example above, but white space used for pretty-printing  
> can be
>    a source of confusion in other situations.  Consider a minor change
>    to the <value> element:
>
>    <value>
>      10.1.2.3
>    </value>
>
>    where white space is found on both sides of the IP address.  XML
>    processors treat the white space surrounding "10.1.2.3" as an
>    integral part of the <value> element.  A failure to recognize this
>    behavior can lead to confusion and errors in both design and
>    implementation.
>
>    All white space is considered significant in XML instances.  As a
>    consequence, it is recommended that protocol designers provide
>    specific guidelines to address white space handling within  
> protocols
>    that use XML.

--
Mark Nottingham     http://www.mnot.net/

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 04 Aug 2005 10:33:57 +0100

> people to the interoperability issues.

But it wouldn't cater for them. That note would need to be a MUST to be
effective.

> lengths, addr-spec, and date-time productions would lead to improved

My best guess is that given the choice to either reject a feed or call
trim(), people will call trim(). But some clarity either way would be
welcome and would need to be presented as a general processing
directive, and not just specific to the element we're talking about.

cheers
Bill

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Aug 2005 12:25:50 +0200

At 7:37 PM -0400 8/2/05, Robert Sayre wrote:
>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 leading and/or trailing whitespace, such as IRIs and ________."

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Graham <[email-masked]>
Date: Thu, 4 Aug 2005 11:39:22 +0100

On 4 Aug 2005, at 11:25 am, Paul Hoffman wrote:

> 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 interoperable model. Either all processors  
must remove whitespace, or whitespace is not allowed at all (Note the  
latter still allows processors to remove whitespace anyway).

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 04 Aug 2005 11:43:44 +0100

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 ________."

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".

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Thu, 4 Aug 2005 08:06:46 -0400

> directive by trimming the content".

What's the problem with that? That discourages sloppy feed generation,
while acknowledging what Atom Processors actually do (yes, already. we
don't actually have a choice).

Robert Sayre

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Aug 2005 14:06:33 +0200

>directive by trimming the content".

Exactly: that's the MAY.

--Paul Hoffman, Director

---

From: Tim Bray <[email-masked]>
Date: Thu, 04 Aug 2005 05:07:43 -0700

> not allow leading and/or trailing whitespace, such as IRIs and  

The more I think about this family of suggestions, the less I like  
them.  There is no coherent argument from the published  
specifications of XML and IRIs that allows our 4.2.6 language "Its  
content MUST be an IRI" to regard

<atom:id>
http://example.com/foo
</atom:id>

as anything but an error.  I suggest an alternate formulation:
===========================================================

"Implementors are advised that there is a common class of error in  
which, when the content of an element is specified as being an IRI,  
software which generates Atom documents introduces spurious white  
space before and after the IRI, for example:

<atom:id>
  urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6
</atom:id>

In this case, since [RFC3987] makes it clear that the leading and  
trailing white space cannot be part of the IRI, implementors MAY  
choose to be forgiving in regards to this error, by ignoring the  
leading and trailing white space."
===========================================================

I'm strongly -1 on treating this as anything but an error.  We may at  
our discretion make it forgiveable.  This formulation would also  
allow the feed validator to complain.

I suppose if we did this, we should generalize it slightly to apply  
to date constructs as well. -Tim

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 04 Aug 2005 13:31:07 +0100

Tim Bray wrote:

> 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 it because I just see it as equivocation.

cheers
Bill

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 04 Aug 2005 14:42:31 +0200

>"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 allows
people to argue that compliance with this particular requirement is
not relevant in practise so they can worry less about compliance in
general.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: James Aylett <[email-masked]>
Date: Thu, 4 Aug 2005 14:09:18 +0100

+1

I don't entirely see why having the MUST in place doesn't satisfy this
anyway, providing we point out explicitly that whitespace around URIs
and dates is an error. This puts a clear restriction on compliant Atom
document producers, but lets consumers deal with not-quite-Atom documents
that break this particular MUST in any way these choose fit. Some will
catch fire. The feed validator will fault them. Others may choose to
strip whitespace, in a kind of Postel-like fashion.

If this needs pointing out to people writing Atom consuming
applications, then it's a job for implementation guidelines in a
separate document. That's how I'd expect this sort of thing to be
handled in any other IETF spec, certainly; otherwise, as pointed out,
no matter what language we use we run the risk of non-conformant Atom
documents being considered 'blessed' by our wording.

We don't spell out what Atom consumers should do if they encounter a
Date construct with "Last Thursday" in, either. Pointing out the
common error AS AN ERROR should be sufficient IMHO.

J

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Aug 2005 15:38:52 +0200

>not relevant in practise so they can worry less about compliance in

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".

--Paul Hoffman, Director

---

From: Robert Sayre <[email-masked]>
Date: Thu, 4 Aug 2005 09:53:05 -0400

On 8/4/05, Paul Hoffman <[email-masked]> 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. I slightly prefer
documenting and allowing what the world's PHP scripts have been
observed to produce, but either way is fine. BTW, my proposed text was
taken from HTML 4.01.

Robert Sayre

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 04 Aug 2005 15:56:38 +0200

>but I am open to "just fail".

Well, if we expect that many content providers will consider the content
model of atom:id elements to be "IRI with optional surrounding white
space" then we define the content model accordingly. Hardcoding "We know
many people will ignore this, but the content model is 'IRI *without*
optional sourrounding white space'" doesn't make any sense.

Of course, content providers would pay more attention to the requirement
if Atom implementations must not (and in practise will not) provide the
content of feeds or entries with such a non-conforming atom:id to users,
so that might indeed be an option too, though I'm not sure how likely it
is that implementers follow such a requirement.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Danny Ayers <[email-masked]>
Date: Thu, 4 Aug 2005 17:45:59 +0200

> > that the content must be exactly equal to the IRI. 

My reading too.

> spec's end-users. 

Why is it particularly likely to happen?

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 not expressable in the
grammar).

But now the issue has been raised, it does seem reasonable to add a
note (assuming the process is ok for that) to the effect that stray
whitespace in content is an error. I can't see how it can be desirable
to allow it (though am not given to lying in the road).

At the application level we're back to Postel again - publishers
shouldn't pump this stuff out,  but liberal clients may find it useful
to trim whitespace from IRI and date fields. But surely that's outside
the scope of the format spec itself.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 4 Aug 2005 18:22:22 +0200

* James Aylett <[email-masked]> [2005-08-04 15:25]:
> > >"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 allows people to argue that
> > compliance with this particular requirement is not relevant
> > in practise so they can worry less about compliance in
> > general.
> 
> +1
> 
> […]
> 
> We don't spell out what Atom consumers should do if they
> encounter a Date construct with "Last Thursday" in, either.
> Pointing out the common error AS AN ERROR should be sufficient
> IMHO.

+1 to James and Bjoern.

    There Is Only MAY, SHOULD And MUST.

I want to remind everyone that the spec’s job is to say exactly
what the bits mean, rather than what people should do with them.
It therefore strikes me as foolish to be coy about what
constitutes an error. Telling implementors that they KINDA MUST,
PROBABLY comply serves noone. An error is an error is an error.

Regards,

---

From: Tim Bray <[email-masked]>
Date: Thu, 04 Aug 2005 09:31:55 -0700

> observed to produce, but either way is fine. BTW, my proposed text was

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  
make the meanings of "element", "content", and "IRI" not really open  
to intelligent dispute.  I claim that text enjoyed strong, not rough,  
consensus support from the WG.

So my preferred course of action would be to leave it the way it  
bloody well is.  The Feed validator should throw whitespace-polluted  
pseudo-Atom on the floor, and if some bozos persist in producing it,  
and some implementors decide to work around this error, well, that's  
the way the Internet is.  But if a couple of leading implementations  
decide to be strict, and the producers develop a culture of Doing The  
Right Thing, well then, that's the way the Internet is too,  
sometimes.  PHP is, if nothing else, flexible and friendly to quick  
changes in deployed scripts, I can hear a zillion publishing-system  
hackers grumbling "Oh, it's that damn tight-assed Atom stuff, guess I  
have to use mod_finicky here".

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 I'm in a small minority here.  -Tim

---

From: Dave Pawson <[email-masked]>
Date: Thu, 04 Aug 2005 19:21:14 +0100

> Why is it particularly likely to happen?

Because there is nothing to 'see' that looks wrong Danny,
  and relaxNG has nothing that allows both text (ws) and anyURI to mix.
I think  that means it needs sneaky words to state it;
or tee people off by failing content that 'looks' good.

regards DaveP

---

From: Dave Pawson <[email-masked]>
Date: Thu, 04 Aug 2005 19:24:24 +0100

On Thu, 2005-08-04 at 09:31 -0700, Tim Bray wrote:

> better. 

> shouting if I'm in a small minority here.  

It's clean, except I'd like an informative statement for people
failing and wondering why.

And something in the schema that lets people know why, since  we
can validate against the schema and *pass*?
  Now that could be confusing.

regards DaveP

---

From: Julian Reschke <[email-masked]>
Date: Thu, 04 Aug 2005 20:41:49 +0200

>   Now that could be confusing.

+1 on both (not changing the semantics, but possibly adding a warning 
that whitespace *really* is significant here).

regards, Julian

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 4 Aug 2005 14:55:09 -0400

> grammar, as there's a lot of other stuff not expressable in the

"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 is quoted directly from Section 1.3.

This whitespace issue is a good illustration of why the schema isn't
normative ;)

I would vote for leaving the text as is and having the validator give
errors on whitespace.

We have the same issue with dates and believe they should be flagged
likewise, i.e. errors on whitespace.

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: James M Snell <[email-masked]>
Date: Thu, 04 Aug 2005 12:17:06 -0700

+++1

---

From: Sam Ruby <[email-masked]>
Date: Thu, 04 Aug 2005 16:04:20 -0400

Tim Bray wrote:
> 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  make
> the meanings of "element", "content", and "IRI" not really open  to
> intelligent dispute.  I claim that text enjoyed strong, not rough, 

I believe that the term "content" is open to intelligent dispute.
Apparently the authors of RFC3470/BCP70 believe so too.

I won't dispute your read on the consensus of the working group, but I
would like to request that *SOME* language be present in the spec that
makes this clear.

- Sam Ruby

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 4 Aug 2005 22:32:22 +0200

* Tim Bray <[email-masked]> [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
> from the WG.

And that stance appears not to have changed.

> 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 I'm in a small minority here.

No, you’re in the unanimous majority.

What people aren’t sure about is what the spec text means, as it
stands. And if the WG can get into such a long discussion about
it, that does not bode well for the spec’s interpretation by
implementors.

The call, therefore, is not to weaken the spec in any fashion,
rather just to make it more explicit about intent.

Further, having raised this issue with atom:id, it seems prudent
to add the same clarification to the text for atom:updated and
friends.

Regards,

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 04 Aug 2005 22:32:02 +0100

0. The validator isn't the spec.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 04 Aug 2005 22:45:26 +0100

Tim Bray wrote:
> So my preferred course of action would be to leave it the way it  bloody
> well is.  [...]
> 

Fine by me. However, "extraneous whitespace will cause compliant
software to puke" needs to be said, not inferred. I don't believe the
text here is as broadly obvious or as well-understood as you suggest.

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Thu, 04 Aug 2005 20:11:09 -0400

> 0. The validator isn't the spec.

+1 to the sentiment that the validator isn't the spec.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Thu, 4 Aug 2005 22:24:23 -0400

> 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

Agree. 

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
scanner-like state machine. Leading and trailing whitespace input for
these fields should be discarded by a robust scanner, and doing so
proposes no risk to compliant feeds, unlike guessing the "true
meaning" of an ampersand in an RSS feed. So, it will be my
recommendation to ignore this MUST-level requirement of the Atom spec
in any consumer aggregator that I contribute to. I think it might be
useful as bozo filter in an Atom protocol server, because the lazy
thing for client implementors to do is find a decent serialization
library. The lazy thing for publishers to do is concatenate strings in
their loosely-typed language of choice.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 05 Aug 2005 11:31:28 +0100

> their loosely-typed language of choice.

If you're going to recommend ignoring it in practice, why not recommend
throwing it out? Why equivocate?

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Fri, 05 Aug 2005 04:53:59 -0700

On Aug 4, 2005, at 7:24 PM, Robert Sayre wrote:

> Leading and trailing whitespace input for

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? -Tim

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 05 Aug 2005 14:12:35 +0100

> end up with a free ampersand or something worse in their Atom feed.  

Right. Doesn't mean everyone (statistically speaking) isn't doing it.
Using templating languages to generate feeds comes to mind.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Fri, 5 Aug 2005 09:59:10 -0400

> throwing it out? Why equivocate?

You keep saying "equivocate", as if there were some hard-to-swallow
truth I'm avoiding. I'm suggesting saying something vague because the
situation is vague, it doesn't matter very much, and I don't consider
detailed information oh whitespace in XML feeds to be the Purpose Of
Atom.

I'm going to recommend ignoring it to people writing Atom processors
with the intent of consuming a wide variety of feeds for consumer
usage. My favorite use case is Grandmother Trying To View Pictures Of
Her Grandchildren. Am I going to prevent that from happening in order
enforce a whitespace rule? Since there are no compliant feeds I'm
hurting, it's an easy decision to make.

That said, I know from experience that it's very easy to write an Atom
Processor that would choke on such whitespace. I would like for those
processors to be supported by the spec as compliant, because writing
one should not have to be an exercise in Keep-Going-No-Matter-What
consumer software in all cases. I don't really care how they are
supported (MAY, SHOULD, MUST...), because it doesn't matter. We do
need to write something that lets the feed validator warn people about
it, but actually trying to enforce a MUST-level requirement here seems
like pissing into the wind.

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 5 Aug 2005 18:08:22 +0200

* Tim Bray <[email-masked]> [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, after all, a
DOM serializer doesn’t do anything else. The strategy is to
establish which concatenations expect XML fragments and which
expect content, and to be diligent about turning the latter into
the former when such is expected, by way of escaping. It’s the
<http://www.tbray.org/ongoing/When/200x/2004/03/16/EscMad>
strategy.

I’ve written that sort of code more times than I care to count
and I’ve never had an escaping bug in it. It’s trivial. So just
because someone’s concatenating strings in a template doesn’t
mean they’re lazy or dumb, but they can still fall for this trap.

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 says the same thing more
explicitly.

In addition, the same minimal change should be applied to

* 3.2.2 (The "atom:uri" Element)
* 3.2.3 (The "atom:email" Element)
* 3.3 (Date Constructs)
* 4.2.5 (The "atom:icon" Element)
* 4.2.8 (The "atom:logo" Element)

which all contain either a URI, an ISO date, or an email address.

Regards,

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 05 Aug 2005 17:01:15 +0100

Robert Sayre wrote:
> truth I'm avoiding. 

I've said it twice; don't take it personally it's not an attack.

> I'm suggesting saying something vague because the

The siutation didn't just happen to be vague, we made it vague, I don't
agree it doesn't matter, and if the Atom spec can't get it's story
straight on whitespace to the extent one of the editors is going to
advise people to ignore a MUST directive that one of the chairs and
others believes has strong consensus support from the WG, then I firmly
believe that puts detailed information on whitespace on the table.
Finally, if there is a Purpose Of Atom I suspect it has something to do
with clarity and unambiguity in specification - and this is not it.

> like pissing into the wind.

I read that as saying we have a broken spec. If there's another way to
read it, help me out. This entire thread is like being in a Joseph
Heller novel, except its called Catch-32.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Fri, 05 Aug 2005 09:20:09 -0700

>It doesn’t change anything, it just says the same thing more
I'm not convinced that we need "MUST NOT contain any whitespace".  How 
about something along the lines of:

   "Its content MUST be an ..., and SHOULD NOT contain any whitespace. 
Software written to conform to this version of the specification MUST 
remove all leading and trailing whitespace that happens to appear in the 
value."

Ok, so the wording can be cleaned up a bit, but you get the point.  With 
this language, the validator can flag a warning if whitespace does 
appear but conformant parsers can be written to handle cases when 
whitespace does appear.  This also shifts the burden of ensuring correct 
handling of whitespace to the feed reader rather than the feed producer 
which is significantly better IMHO.

+1

>Regards,
- James

---

From: Robert Sayre <[email-masked]>
Date: Fri, 5 Aug 2005 12:25:08 -0400

On 8/5/05, Bill de hÓra <[email-masked]> wrote:
> advise people to ignore a MUST directive 

To be clear, I would not go shouting this opinion from the rooftops. 

> that one of the chairs and

Paul, Tim, and I have all proposed text. All of them communicate the
reality, and they would all do the job. Graham +1ed Sam's idea, but
there was no spec text there. Mnot has pointed out we should write
something, because of the BCP, so let's just write something, like
now.

Robert Sayre
Robert Sayre

---

From: Walter Underwood <[email-masked]>
Date: Fri, 05 Aug 2005 14:37:02 -0700

--On August 4, 2005 9:31:55 AM -0700 Tim Bray <[email-masked]> wrote:
>
> 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 I'm in
> a small minority here.  -Tim

Wow, this string has made my "away on vacation" mailbox fatter.

I strongly favor making white space around IRIs illegal in Atom, whether
they are an ID or somewhere else. Same for dates.

This follows the robustness principle, where we are conservative in what
we generate. Atom processors are free to be liberal in what they accept,
so they can strip whitespace. Or not, I don't care.

Note that a feed with whitespace around an IRI can never be aggregated
into another feed, because a) the ID IRI cannot be changed, and b) the new
feed cannot cannot contain whitespace.

Making every single processor strip whitespace smells too much like
the HTML tag soup processors that we all have to maintain. Yuk.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Tim Bray <[email-masked]>
Date: Sun, 07 Aug 2005 22:58:15 -0700

On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote:

>> make

Could you reference that?  It seems to me that the guidance we should  
take from 3470 is from section 4.16, which seems to me to make it  
clear that *we* should make it clear that

<id>
  http://example.com/foo
</id>

is an error and nothing but an error. -Tim

---

From: Tim Bray <[email-masked]>
Date: Sun, 07 Aug 2005 23:00:37 -0700

On Aug 3, 2005, at 6:04 AM, Sam Ruby wrote:

> <atom:id>&#104;&#116;&#116;&#112;&#58;&#47;&#47;&#101;&#120;&#97;&#109 
> ;&#112;&#108;&#101;&#46;&#99;&#111;&#109;&#47;&#102;&#111;&#111;</ 
> atom:id>

I believe this is incorrect, see http://www.w3.org/TR/xml-infoset/ 
#omitted, item 6

> <atom:id>http://example.com/foo</atom:id>

I believe this is incorrect, see http://www.w3.org/TR/xml-infoset/ 
#omitted, item 19

Or am I missing something obvious? -Tim

---

From: Sam Ruby <[email-masked]>
Date: Mon, 08 Aug 2005 07:28:21 -0400

Tim Bray wrote:
> take from 3470 is from section 4.16, which seems to me to make it  clear
> that *we* should make it clear that
> 
> <id>
>  http://example.com/foo
> </id>
> 

My point was simply that *we* should make it clear.  Either of the texts
that Rob proposed [1] is sufficient for my purposes.

You appear to have a strong preference for #2, and a strong aversion to
#1.  I haven't heard anybody opposed to #2.  This seems to me to be to
be a sufficient basis for the chairs to declare (re-affirm?) consensus
on this matter.

If either is adopted, I will simply add a slew of tests to [2], ensure
that they pass, and commit the change.

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg16616.html
[2] http://feedvalidator.org/testcases/atom/2/

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Mon, 8 Aug 2005 07:38:33 -0400

> -----Original Message-----
> From: Tim Bray [mailto:[email-masked]] 
> Sent: Monday, August 08, 2005 1:58 AM
> To: Sam Ruby
> Cc: [email-masked]
> Subject: Re: spec bug: can we fix for draft-11?
> 
> 
> 
> better and

That's my interpretation of what we (the authors of 3470) wrote, too.
Knowing that white space is significant, you guys need to explain what to do
with it.

-Scott-

---

From: Dave Pawson <[email-masked]>
Date: Mon, 08 Aug 2005 19:11:35 +0100

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 white
space before or after a date time value
      </s:assert>
      <ref name="atomDateConstruct"/>
    </element>

Unfortunately, as of this release, relames doesn't
support Schematron assert statements for attribute
values, which is required for uri's.

C'est la vie

[1]https://msv.dev.java.net/

regards DaveP

---

From: Henri Sivonen <[email-masked]>
Date: Tue, 9 Aug 2005 09:01:04 +0300

> This whitespace issue is a good illustration of why the schema isn't

This thread makes me wonder if taking the schema seriously enough to 
actually encourage validation against the schema causes more harm than 
good. Perhaps I should remove the Atom schema from the presets of 
http://hsivonen.iki.fi/validator/ .

> I would vote for leaving the text as is and having the validator give

ITYM, the Feed Validator and not a RELAX NG validator.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 15 Aug 2005 11:46:09 -0400

The "Introduction to The Atom Syndication Format" indicates that atom:source
is an "optional" element of atom:entry. While this is indicated by the "MAY"
in the first sentence of the specification's description of atom:source, the
second sentence, by using "SHOULD", would seem to indicate that in some
circumstances, atom:source is a recommended element. The text I refer to is:

4.2.11: "Such metadata SHOULD be preserved if the source atom:feed contains
any of the child elements atom:author, atom:contributor, atom:rights, or
atom:category and those child elements are not present in the source
atom:entry."

I suggest that the Introduction cover atom:source in the "recommended"
section and highlight the case in which it is recommended.

	bob wyman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sam Ruby
Sent: Monday, August 01, 2005 10:39 PM
To: [email-masked]
Subject: Introduction to The Atom Syndication Format

Feedback welcome.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Mon, 15 Aug 2005 12:42:16 -0400

> section and highlight the case in which it is recommended.

Disagree. The introduction is for newbies. Folks implementing
synthetic feed services (the case in which it is recommended) have to
read the real spec.

Robert Sayre