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

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SAX2: Missing isSpecified show-stops DOM building



Dear SAXons,

we are using SAX2 events (only) to build a W3C-DOM1. The code works well
beside exactly one exception. The "Attr"-node in DOM1 has a "specified"
attrbibute and also has some methods which need to know whether an attribute
value is present. Reminder: "isSpecified" tells you if an attribute value is
there because of DTD-defaulting or because of an instance value. This single
piece of information, however, is missing in SAX2 and thus is a show-stopper
in building a 100% compliant DOM. Everything else works fine (as per the the
NIST compliance suite tests at www.nist.gov/xml), using only SAX2 events.

In private mails I was told that supporting the "isSpecified" attribute in
SAX was discussed and voted against in the SAX1 discussion. However, there
is no sure way to actually re-calculate this information from anything else
provided by SAX events.

Here are some arguments in favor of adding "isSpecified" to SAX 2.0.1:

(1) "It's calculated anyway": Most vendors implement both DOM and SAX in a
combined package. To fill the DOM objects, the "isSpecified" information has
to be calculated anyway. A prominent example is the Apache Xerces code,
where "isSpecified" is present and only dropped few code lines before the
SAX event is fired.
I'm pretty sure that any fully compliant DOM implementation out there has to
do the same. The problem just never surfaced because vendors normally do
both SAX and DOM, and can easily use their internal interfaces.

(2) "It is a show-stopper in building a DOM": Our implementation does not
parse XML itself, but relies on SAX2 events when building a DOM. Wasn't SAX
meant to provide exactly freedom from proprietary parser glue code ? Given
the importance and widespread use of the W3C-DOM, shouldn't it be a goal for
SAX2 to support DOM building ?
However, we currently have to write ugly, vendor-specific glue code for the
only reason "isSpecified" can not be calculated any other way.

(3) "This is a very small plea": I'm not asking for a
fancy-do-it-all-DTD-processing extension of SAX, but only for a single
attribute to be added.

I would be very grateful if some of the SAX-debate veterans could comment on
this, or even point out a way how I can help getting this into SAX 2.0.1.
Thanks a lot in advance.

Regards,
	Ingo Macherius