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

Re: HTML+RDFa Issues (update)

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 09 Jul 2009 13:07:31 -0400
Message-ID: <4A5623D3.204@digitalbazaar.com>
To: RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>
Julian Reschke wrote:
> Manu Sporny wrote:
>> What is the worst thing that could happen, as far as you are concerned,
>> if a consumer saw/stored both "urn:rights" and
>> "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a", verbatim? What is the
>> damage done to the Web if the practice becomes widespread?
> With "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a" there is no problem
> -- it looks like a full URI and it is.
> With "urn:rights" there is the problem that the consumer gets the wrong
> URI, and furthermore there's a real risk that it could get the same
> string from a different party, trying to identify a *different* link
> relation.

Right - but what damage is done at that point? How does that ambiguity
translate into a fatal error in an application or a logic error in a
reasoning agent?

Sam's language, "SHOULD avoid well known URI schemes", goes a long way
to prevent the markup above. Do you have another example that could
conceivably be used? http:, ftp: and urn: break the "SHOULD avoid well
known URI schemes" rule. I'm having a difficult time trying to create a
scenario where something bad happens (other than potential ambiguity IF
somebody uses a URI scheme and IF they just happen to use the exact same
string of characters as a page somewhere else on the web).

I understand that these barrage of questions that you feel you have
already answered may be irritating, but we're attempting to thoroughly
understand your position - as there may be subtleties that we have
continued to miss.

>> Also, what is in your set of acceptable solutions to the issue -
>> assuming that we adopt Sam's "SHOULD avoid well known URI schemes"
>> language, and ensuring that there is backwards compatability for RDFa?
>> Similarly, what is your ideal solution?
> If I had a solution that is compatible both with RDFa and full-URIs in
> @rel, I would already have proposed it. That's why I've been complaining
> for so long: I think the use of CURIEs instead of safe-CURIEs in @rel is
> a big problem. (It's ok in new attributes, but problematic in @rel/rev).

We discussed this issue at length during the telecon today - we may be
closing in on a solution that would work for you (and the rest of the
"allow unambiguous URLs in @rel/@rev" group).

All of us agreed that we didn't necessarily understand the problems
resulting from what you are describing. We see it as a theoretical issue
with potential real-world implications, but couldn't think of any that
would destabilize the Web or even affect a significant number of people
(<1%, if forced to pull a number out of thin air).

So, we approached it from the standpoint that not being able to place
URLs in @rel/@rev is too restrictive and that we should try to change that.

I believe the consensus during the call today was on an approach that
would change the CURIE processing rules such that anything without a
prefix mapping is understood as a URL by default. This would allow URLs
to be used in @rel/@rev.

Mark is going to detail the proposal in an e-mail to this list in the
next couple of days. You can see the telecon conversation related to the
issue here:


-- manu

Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
Received on Thursday, 9 July 2009 17:08:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:03 UTC