W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > July 2009

Re: Proposal for allowing URIs in CURIE-only attributes

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 10 Jul 2009 19:50:25 +0200
Message-ID: <4A577F61.5080904@gmx.de>
To: Mark Birbeck <mark.birbeck@webbackplane.com>
CC: RDFa <public-rdf-in-xhtml-tf@w3.org>
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
Received on Friday, 10 July 2009 17:51:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 10 July 2009 17:51:12 GMT