W3C home > Mailing lists > Public > www-tag@w3.org > February 2009

Re: Using XMLNS in link/@rel

From: Shane McCarron <shane@aptest.com>
Date: Fri, 27 Feb 2009 03:32:47 -0600
Message-ID: <49A7B33F.6060308@aptest.com>
To: Mark Nottingham <mnot@mnot.net>
CC: "www-tag@w3.org WG" <www-tag@w3.org>
I will try to write more on this later.  However, Mark, please note that 
RDFa is not proposed.  It is a W3C Rec.  And CURIEs are not a future 
direction of @rel in XHTML - they are state of the art.  The RDFa Syntax 
Recommendation codifies this in an XHTML M12N module (Metainformation 
Attributes) and all current and future XHTML 2 Working Group activities 
assume this to be the case.  This is why we raised the issue of the 
@rel/@rev value registry at http://www.w3.org/1999/xhtml/vocab with you 
all months ago.  Moreover, this use of CURIEs is now widely deployed in 
the semweb community with regard to XHTML.  In the context of HTML there 
is continuing discussion, but within the XHTML 2 Working Group and the 
RDFa Task Force we have identified a potential path forward that 
accommodates the concerns of the HTML community with regard to the use 
of @xmlns:* for prefix mapping declarations. 

[1] http://www.w3.org/TR/rdfa-syntax
[2] http://www.w3.org/MarkUp/Drafts#xhtml2

Mark Nottingham wrote:
> 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).
>
> 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.
>
> 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?
>
> 2) However, it seems like RDFa is jumping the gun by assuming @rel is 
> a CURIE right now. This is not promoting interoperablity or shared 
> architecture, because no XHTML processor that isn't aware of RDFa can 
> properly identify these link relations. My preference would be an 
> erratum to RDFa removing this syntax, replacing them with a 
> self-contained identifier (i.e. a URI). Thoughts?
>
> 3) CC's adoption of *proposed* XHTML conventions from RDFa into HTML4 
> via CURIEs further muddies the waters; xmlns has no meaning whatsoever 
> in HTML4, so they're promoting bad practice there by circumventing the 
> specified Profile mechanism. I find this aspect of this the most 
> concerning, and it needs clarification (more colourful words come to 
> mind, but I'll leave it there for now).
>
> Thanks,
>
> P.S., I realise that this involves at least three additional 
> communities, but the TAG seems like the logical place for the initial 
> discussion and eventual coordination of this issue.
>
> -- 
> Mark Nottingham     http://www.mnot.net/
>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Friday, 27 February 2009 09:34:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:12 GMT