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

Re: SAX2: Namespace proposal

• From: James Clark <jjc@j...>
• To: David Megginson <david@m...>
• Date: Sun, 19 Dec 1999 13:11:34 +0700

David Megginson wrote:

> c. If the Parser is delivering raw XML 1.0 names, the Namespace
>    declarations (xmlns*) will be included in the AttributeList but
>    both the Namespace URI and the local name will be set to null, and
>    getType(String, String) and getValue(String, String) will always
>    fail (even with null arguments).

The one scenario that bothers me with this is:

- the parser always supplies both XML 1.0 names and cooked namespace
declarations

- the application is namespace-aware and only interested in the cooked
namespace information

- the application iterates over all attributes using getLocalName(int).

In this scenario, the fact that the parser is supplying XML 1.0 raw
names in addition to cooked namespace declarations will force the
application to check whether getLocalName is returning null (indicating
a namespace declaration) and, if so, ignore the attribute.  This seems
to be the one case where a namespace-aware application that is being
driven by a parser that provides cooked namespace information is
affected by whether or not the parser also provides XML 1.0 raw names.
This seems a bad thing, but so far I haven't been able to think of a
fully satisfactory solution.

> This is kind-of painful

Indeed.  Although I think your proposal is quite reasonable, and
although I don't have anything better to propose right now, I can't say
I feel altogether comfortable with it.  I think we should continue to
explore other possible solutions.  If it's possible to have a completely
new org.xml.sax2 package, then more radical solutions are possible.  For
example, I think there are good arguments for moving to a 

interface DocumentHandler {
  void startElement(StartElementEvent event)
  void endElement(EndElementEvent event)
  ...
}

style interface.  This makes it much easier to evolve the interface in
the future.  For example, a SAX3 that added support for XML Schemas
could just add additional methods to StartElementEvent and
EndElementEvent and thus remain compatible with SAX2.

James



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...)

• Follow-Ups:
  • Re: SAX2: Namespace proposal
    • From: Stefan Haustein <stefan.haustein@t...>
  • Re: SAX2: Namespace proposal
    • From: David Megginson <david@m...>

• References:
  • SAX2: Namespace proposal
    • From: David Megginson <david@m...>

• Prev by Date: Re: Free Tool for Efficient XML Data Compression
• Next by Date: Re: XML parsing memory overhead concerns (fwd)
• Previous by thread: SAX2: Namespace proposal
• Next by thread: Re: SAX2: Namespace proposal
• Index(es):
  • Date
  • Thread