[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SAX Filters for Namespace Processing
- From: Richard Tobin <firstname.lastname@example.org>
- To: email@example.com
- Date: Sun, 05 Aug 2001 01:51:10 +0100 (BST)
>> As many threads on xml-dev have shown,
>> text-based processing of XML is hazardous at best.
>Do you understand how this statement completely contradicts the original
>intent of XML?
Hang on, consider the context of this. The thing that's "hazardous"
is copying a fragment of XML from one place to another, and the
sense in which it's hazardous is that it may become impossible to
identify what vocabulary the elements belong too.
Now this was always true, even before namespaces. In fact, it was
*more* true before namespaces, because there was nothing you could do
about a name clash short of renaming the elements. Namespaces have
relieved this somewhat, in that you can bind prefixes locally to
preserve their meaning. A simple cut-and-paste can't do this,
because you have to insert namespace attributes, but XSLT does it,
XInclude will do it, and a namespace-aware editor can do it.
The use of unqualified local elements (which is not something I
advocate, by the way) does make this more difficult, but that's just
one of the factors you have to consider when choosing whether to use
them. If you want to use elements whose vocabularies are determined
by their parents, you just can't put such elements from different
vocabularies inside the same parent. You can only move the whole unit
rooted at the qualified element. Just as with attributes: if the same
attribute means different things on different elements, you can't move
it around from element to element, but you can move the whole element.