[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Why SAX needs namespace support
Michael.Kay@i... wrote: > > > Perhaps a setOption(option, flag) interface would be more > > extensible. > > > > I could live with this, but only if the options were namespace > > qualified, i.e. > > > > parser.setOption("http://xml.org/sax/features/validation", true); > > parser.setOption("http://xml.org/sax/features/namespaces", false); > > > I'm all for fully qualified names, but I don't see why we should repeat the > error of using "http://" names for things that are not accessible via the > HTTP protocol. What's wrong with > "org.xml.sax.option.validation"? > > Or is this overkill anyway? Why not just say that names beginning with > "sax:" are reserved? This got me to thinking that you could have the best of both world's here from those people who want support for validation, namespaces, and the like to be through filters, and those who quite simply want direct native interfaces to the parser. To make this work you would need to do several things: (1) Change the ParserFactory class to not return a parser but a ParserGenerator object (in this case you might want to change the name "ParserFactory" to "ParserGeneratorFactory"). You would then have an interface named ParserGenerator which would be reponsible for constructing Parser types (such as parsers which do namespace processing). Really I think we only need two Parser types right now and then do the rest of the option stuff the way Mr. Megginson had suggested which I feel is simple and to the point. For a particular XML Parser package it would supply support for SAX by returning a ParserGenerator implementation in a manner similiar to how ParserFactory returns a Parser object (by using a system property). The structure of the ParserGenerator interface would be something pretty simple like this in Java: package org.xml.sax; public interface ParserGenerator { Parser createParser(InputSource source); Parser createParser(InputSource source, boolean validating, boolean entitesExpanded); NamespaceParser createNamespaceParser(InputSource source); NamespaceParser createNamespaceParser(InputSource source, boolean validating, boolean entitesExpanded); } If for some reason someone needed to use namespaces but the XML Parser implementation had no direct support for it or otherwise had no way of supporting the NamespaceParser interface, you could then use a standard filter that will come with the SAX Package to achieve this need. Michael Kay's SAXON package is a great start here. So if you did something like: ////////////////////////////////////////////////////////////////////// ParserGenerator parserGenerator = ParserGeneratorFactory.createParserGenerator(); NamespaceParser parser = null; try { parser = parserGenerator.createNamespaceParser(); } catch (UnsupportedParserException e) { parser = new NamespaceParserFilter(parserGenerator.createParser()); } parser.parse(new InputSource("http://www.foo.org/xml")); ///////////////////////////////////////////////////////////////////// NamespaceParserFilter would implement all of the methods of NamespaceParser and simply be a utility class for filtering out handled events from the standard SAX parser and then presenting them to the application. Not so sure here if this is exactly "Simple" (I am one of the people here who like SAX for its simplicity), but it does have some advantages in that you could easily have namespaces support even if the underlying XML parser does not support namespaces directly. Plus, I doubt "Namespaces in XML" will have any widespread use in the future by the great majority of XML Applications, so application programmers who want to deal with the very populous simple SAX Parser interface, won't have to eat the complexity of handling the namespace interface in their applications. Last but not least, we can talk about having specialized Name types for the NamespaceParser interface without having to worry about messing with the core XML parser interface. What do you folks think here? Tyler 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/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe 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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|