Sam Ruby wrote:
Manu Sporny wrote:
= Use of regular CURIEs in @rel =
I believe that Julian Reschke has raised this issue several times. I
don't remember the technical issue and I remember Ben stating clearly
that there isn't a technical issue.
I don't have any input on this at the present time. Clearly, if a
technical issue exists with CURIEs in @rel - we must address it.
If I remember correctly, the issue that Julian raised is that a number
of potential "consumers" have created multiple, potentially incompatible
ways of interpreting the value of the rel attribute. Some may interpret
it as a list of tokens, some as a list of URIs, and some as a list of
CURIEs.
Indeed. Note that the two interpretations are somewhat compatible, while
the CURIE interpretation is not.
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.
(And yes, I'm familiar with the P.O.V. that HTML4 requires new rel
values to be opted-in through a @profile; however the real world shows
almost nobody has been doing it, *including* RDFa).
BR, Julian
