Re: [Fwd: Using XMLNS in link/@rel]

I understand the problem here. It would be nice to be able to use the 
same @rel syntax in both HTTP Link:, HTML 4 and XHTML Link elements. But 
you can't:  HTTP and HTML 4 have no way to define a namespace. XHTML 
does, of course, and that's where the RDFa comes in. So I wonder whether 
this is really 'all that bad?'

It's an irritating fact of life that the ATOM registry and the RDFa @rel 
values [1] are not the same but at least they don't actually contradict 
each other. Where the same term exists in both, it means the same thing 
(e.g.  next) and the synonyms (first cf. start) are, well, just 
irritating, but that's life.

So although sloppiness may lead some people to put cc:morePermissions in 
an HTTP Link: header, it's clearly incorrect. Whereas 
rel="http://creativecommons.org/ns#morePermissions" is fine for everyone.

Link: can't support Curies - but it doesn't have to. RDFa isn't going to 
change, but it doesn't have to either. HTML doesn't support namespaces 
and so shouldn't be using Curies anyway. If people do, it may lead to 
unexpected results. C'est la guerre mes amis.

Or am I missing the elephant in the room here? (not unknown I know...)

Phil.

[1] http://www.w3.org/TR/rdfa-syntax/#relValues
[2] http://www.iana.org/assignments/link-relations/link-relations.xhtml


Mark Nottingham wrote:
> 
> Hello Steven,
> 
> On 27/02/2009, at 9:06 PM, Steven Pemberton wrote:
> 
>> On Fri, 27 Feb 2009 10:31:57 +0100, "Mark Nottingham" <mnot@mnot.net> 
>> said:
>>> Creative Commons just released a new spec:
>>>   http://wiki.creativecommons.org/Ccplus
>>> that has markup in this form:
>>>   <a xmlns:cc="http://creativecommons.org/ns#"
>>> rel="cc:morePermissions" href="#agreement">below</a>
>>> (in HTML4, one assumes, since they don't specify XHTML, and this is
>>> what the vast majority of users will presume).
>>
>> In the link you refer to they don't specify either, but I imagine they 
>> mean XHTML,
> 
> I will wager any amount of money you care to name that more than 99% of 
> the document's readers (as it stands) will assume HTML4.
> 
> 
>> and I'm sure Ben Adida of CC can speak up here.
>>
>>> However, it appears that they adopted this practice from RDFa;
>>>   http://www.w3.org/TR/rdfa-syntax/#relValues
>>> which, in turn, *does* rely upon XHTML. However, XHTML does *not*
>>> specify the @rel value as a QName (or CURIE, as RDFa assumes);
>>> http://www.w3.org/TR/2008/REC-xhtml-modularization-20081008/abstraction.html#dt_LinkTypes 
>>>
>>> "Note that in a future version of this specification, the Working
>>> Group expects to evolve this type from a simple name to a Qualified
>>> Name (QName)."
>>>
>>> So, that's an expectation, not a current specification.
>>
>> In fact it is a current specification. RDFa specifies a version of 
>> XHTML that defines the meaning of CURIEs in rel and rev values. Note 
>> that this is also not invalid HTML4 (which also allows such values in 
>> a rel - they are CDATA - but doesn't specify what they mean).
> 
>   http://www.w3.org/TR/rdfa-syntax/
> refers to
>   http://www.w3.org/TR/2001/REC-xhtml11-20010531/
> which contains
>   http://www.w3.org/TR/2001/REC-xhtml11-20010531/doctype.html
> which refers to, for the Hypertext module (note 'latest version' URI):
>   
> http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_hypertextmodule 
> 
> which leads back to
>   http://www.w3.org/TR/xhtml-modularization/abstraction.html#dt_LinkTypes
> i.e., the same, albeit most recent (instead of versioned) URI for
>   
> http://www.w3.org/TR/2008/REC-xhtml-modularization-20081008/abstraction.html#dt_LinkTypes 
> 
> 
> Even taking the other road and going with the contemporary version,
>   
> http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/abstraction.html#dt_LinkTypes 
> 
> it's still just short names, with no reference to CURIEs or QNames at all.
> 
> What am I missing?
> 
> The only place I see this defined is in the RDFa syntax document itself 
> -- do you mean that is the specification of authority? I note that it 
> specifies /html/@version="XHTML+RDFa 1.0", and it has its own DTD, so in 
> a way I suppose it's not really an extension to XHTML, but a 
> re-definition of it...
> 
> 
>>> Of course, this conflicts with the Link draft;
>>>  http://tools.ietf.org/id/draft-nottingham-http-link-header-04.txt
>>> which we've worked pretty hard to come to consensus on across a broad
>>> selection of communities (Atom, POWDER, OAuth, HTTP, and
>>> optimistically, HTML5).
>>>
>>> A few observations and questions;
>>>
>>> 1) I'm more than happy to specify in the Link that in XHTML, a link
>>> rel value is indeed a QName, if XHTML chooses to take that position
>>> (although I believe a URI is a better fit than a QName here, as in
>>> most other places). Can we get a current reading from the XHTML world
>>> on this?
>>
>> A CURIE is a URI not a QName, so you're OK.
> 
> I haven't paid a lot of attention to them to date, but as far as I can 
> see, a CURIE is most definitely not a URI; at most, it's a shorthand for 
> one.
> 
> 
>> CCing the XHTML2 WG and/or RDFa group would have helped in this case 
>> if you wanted a response from them :-)
> 
> I wanted to get a feel from an architectural standpoint before talking 
> to WGs about potentially irrelevant problems, but point taken.
> 
> 
>>> 2) However, it seems like RDFa is jumping the gun by assuming @rel is
>>> a CURIE right now.
>>
>> See above. It is already a Rec.
>>
>> [All the rest snipped since it was based on the assumption that 
>> XHTML+RDFa isn't a Rec].
> 
> As I said before, the third point is IME the most concerning. Having two 
> subtly incompatible syntax for the same attribute in HTML and XHTML 
> isn't a great situation, but assuming that one is valid to use in the 
> other is far more troublesome.
> 
> Cheers,
> 
> -- 
> Mark Nottingham     http://www.mnot.net/
> 
> 
> 

-- 

Phil Archer
http://philarcher.org/

i-sieve technologies                |      W3C Mobile Web Initiative
Making Sense of the Buzz            |      www.w3.org/Mobile

Received on Friday, 27 February 2009 11:52:52 UTC