Lists Home |
Date Index |
- From: David Megginson <email@example.com>
- To: "XML Developers' List" <firstname.lastname@example.org>
- Date: Thu, 23 Apr 1998 13:49:57 -0400
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
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 Megginson email@example.com
Microstar Software Ltd. firstname.lastname@example.org
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)