OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: SAX2: Namespace Processing and NSUtils helper class

[ Lists Home | Date Index | Thread Index ]
  • From: uche.ogbuji@fourthought.com
  • To: "Simon St.Laurent" <simonstl@simonstl.com>
  • Date: Sun, 26 Dec 1999 13:27:14 -0700

> 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@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@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@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS