Cover Pages Logo SEARCH
Advanced Search
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

Cover Stories
Articles & Papers
Press Releases

XML Query

XML Applications
General Apps
Government Apps
Academic Apps

Technology and Society
Tech Topics
Related Standards

Java Specification Request - XML Standard Extension Specification

Date:        Thu, 25 Feb 1999 13:13:48 -0800
From:        David Brownell <db@Eng.Sun.COM>
To:          John Wilson <>
Subject:     Re: Proposal to standardise a Java API

John Wilson wrote:

> Sun have just published a proposal to standardise a Java parser API.
> The proposal, such as it is, is available at the URL above.

The proposal is to start the discussions for what the platform level API should be ... it's not a specific API proposal. Though it does sketch an initial set of functionality, scoped by SAX, DOM, and some appropriate extensions.

Point being, the open process Sun is following in support of its ISO/PAS process doesn't allow concrete proposals to be published quite yet -- they've got to be made as part of that process.

> I'm mildly surprised that nobody from Sun has had the good manners
> to post an announcement here.

You beat me to it, that's all! However, the intention to start this process has been mentioned in the past ... and I told folk to watch the URL above quite recently. Quite a few folk from XML-DEV have asked for such an API standardization process to start.

Date:       Thu, 25 Feb 1999 22:46:42 -0800
From:       David Brownell <db@Eng.Sun.COM>
To:         "Simon St.Laurent" <>
Subject:    Re: Well-formed vs. valid

Simon St.Laurent wrote:
> Big question: can I plug someone else's SAX parser into your scanner, and
> then have your validation component work on my SAX events? While it's
> unlikely that I'd want to plug a different SAX parser in, it's quite
> possible that I'd want to work with the SAX events (transforming with XT,
> for instance) before performing validation.

Well, Sun's current package (released today with source :-) has some infrastructure along those lines ... but it's a bit more integrated with the DOM than with the SAX bits. That's to keep apps from needing to do the sort of tree structure tracking that DOM already does. Since it's in the DOM side, you can plug any SAX parser in to it.

Specifically, when DOM nodes are plugged into the tree there are certain clearly defined callbacks which are made: the "XmlReadable" interface.

When those callbacks are made, the "parent" context is visible as a DOM tree that doesn't fully correspond to the input document. It seems that one of the more popular methods is doneParse(), called when the last of an element's children is parsed. Also startParse() gets used to do resolution of relative URLs (e.g. in external entities).

Those callbacks are intended for performing various application level work such as integrity checks. Applications can provide diagnostics with the same level of specificity (line, file, etc) as the parser itself; in some cases such diagnostics will be reported directly through the SAX error handler used by the parser.

- Dave

xml-dev: A list for W3C XML Developers. To post,
Archived as: and on 
CD-ROM/ISBN 981-02-3594-1

Prepared by Robin Cover for the The SGML/XML Web Page archive.

Globe Image

Document URL: