Re: @rel syntax in RDFa (relevant to ISSUE-60 discussion), was: Using XMLNS in link/@rel

On 1/3/09 20:13, Rob Sayre wrote:
> On 3/1/09 2:09 PM, Dan Brickley wrote:
>>> Do you mean it won't work technically, or that it would be using the
>>> attributes in a way that's unintended? RDFa already uses XML Namespaces
>>> and HTML in ways that those specifications don't cover. What's different
>>> about my example?
>>
>>
>> This option has been bounced around a few times on the HTML and WHATWG
>> lists. The general consensus seemed to be that this wasn't what data-
>> attributes were intended for. Of course the HTML5 spec is still in
>> flux, and they could be redefined to do this kind of thing too.
>> Whether that would be a good idea, I don't know.
>
> My question was about what's different from the current RDFa strategy of
> using other specifications in ways that weren't intended. Even in XHTML,
> using QNames in content is a flagrant layering violation, and certainly
> unintended by XMLNS. So I think your answer didn't really address my
> question.

Sorry, I took it as a rhetorical question. I lost interest in the idea 
of using the data- mechanism when there was little encouragement from 
HTML5 experts to explore those options.

Re qnames and qname-like mechanisms, ... I have (nearly) always been 
pretty squeamish. But the RDFa and CURIE design had plenty of review and 
discussion, here and around W3C. If it is a flagrant layering violation, 
it shouldn't have gone to REC. But it seems enough folk could live with 
it, even though there are difficulties / risks. FWIW we discussed the 
options for something similar back in 1998 for RDF/XML (I initially 
propoposed it, but changed my mind).

What's different now? RDFa had to do *something*. It seems the TAG and 
W3C AC and other reviews found the tradeoff acceptable. Lots of pieces 
of the puzzle were already frozen. HTML5 is different in that it is not 
frozen, and there is active ongoing dialog with the people working on 
it. Wilfully stretching the meaning of brand new language constructs 
(data-foo) while they're already undeployed and their spec is still in 
flux, just seems a bit silly. Why not just change them.

> However, unlike XMLNS, we could change the HTML5 text. Those attributes
> are obviously going to leak all over the place, so I can't see how it
> would matter.

Yup

> Here's my suggestion:
>
> "Custom data attributes store data for which there are no appropriate
> attributes or elements. Authors should be aware that these HTML5 has no
> facilities to protect against naming collisions in the data- namespace."
>
> data-rdfa- seems very unlikely to collide with anything.

This is pretty close to the current proposal floating around for 
stuffing prefix to URI bindings into a non-xmlns attribute. Just it 
involves tweaking the prose definition of data-* rather than adding a 
new attribute.

cheers,

Dan

Received on Sunday, 1 March 2009 19:51:59 UTC