Hi Mark,
thanks for doing this work. You know I'm not happy with anything that
leaves ambiguity, but it certainly is a step into the right direction.
Some comments in-line.
Mark Birbeck wrote:
...
FALSE POSITIVE CURIES
The scenarios that seems to be causing concern is that when a URI
begins with the same string as a prefix mapping, it creates a 'false
positive' CURIE.
Using Julian's example:
...
I think it was Sam's...
...
The problem with this example is that it is relying on a situation
that won't arise to make its point; as RDFa stands at the moment, why
would anyone place a URI into the @rel or @rev attribute? Nothing in
the spec gives the impression that URIs are valid in @rel, and no
other host languages seem to indicate this either.
...
But then the host languages do not disallow it either.
...
This creates a lot of extra work, and in particular makes
cut-and-paste examples more difficult. An obvious question then is why
RDFa doesn't simply support this kind of mark-up:
<div about="#me" typeof="http://xmlns.com/foaf/0.1/Person";>
<a rel="http://xmlns.com/foaf/0.1/knows";
href="http://www.w3.org/People/Ivan/#me";
>Ivan Herman</a>
</div>
...
Indeed!
WAY BACK...
This is a pretty obvious technique, so it probably won't surprise
anyone that it was considered...way back. :)
The problem we had at the time we discussed this was that if we went
for URLs in @rel, then we'd need to go for safe-CURIEs also. And that
then raised problems with the pre-existing tokens from HTML
...
Interesting...
...
The issue is, how would we know when we had a relative path, and when
we had a reserved value:
@rel="next"
@rel="relative-url"
...
Could you elaborate on why this matters?
At the time, the only solution we could think of was to insist on
safe-CURIEs for all non-URI values:
@rel="[next]"
@rel="[dc:rights]"
@rel="relative-url"
Why not simply state that something that looks like an absolute URI/IRI
*is* one, and that everything else is a token?
...
DIFFERENTIATING BETWEEN CURIES AND URIs
Interestingly enough, it is possible to solve this problem, by simply
saying that any string of characters that begins with a predefined
prefix is a CURIE, and anything else is a URI.
...
With the caveat that this is a bit fragile, because the semantics of a
@rel value can be broken by a change somewhere else in the document.
This is quite a different approach to the one normally taken to
differentiation. The usual discussion is to say that it's impossible
to tell if:
x:y
is a URI or a CURIE because 'x' could be a protocol, and 'y' could be
any part of a URI. It might seem an obvious remedy to say that if 'x'
is a protocol, then treat 'x:y' as a URI. However, this would 'break
s/protocol/URI scheme/
...
PROPOSAL
So to bring everything together, the proposal is:
(a) RDFa should add support for URIs in attributes that currently only
support CURIEs;
+1
(b) authors should be encouraged to use safe-CURIEs in those
attributes;
+1
(c) but since ordinary CURIEs may still be used, we should differentiate
by saying that anything appearing before a colon, that is not a
mapped prefix, is a protocol.
+-0; but I understand that going further would break existing content.
Now, *technically*, existing content will be in XHTML, not HTML, right?
So maybe in the process of defining RDFa-in-HTML, we could go even
further than that?
...
BR, Julian
