- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 18 Feb 2009 14:55:59 +0200
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Sam Ruby <rubys@intertwingly.net>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, Dan Connolly <connolly@w3.org>, Ian Hickson <ian@hixie.ch>
On Feb 17, 2009, at 05:40, Manu Sporny wrote: > The front-runner for how we address the xmlns: issue seems to be > @prefix. I believe using @prefix to specify CURIE prefixes will > address > all of your concerns with XHTML/HTML DOM incompatibilities. Please > confirm or reject this assertion (and be specific about what you > do/don't like about @prefix). If @prefix were used as the only mechanism for defining CURIE prefixes (that is, xmlns:foo would no longer be used), it would address all my XHTML/HTML API consistency concerns. However, it would not address my concerns about prefix-based indirection in general. What I like about @prefix is that the attribute would result in the ["", "prefix"] namespace,local pair in both Namespace-aware XML parsing as in HTML parsing. More on what I don't like about it below. > The other issue that you have raised is the perceived fragility of > CURIEs. Your suggested change has been to get rid of CURIEs > altogether, > replacing them with full URIs. I can't tell if you are proposing this > because you think it is a good idea, or if you are proposing this to > illustrate a point about the authoring difficulty of using full URIs? Both, except instead of "good" I'd characterize full URIs as less bad than CURIEs. > Could you please summarize (refer to other conversations[1] if it > helps) > why you feel that full URIs are a better alternative than CURIEs? For > those that take part in this thread, please be specific and keep it > focused on CURIEs vs. full URIs for predicates. * Using full URIs doesn't involve a layer of indirection this - reduces cognitive load (particularly for non-programmers who don't deal with indirection all the time) - simplifies code (both producing and consuming code) * The kind of indirection where a meaningless prefix is minted solely for indirection is problematic - it confuses people who think the prefix itself is semantically important (Examples: http://lists.w3.org/Archives/Public/public-rdfa/2009Feb/0083.html ) - it requires programmatic generators to come up with aesthetically pleasing prefix generation strategies * The usability problem with full URIs is a problem that the RDF community hasn't addressed at the root of the problem. Instead, the RDF community has tried to hide the problem syntactically. This has caused adjacent communities within the W3C sphere to sustain syntactic damage. In SGML and in XML 1.0 before Namespaces, a generic identifier (in SGML) or a name token (in XML) was a simple datatype that could map to the string datatypes of various programming languages and that could use general string interning mechanisms. Namespaces were introduced in XML due to a requirement posed by RDF. This permanently complicated XML by turning names into compound objects. (See http://www.flightlab.com/~joe/sgml/sanity.txt ) The XML community was left with this damage (complication) even when the RDF community decided it didn't like RDF/XML after all and tried to distance itself from RDF/XML moving to other syntaxes. I think CURIEs pose a similar risk of syntactic damage to HTML. Even if RDFa largely failed, we'd be left with a legacy of CURIE-induced requirements in HTML parsing. The whole history of RDF serializations is about dealing with the usability problem that URIs as identifiers pose. (Compared to N-Triples, N3 and Turtle just add more syntax for hiding the length of URIs.) Abandoning one serialization after another and blaming the syntax for the lack of success of RDF won't solve the usability problem with URIs-as-identifiers that the next serialization will face. Using full URIs exposes the cost of the actual usability problem to the RDF community instead of making adjacent communities bear the cost through complication to their formats. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 18 February 2009 12:56:42 UTC