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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: SAX: two alternatives for namespaces

[ Lists Home | Date Index | Thread Index ]
  • From: Chris Hubick <maillist@chris.hubick.com>
  • To: xml-dev@ic.ac.uk
  • Date: Thu, 30 Jul 1998 10:18:37 +0000 (GMT)

On Wed, 29 Jul 1998, David Megginson wrote:

> This leads to another thought -- that we probably need some kind of a
> hook for requesting and/or querying parser features.  This issue came

	I would disagree, somewhat.  Although I think it would be usefull,
I will go with Ron Bourret and say that I would rather see a standard set
of features supported by SAX parsers.  I would imagine that the vast
majority of SAX applications will not have to do runtime introspection of
a parser, but will rather be written, tested, and shipped using a certain
processor which supports the applications needed features.  There will
always be features SAX won't support, and people can use the processors
native API's to access them.  I think there will soon be enough XML
processors out there that full SAX support will be a good way to
differentiate.  Done think of the current SAX as version 1, think of it 
as level 1, and the next version can be level 2, if you want to advertise
level 2 SAX support in your processor, then you have to support all it's
features, such as namespaces, else you can just support level 1.
Level 3 could be support for DOM/RDF/XLL/XSL/XSchema extensions or
whatever. Make the processor writers work harder to make things simpler
for the users, because in the end it is the users writing applications who
will spend more time with SAX.

	Now, on the other hand...

	All that worries me about querying for features is that they will
become too fine grained.  How about seprate SAX API's for all the
different areas of XML, rather than one big one.  Ie, a SAX API for all
parsers supporting DOM, something like:

public interface DOMFactory {

  public void buildDOM(boolean build);
  public Document getDocument();
    // The above Document is live unless parse has returned


And then one could query to see if this interface is supported.  The thing
being that if you implement an interface, you should have to support all
of it.

I have been trying to think of a clean way to support namespaces
without having to change the current SAX (Level 1) spec. How about an
interface that works similar to Locator:

public interface NameSpace {

  String getNameURI();


Whenever a parser supporting namespaces calls your Document/DTD Handler
you would be able to call getNameURI() (implemented by the parser) during
the scope of that method.  AttributeList could be extended to implement 
this interface as well.

Chris Hubick

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe 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