Re: CURIEs vs. QNames

Norm,

As always, thanks for your time and input on these issues. Comments  
below.

> | Do I really need to write the Dublin Core URI multiple times?
>
> That would work.

Yes, it would "work," but it would violate one of our strong  
requirements that we help users not duplicate data unnecessarily. If  
a user wants to upgrade from one version of Dublin Core to the next,  
he shouldn't have to go change all the Dublin Core properties used  
throughout every document.

> I'd prefer to simply allow
>
>   <dc:creator>Norman Walsh</dc:creator>

Seems like <meta property="dc:creator">Norman Walsh</meta> is close  
enough, though again that violates the TAG and overloads the QName  
usage. We're trying to fix that.

> | Do I
> | really need to start using XSLT just so I can define URI
> | abbreviations? Or should I simply violate the TAG's recommendation
> | that QNames not be used as URI abbreviations,
>
> Yes. That's what everyone else does, that's what everyone expects.
> Doing something else is going to be more confusing.
>
> | and then be stuck with
> | a mostly-working-but-not-quite-complete abbreviation scheme?
>
> Yes.

I feel that the above approach is deeply broken. You're effectively  
saying "ignore the TAG, that's what everyone else does." Even worse,  
it seems that we should sometimes ignore the TAG, and at other times  
abide by the TAG rules quite strictly. Maybe this is the unwritten  
W3C rule and I'm just not used to it.

> | I certainly understand the worries about the specific syntax that
> | will be used for CURIEs, and the task force is actively discussing
> | various options right now. However, I don't understand this reaction
> | to the CURIE concept.
>
> Conceptually, I think it's going to be confusing to introduce another
> syntax for something that can almost always be represented as a QName
> without introducing a new syntax. Syntactically, I think overloading
> the QName syntax is just plain wrong.

So, if I understand you correctly, you're saying there is no right  
solution. The current solution of overloading QNames is syntactically  
(and possibly semantically) wrong. Yet everyone does it. And it  
violates the TAG recommendation. If we continue to live with "almost  
always," confusion will only get worse, and we are going to come up,  
at some point, with a series of scenarios that inevitably don't fit.

Why are we afraid to start solving this problem? We have a very good  
reason to address it now. RDF clearly calls for using namespaces  
multiple times, particularly multiple namespaces in a given document.  
That's the point of RDF, in fact. Adding RDF to HTML, where certain  
attributes are already typed as URIs and cannot be changed willy- 
nilly, forces us to resolve the QName/URI conflict.

The needs of expressing RDF in HTML present an opportunity to solve a  
long-standing problem. I can't see why punting on it yet again is a  
good thing.

-Ben

Received on Monday, 28 November 2005 16:49:46 UTC