- From: Sam Ruby <rubys@intertwingly.net>
- Date: Thu, 11 Aug 2011 20:20:05 -0400
- To: Tim Berners-Lee <timbl@w3.org>
- CC: Ian Hickson <ian@hixie.ch>, HTML WG <public-html@w3.org>, TAG List <www-tag@w3.org>, Larry Masinter <masinter@adobe.com>, "Michael[tm] Smith" <mike@w3.org>
Does the following change sufficiently make the issue moot? http://html5.org/r/6427 - Sam Ruby On 06/27/2011 10:50 AM, Tim Berners-Lee wrote: > > On 2011-05 -26, at 01:20, Ian Hickson wrote: > >> On Fri, 20 May 2011, Tim Berners-Lee wrote: >>>> >>>> http://dev.w3.org/html5/md/#examples >>>> >>>> In the example, the HCARD data is to be parsed to produce RDF data >>>> with a predicate whose URI is >>>> http://www.w3.org/1999/xhtml/microdata#http://microformats.org/profile/hcard%23:adr >>>> >>>> >>>> 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. > > URIs are, of course, seen by humans in fact in many cases > even though to first order a web browsing person should not see any. > > A developer or a data analyst writing a SPARQL query > like > select * where { ?who > <http://www.w3.org/1999/xhtml/microdata#http://microformats.org/profile/hcard%23:adr > > ?where } > > is not going to be so. > > > Remember that there is while the HTML code for a web page > is rather cumbersome to look at compared the page, if you extract the > data and serialize it as turtle it often looks pretty easy for > the advanced user to understand. (Say the same level of user as one > who can handle spreadsheets). > > > >> 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 >>>> w3.org <http://w3.org> and microformats.org >>>> <http://microformats.org> sites coordinate the generation of new >>>> microformats. >> >> Actually the W3C part of the URI is fixed and used for all microdata >> vocabularies, so the w3.org <http://w3.org> 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 whatwg.org >> <http://whatwg.org> URL or even a separate >> scheme altogether. The latter would also reduce your issue #1 above about >> length. > > The microdata spec should not be arbitrarily different from the RDFa > spec. The URIs generated should work with RDF. > > Yes, a shorter URI which is in the w3.org <http://w3.org> space and then > has a hash > followed by the localname could work, effectively a default namespace > hosted by w3c, who would support it on the web. > Or microformats but they might not want to serve RDF schemas. > > > >> >> >>>> It makes W3C responsible for supporting things added in >>>> microformats.org <http://microformats.org> 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? > > Serializers use namespaces to make the output compact and > readable. They typically use N3/turtle prefixes or XML namespaces as > abbreviations > where the hash or if none the last slash is taken as the end of > the namespace URI, and everything from then on must be basically a > localname. > > >> >> If the URL syntax allowed the # character in a fragment identifier, we >> could avoid escaping the second one; would that help? > > No. > > Tim > >> >> -- >> Ian Hickson U+1047E )\._.,--....,'``. fL >> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >> >
Received on Friday, 12 August 2011 00:20:37 UTC