[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX2: Namespace Processing and NSUtils helper class

  • From: james anderson <James.Anderson@m...>
  • To: XMLDev list <xml-dev@i...>
  • Date: Fri, 17 Dec 1999 18:43:26 +0100

Re: SAX2: Namespace Processing and NSUtils helper class
That the argument cited below appears in the context of
names/namespaces/xml-encoding is an artifact of xml's genesis. If one leaves
text strings alone for a moment, and permits that, once the document is
decoded, the processing can occur on a symbolic level, then the argument has
no grounds, as the worrisome interface is relegated to the javadoc archives
and never appears in code.

Why are people so worried about the "parts of a name" anyway? In lisp code for
processing stuff decoded from / encoded into xml there is not a single
instance of either (SYMBOL-NAME ...) or (PACKAGE-NAME (SYMBOL-PACKAGE ...)).
The only test is (EQ ...). and even those are primarily by virtue of
classification for method dispatch.

So long as one stays on the "strings" level, however, the need for centralized
registration and rectification will prevail... Move up a level: let namespaces
themselves be first class objects. Parsers appear in any event to be moving
towards interning parsed strings. The processing infrastructure needs
operations to manipulate namespaces. A name should not bind an uri; a
namespace comprises a collection of names. If implemented in a reasonable
fashion, this permits the processor to associate a name with more than one
namespace. given that, a process can guarantee the correct mapping from names
to symbols and thus to processes without need for a centralized authority.

David Megginson wrote:
> 
> Every level of indirection is an open flame because it increases the
> difficulty (and cost) of learning and implementing an API, which
> leads to several problems:
> 
> a) the API is less likely to gain acceptance;
> b) the API is less likely to be implemented correctly; and
> c) the costs of learning, teaching, and documenting the API are higher.
>


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@i... the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.