Why I moved from Forbid to Literal

At XMLDevCon 2000 this week, someone asked me to write a public explanation
of why I shifted from original position of Forbid to my current position of
Literal.  The relative URI discussion did come up several times during the
conference, and I'd like to think we found a little more cause for optimism
than is normal on this list, but I'm not positive it will last.

'Forbid' seems like the easiest solution to the problem.  Remove relative
URIs, and most of the believable differences between those who support
absolutization and those who support treating namespace URIs as literal
strings disappear.  The number of warning labels required in the Namespaces
specification and related best practices information drops fairly
dramatically.  Perhaps best of all, it lets you combine literal comparison
with the global and reusable identifiers wanted by the absolutize side.

Common XML, a document describing a safe core of XML and providing warning
labels for the rest, immediately took this approach for its core and will
continue to take this approach, as it is the easiest way to maintain
interoperability.  (Common XML doesn't prohibit the use of features outside
of its core - it just treats them as potentially useful features with
potentially dangerous side effects.  See
http://www.docuverse.com/smldev/commonxml.html)

While I felt (and still feel) that the use of relative URIs is dangerous
and generally poor practice, there are two sets of arguments that lead me
away from forbidding their use.  The first is the existence of documents
that already use relative URIs - /dev/null being only one of several cases
found in the wild.  

More compelling, however, is the possibility that relative URIs may in fact
make sense as a 'best practice' in circumstances where the identity of a
set of documents is defined by the set, not by some identifier with meaning
outside of that set.  It may not matter at all where these documents go or
who 'owns' them - within the world of that set, their interrelations are
real, and any addition of a more global identifier is just a contingent bit
of information that may not add any substantial meaning except possibly for
convenient retrieval.

In this latter case, it is the namespace identifier that matters, not the
wider context.  In a sense, these document sets may be said to be
independent of global schemes.

In addition to that identifier-centric perspective is the complexity
introduced by the various schemes provided by URI schemes for comparing URI
values.  While we may go so far as to provide a simplified algorithm for
comparing URIs in some kind of context, that algorithm will not keep pace
with the many different comparison rules used for the different URI
schemes.  While simplification is necessary to make such a process widely
and consistently implementable, it treads on the assumptions that people
familiar with particular URI schemes are likely to make.

Literal comparison avoids both that complexity and the temptation to
globalize where it may not be appropriate.  

It seems best to me to keep 'namespace names' as just names, while
preserving base URI information and allowing applications to build
'namespace URIs' as necessary in given contexts, typically involving
retrieval.  


Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
http://www.simonstl.com - XML essays and books

Received on Friday, 30 June 2000 11:12:45 UTC