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
hsivo...@iki.fi
http://hsivonen.iki.fi/
