Re: HTML+RDFa Issues (update)

Manu Sporny wrote:
> Julian Reschke wrote:
>>> The technical issue is that it is theoretically possible to construct
>>> a rel value which has a list of URIs which could be accidentally
>>> interpreted as a list of CURIEs.  Consider the following:
>>>
>>> <a xmlns:urn="http://purl.org/dc/terms/"
>>>    rel="urn:rights urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"
>>>    href="http://example.com/terms_of_service.html" >
>>>
>>> My take: while it is possible to construct such examples, in practice
>>> they would be rare enough to not be an issue.  That being said, it is
>>> nearly impossible to legislate against, as it would require people to
>>> avoid declaring namespaces prefix that matches any current or future
>>> URI scheme.  Perhaps a "SHOULD avoid well known URI schemes" might be
>>> in order.
>> That would deal with collisions; but not with the fact that existing,
>> non-RDFa consumers, will not expect that an indirection mechanism has
>> been added.
> 
> Julian, assume that we adopt the language the Sam has specified above.
> 
> Why would existing non-RDFa consumers need to know or care? Does it
> create any sort of technical issue with pre-existing HTML consumers that
> we know about? Wouldn't existing consumers merely ignore the CURIE
> values or do nothing with them? Which current HTML parser or toolchain
> implementation are we concerned about affecting?

I'm concerned about consumers that treat the contents of @rel as a set 
of whitespace-separated tokens, thus seeing "urn:rights" (incorrect) and 
"urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a" (correct) in the example 
above.

BR, Julian

Received on Thursday, 9 July 2009 14:29:26 UTC