Subject: nit: spaces in link@rel?

From: Eric Scheid <[email-masked]>
Date: Fri, 13 May 2005 02:23:34 +1000

Is this legal according to our spec-08?

    <link rel="foo bar" .../>

According to the spec, @rel can contain either isegment-nz-nc or IRI values,
where isegment-nz-nc is also described as atomNCName, which is defined in
Appendix B (RELAX NG Compact Schema) as

    atomNCName = xsd:string { minLength = "1" pattern = "[^:]*" }

Both isegment-nz-nc and atomNCName allows all characters except the colon.
This means a string containing a space is permitted, and the @rel above of
"foo bar" is actually just one relationship, not two delimited by a space.

This is confusingly different from HTML's link@rel and should be fixed.

e.

---

From: Graham <[email-masked]>
Date: Thu, 12 May 2005 18:32:13 +0100

> This is confusingly different from HTML's link@rel and should be  

I believe the intention is that only one value is allowed, and any  
whitespace included is part of the name of the rel value. Perhaps  
this should be noted in the spec.

Or are you suggesting we adopt the HTML method?

Graham

---

From: Eric Scheid <[email-masked]>
Date: Fri, 13 May 2005 04:10:41 +1000

> Or are you suggesting we adopt the HTML method?

perhaps, but it's late, we're in last call, and I'm too tired.

I would be happy with allowing only one value, but with that value not
including space characters. At least that way we won't be building in
breakage if in a future spec the idea of space delimited values is proposed.

e.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 12 May 2005 12:30:55 -0600

From 4.2.9.2  The "rel" Attribute:
> 	The value of "rel" MUST be string that is non-empty, and matches the
> 	"isegment-nz-nc" or "IRI" production in [RFC3987].

If I'm reading RFC3987 correctly, isegment-nz-nc does not include 
spaces, so I think @rel as spec'd can only contain one value and no 
whitespace.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 13 May 2005 05:30:33 +1000

On 13/5/05 4:30 AM, "Antone Roundy" <[email-masked]> wrote:

> spaces, 

hmmm - caveat lector.

> so I think @rel as spec'd can only contain one value and no
> whitespace.

but that then means isegment-nz-nc != atomNCName

which is easy to fix

    atomNCName = xsd:string { minLength = "1" pattern = "[^: ]*" }

e.

---

From: Thomas Broyer <[email-masked]>
Date: Thu, 12 May 2005 22:39:42 +0200

>     atomNCName = xsd:string { minLength = "1" pattern = "[^: ]*" }

The RNC is not normative and, actually, your modified atomNCName does 
not match isegment-nz-nc either.

Something approaching might be xsd:NMTOKEN (which might later be 
"extended" to xsd:NMTOKENS to allow space-delimited lists of NMTOKEN) or 
xsd:NCName. I've not checked but I think they accept the same list of 
characters (especially the "ucschar" production of RFC3987).
Note that none of them accepts percent-encoded characters. This is IMO a 
good thing and it should be enforced by the Atom spec. Having names 
matching xsd:NMTOKEN or xsd:NCName should be enforced by the IANA 
"relations" registry process and/or the Atom spec (I'm not used to the 
IANA stuff and don't know how values will be later added to the 
"relations" registry).

-- 
Thomas Broyer

---

From: Kevin Marks <[email-masked]>
Date: Tue, 17 May 2005 00:27:17 -0700

-1
This is a gratuitous variation from exisiting practice. As you may have 
noted from previous work, allowing multiple rel values enables a great 
deal of useful flexibility in HTML.
On May 12, 2005, at 10:32 AM, Graham wrote:

> whitespace included is part of the name of the rel value. Perhaps this 
> should be noted in the spec.
>