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

SAX2: Namespace processing features

  • From: David Megginson <david@m...>
  • To: xml-dev@X...
  • Date: Wed, 15 Mar 2000 08:03:00 -0500 (EST)

namespace processing
David Brownell writes:

 > General SAX2 Observations> 1) The feature mechanism is busted wrt the two
 > namespace-related features.
 > 
 > Agreed.  As the simplest conceptual issue, two flags define four states ...
 > one is declared illegal, and there are really only two useful models for
 > working with XML documents (XML, or NS).  Why are three  models provided?

Here's my thinking on the three models:

1. Namespace-aware processing (typical case): xmlns* attributes should
   be invisible to most apps, because they are really pure
   declarations (I would have perferred PIs, but that's ancient
   history now).  Making xmlns* attributes available to all apps would
   hoist unnecessary complexity on most of them.

2. Namespace-oblivious processing (common case for now): many apps
   still need to work at the raw XML 1.0 level rather than the
   Namespace level -- they need to see qualified names with prefixes,
   for example, and xmlns* attributes are real attributes to them.
   Making these apps reconstruct xmlns* attributes based on
   start/endPrefixMapping hoists unnecessary complexity on them.  It's 
   also necessary for a few apps to be able to specify that they don't 
   want the XMLReader even to attempt Namespace processing (because of 
   non-standard prefix use, etc.).

3. According to many posters, there exist apps that want to have it
   both ways: they want to be able to work at both the raw XML 1.0
   view and the cooked Namespaces view at the same time -- allowing
   this level as well makes things messy, but the demand is clearly
   there.

So, there has to be some way for an app to say that it does or doesn't
require namespace processing and that it does or doesn't require
qnames and xmlns* attributes.  There's no harm in providing qnames in
either case, but providing xmlns* attributes can mess up the model.

I'll admit that the two features I chose are a little awkward, but I'm
still having trouble thinking of a credible alternative.


All the best,


David

-- 
David Megginson                 david@m...
           http://www.megginson.com/

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

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.