Re: HTML+RDFa Issues (update)

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:

http://www.w3.org/2009/07/09-rdfa-minutes.html#item01

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/

Received on Thursday, 9 July 2009 17:08:09 UTC