SAX2: Namespace Processing and NSUtils helper class
uche.ogbuji at fourthought.com
uche.ogbuji at fourthought.com
Sun Dec 26 20:27:21 GMT 1999
> At 11:57 AM 12/15/99 -0800, Tim Bray wrote:
> >i.e. the namespace processing is highly decoupled from the name
> >processing. Another way to say it is that much name processing will
> >be written to deal with one particular vocabulary, and want to just
> >deal with names, assuming the NS to have been checked already.
>
> I'm afraid my experience is rather different - that in building XML
> applications, people are reading the namespaces spec as providing a new and
> more sophisticated name, not a multi-level architecture. While the
> multi-level architecture is intriguing architecturally, I'm not sure that
> requiring every application to support it is even worth contemplating.
My experience differs greatly from yours. In _every_ XML application I have
been involved with in the last six months or so, and that accounts for many,
XML namespaces have been used to differentiate processing, and in that case,
gluing the URI to the local name would make life uglier for us.
However, I have an idea I might disagree with Tim on one point. I think that
the name that SAX2 signals to the application should include the prefix. I
know that the prefix is nothing more than syntactic sugar, but it can be very
useful sugar when trying not to surprise the end-user. Often prefixes are
chosen as a useful mnemonic, for example, using "xsl" as a common prefix for
'http://www.w3.org/1999/XSL/Transform'. In this case, it is nice to be
courteous enough to maintain the prefix through transformations if possible.
> It's fine as an option, but for many many use cases - especially smaller
> use cases where SAX is being used for its quick-and-dirty nature, I think
> I'd much rather have the big kludged string. If I as a programmer have to
> deal with this every time I write a handler, or even have to track down
> filters, I'll waste a lot of time complaining on XML-dev about what an
> utterly idiotic notion namespaces in XML were to begin with. If I can just
> tell the parser my preference, and not be forced into extra work, I'll be a
> lot more productive.
But you've already made all these complaints, and I daresay we've all learned
how to delete certain posts in a hurry. I don't mean any personal offense,
but I think Namespaces did an excellent job of addresing a difficult problem,
and the fact that some people disagree is hardly grounds for excluding them
from every following standard. It is part of XML, deal with it.
> Until schemas/DTDs are capable of doing real work with namespaces, we are
> living in the pre-namespace era. The W3C dropped the ball on validation
> and namespaces, and we've been living with the consequences - life between
> 'eras' - ever since.
Interestingly enough to note, lately, we've been using schematron for
validation, and it handles namespaces pretty neatly through the awesome
namespace-crunching power of XPath and XSLT.
--
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji at fourthought.com (970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com http://OpenTechnology.org
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev
mailing list