Re: Fwd: Re

On Fri, 20 May 2011, Tim Berners-Lee wrote:
> >
> >
> >
> > In the example, the HCARD data is to be parsed to produce RDF data 
> > with a predicate whose URI is 
> > 
> >
> > That is an appalling URI, for a number of reasons.
> > 
> > 1. It is horribly long

It's opaque and not intended for human consumption, so that doesn't seem 
like a serious problem.

> > 2. It is constructed including two other URIS, so that there is a 
> > combination of two authorities, so it will only be supported if the 
> > and sites coordinate the generation of new 
> > microformats.

Actually the W3C part of the URI is fixed and used for all microdata 
vocabularies, so the site doesn't have to be involved in the 
development of the vocabulary at all. I'm happy to use another URL if you 
would like; I used that one for consistency with e.g. the URLification of 
the rel="" values in RDFa. It could be a URL or even a separate 
scheme altogether. The latter would also reduce your issue #1 above about 

> > It makes W3C responsible for supporting things added in 
> > which, while W3c may need to do this special cases 
> > should not be built into the semantics of the HTML language.

There is no effort needed on the W3C side for this at all. If the W3C 
would rather not be part of this though I'm happy to change the URL.

> > 3. Because it has a hash in he middle instead of at the end, typical 
> > serializers won't be able to use namespace prefix on output, so any 
> > files which use these URLs will by ugly, unreadable, and large.

I don't understand this issue. Could you elaborate?

If the URL syntax allowed the # character in a fragment identifier, we 
could avoid escaping the second one; would that help?

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 26 May 2011 05:21:39 UTC