SAX Level 2 (was 1998-04-20 Pre-Release...)

[David Megginson]

Ray Cromwell writes:

 > However, I think there is a need for a ubiquitous, parser
 > independent, API that gives one complete control over their data
 > structures, but without any (or negligable) information loss. Larry
 > Wall gave a convincing presentation at XML98 as to how Perl will
 > support XML which made my mouth drool compared to the level of
 > information I'm getting now. In fact, I built my application around
 > Lark instead of SAX because I needed access to location offset
 > information.

Location information wasn't available in the January draft, but it
will be there in the release that I'm finishing up right now.  I
expect that much of what you want (including DTD information, which
you mention elsewhere in your message) will be there in the DOM, and
that authoring tools will naturally gravitate towards the DOM, since
they often (usually?) need to have an XML tree model anyway.

 [...]

 > 1) All SAX features are required to be implemented, ala OpenGL, etc.
 > 2) Some SAX features can be unimplemented, but an interface is available
 > to query whether the functionality exists (DirectX, JDBC, etc)

I also tend towards (1), with a few provisos:

1) there is no requirement that SAX parsers support any particular
   requested locale for messages; in other words, it is always
   acceptable for the parser to throw a SAXException when the user
   invokes Parser.setLocale() to request an explicit locale;

2) SAX parsers are encouraged but not required to provide a Locator
   for document events with DocumentHandler.setDocumentLocator();

3) Non-validating parsers do not have to use the
   DocumentHandler.ignorableWhitespace() callback (though they may if
   they wish, as AElfred does);

4) it is at the discretion of the SAX parser what events (if any) are
   fired after the parser has invoked ErrorHandler.error() or
   ErrorHandler.fatalError() -- however, it may be that the XML 1.0
   spec requires ErrorHandler.error() _not_ to kill the parse, at
   least for validity errors (validity errors are reportable only at
   user option); and

5) a parser that does not use the DTD need not report notation and
   unparsed entity declarations (I need to look into this further).

 > I'd like to nominate the three biggest features I'd like in SAX Level 2
 > (or SAX2.0), in order of importance.
 > 
 > 1) access to DTD information

Bingo -- this would be valuable to me too.  I'm not certain, though,
if it makes sense to provide this through SAX or if we need to wait
for the DOM.

 > 2) comments, CDATA, and location information for Attributes

Yes, this is a big one for authoring transformations (as opposed to
downstream production transformations, which the author will never
see).  By "location information," do you mean the order of
specification, or whether an attribute was specified or defaulted?

 > 3) sax.util classes that take an ElementFactory (which return DOM
 > interfaces), and build a tree. (maybe Don Park would like to contribute
 > this). IBM's XML for Java is a starting point, but it has the fatal flaw
 > that the return values of the ElementFactory are not the DOM interfaces
 > (such as Element or PI) but IBM base classes, like TXElement or PI,
 > which means you are forced to inherit from TXElement instead of just
 > implementing Element.

Sounds good, but since this could be built on top of SAX instead of
within it, I'll probably bow away from it.

Now, I need to stop talking about level 2 and finish level 1.


All the best,


David

-- 
David Megginson                 ak117 at freenet.carleton.ca
Microstar Software Ltd.         dmeggins at microstar.com
      http://home.sprynet.com/sprynet/dmeggins/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)