« Return to Thread: HTML+RDFa Issues (update)
Re: HTML+RDFa Issues (update)
by Julian Reschke
::
Rate this Message:
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
> 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
« Return to Thread: HTML+RDFa Issues (update)
| Free embeddable forum powered by Nabble | Forum Help |
