[
Lists Home |
Date Index |
Thread Index
]
I want to step back a pace or two.
There must be a really compelling use case to require XPointer authors to
always specify xmlns(), but I don't see what it is. As far as I can see, it
adds more work for authors, creates a greater likelihood of error, and adds
work for XPointer processors. I can imagine one use case for it, but it
doesn't seem to me to be the 80% case.
What I see as the common use case for XPointer is to link to relatively
static documents. The content of those documents might change, slowly, but
any change may break an XPointer, and prefix to namespace mappings are the
least likely things to change.
For instance, suppose that I have a set of XML documents that describe a
fantasy world in terms of geography, demography, history, literature, and
the like. Each broad subject category has a schema for documents, and a
namespace. And in all likelihood, I'm using the same prefix for all
documents of a given type. Or, if I'm authoring docbook, chances are that
all my documents use doc: as the prefix, or db:, or dbook: ... and even if I
use different prefixes, depending upon the phase of the moon, I *won't*, as
a rule, use different prefixes within a single document.
In short, prefix to namespace mappings in documents that are the targets of
XPointers are not likely to be variable.
So, what does xmlns buy me, in those circumstances? Well, first, I have to
decide whether I'll use the prefix in the document, or use a shorter one
(say, d:) in the xmlns() declaration in the XPointer. Assuming that I'm
authoring by hand, I have to type the namespace name (namespace names are
too damned easy to mistyp). Instead of looking at the target, and choosing
one of demo: or geo: or db: or doc:, and typing the QName, I get to type
something that's probably forty characters longer, plus the xmlns()
directive and my chosen prefix.
Assume I've got an authoring tool, and I point at a node, click, and select
"create XPointer." It does all the work. Great! Until I have to debug it,
because the XPointer runs two lines of URI-like namespace names embedded
inside a URL.
How does it benefit the author of an XPointer processor? I can't see this,
either. It doesn't mean that the processor can ignore namespace context; it
can't. It still has to keep track of namespace to prefix mappings specified
by the target document (as well as the ones specified in the XPointer). It
just adds a layer of mapping.
Now, the one case that I can think of where this is useful is for automated
creation of links to documents for which the content is unknown, but follows
a standard document type. So, for instance, if I wrote a desperate perl
hack to build a page of links, in which each (XPointer) link used the
/xhtml:html/xhtml:head/xhtml:title element's content as the content of the
link, and the various authors used various random prefixes instead of xhtml,
then I might want to say "this namespace, no matter what the prefix is".
However, I don't see that case as being particularly compelling, and I don't
understand why it should be considered more important than the
static-pointer case, such that authors of static pointers are required to
use the framework supplied to enable these more dynamic pointers.
Yes, I understand that an XPointer can't rely on getting its context from an
enclosing document, because its context might not be XML. The *target*,
though, is XML, and establishes a context, and that context is unavoidable,
so *why can't I use it*?
As I said, I'm sure there's a reason, but I still can't quite figure out
what it is.
Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
So what is love then? Is it dictated or chosen? Does it sing like the
hymns of a thousand years or is it just pop emotion? And if it ever was
here and it left does it mean it was never true?
-- Emily Saliers
|
