You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Edwin Goei <ed...@sun.com> on 2001/11/28 01:27:01 UTC
SAX spec bugs (was Re: [Sax-devel] Re: SAX and namespace attributes)
David Brownell wrote:
>
> > > Re what to do ... changing the default behavior of a SAX2 parser isn't
> > > something that could be done while retaining backwards compatibility.
> >
> > I don't think adopting this change will break backwards compatibility:
> > the information that users get today will remain unchanged.
>
> The original Xerces bug report identified a backwards-incompatibility:
> different values reported for "xmlns" and "xmlns:*" attribute values.
> Even wrote that the empty string was preferred, as I recall ... that's
> "information that users get today". How can you claim that?
>
> The change would be backwards-incompatible to every SAX2 driver.
> It would instantly make conformant ones be nonconformant. (Nothing
> in SAX2 r2 does that!!) And there's really no way to evaluate the
This brings up a related issue. It seems that there were a few minor
method signature changes made between SAX2.0 final and subsequent sax2
bugfix releases. For example, DefaultHandler.resolveEntity() added an
extra exception in its throws clause. This is the correct fix, however,
it causes problems for application servers that want to be J2EE
compliant. The reason is that J2EE 1.3 includes JAXP 1.1 which includes
SAX2.0 final. To be J2EE compliant, app servers must pass signature
tests. These tests fail with the latest versions of sax2r2. So to
solve this our reference parser had to be modified to keep the old
version of the signatures.
As I understand it, the reasoning behind this is that J2EE certification
is based on specs. The JAXP 1.1 spec says it includes SAX2.0 final and
that distribution unfortunately had bugs in it, so we are stuck with the
old signatures until the next major release. The fixes to
AttributesImpl, for example, were included b/c those were implementation
fixes to the SAX2.0 final spec.
Here are the signature diffs that were found:
+ 3 SAXException-s had public no-arg constructors added
+ DefaultHandler.resolveEntity() added a throws IOException
Not sure what SAX should do with this info b/c these can probably be
considered SAX spec bugs. For xerces, this means that one could either
conform to the latest bugfix SAX spec or to the JAXP 1.1 spec (b/c JAXP
1.1 froze at SAX 2.0 final), but not both. Hope this makes sense, let
me know if it is unclear.
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: SAX spec bugs (was Re: [Sax-devel] Re: SAX and namespace
attributes)
Posted by David Brownell <da...@pacbell.net>.
> The right solution is for
> Sun to relax its signature tests concerning "endorsed standards". Now that
> Sun officially supports a mechanism to override these endorsed standards it
> is only logical to include the same kind of support in its conformance
> tests. If you could help in any way on that front ...
It should certainly be legal to support more current versions of
such standards, as a general rule. Conformance requirements
of JAXP (the text) don't specify "may not use more current
versions", so any signature tests adding such requirements are
contrary to the specification that was adopted.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: SAX spec bugs (was Re: [Sax-devel] Re: SAX and namespace attributes)
Posted by Edwin Goei <ed...@sun.com>.
Edwin Goei wrote:
>
> I believe the "endorsed standards" mechanism is something different. It
> was something that was added to J2SE 1.4 to allow users to use newer
> versions of some packages like DOM. The mechanism works like the
> -Xbootclasspath option that Miles mentioned. However, I am less certain
> what the rules are with vendors shipping say DOM L3 by default and still
> claim to be J2SE 1.4 compliant. It could be argued that this situation
> is similar to the J2EE 1.3 example above and may not be allowed.
I am told that the compatibility rules for J2SE 1.4 have been changed in
this area so what I state above may not be true. This is not an
official answer, though.
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: SAX spec bugs (and fixes)
Posted by Edwin Goei <ed...@sun.com>.
Arnaud Le Hors wrote:
>
> I fully understand the rationale for all this. However, it doesn't make much
> sense to provide an override mechanism on one hand, and to prohibit using it
> through the conformance test suite on the other hand. If this is not
> changed, people will be forced to use the obvious workaround which is to
> distribute platforms that contain out of date but compliant code along with
> a separate package which people can use to override the platform code.
> No real gain, but additional complication/confusion...
I think this is covered in my reply to Miles which you may not have seen
so I'm attaching it.
-Edwin
Re: SAX spec bugs (and fixes)
Posted by Arnaud Le Hors <le...@us.ibm.com>.
I fully understand the rationale for all this. However, it doesn't make much
sense to provide an override mechanism on one hand, and to prohibit using it
through the conformance test suite on the other hand. If this is not
changed, people will be forced to use the obvious workaround which is to
distribute platforms that contain out of date but compliant code along with
a separate package which people can use to override the platform code.
No real gain, but additional complication/confusion...
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: SAX spec bugs (and fixes)
Posted by David Brownell <da...@pacbell.net>.
> Here is my understanding: the intent of having the signature tests is as
> a partial solution to enforcing spec conformance. For example, there is
> a J2EE 1.3 spec and several implementations from various vendors like
> BEA, IBM, and the reference implementation (RI), that attempt to conform
> to it. The goal is to allow an app component, call it C, that uses the
> J2EE 1.3 API to be able to run in any 1.3 compatible implementation.
Seems like that goal calls for testing components against API specs,
doing things like "may only use methods in the 1.3 API spec", rather
than testing platforms! Though testing platforms is easier (there aren't
so many of them to test) and is already done for many other reasons.
It's good to know that JDK 1.4 systems can just drop "sax.jar" into
$JAVA_HOME/jre/lib/endorsed and get the ability to run software
that needs more current APIs. I added an entry to the SAX FAQ
on that topic. Presumably that'll work for J2EE as well as J2SE.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: SAX spec bugs (was Re: [Sax-devel] Re: SAX and namespace attributes)
Posted by Edwin Goei <ed...@sun.com>.
Arnaud Le Hors wrote:
>
> Well, IBM, for one, uses Xerces in its Java platform and is facing this kind
> of problem too (cf DOM Level 3 vs 2 discussion). The right solution is for
> Sun to relax its signature tests concerning "endorsed standards". Now that
> Sun officially supports a mechanism to override these endorsed standards it
> is only logical to include the same kind of support in its conformance
> tests. If you could help in any way on that front that would be very nice of
> you.
I'm replying to your message, but this is not specifically directed at
you but a response to other emails also.
Here is my understanding: the intent of having the signature tests is as
a partial solution to enforcing spec conformance. For example, there is
a J2EE 1.3 spec and several implementations from various vendors like
BEA, IBM, and the reference implementation (RI), that attempt to conform
to it. The goal is to allow an app component, call it C, that uses the
J2EE 1.3 API to be able to run in any 1.3 compatible implementation.
Since I'm familiar with the RI, I'll use that as an example. The J2EE
RI may have more than one 1.3 conformant version, but that C should run
in any of those versions and also in other implementations from other
vendors. At a minimum, the API should be stable so if someone develops
using a newer version of the RI, say 1.3.1, then it should also run in
an older version say RI 1.3.0 or any other 1.3 spec compliant
implementation.
The J2EE 1.3 spec includes JAXP 1.1 which includes DOM L2 core. This
means that C should only be limited to DOM L2 core b/c if it uses DOM L3
APIs then it would not work in other J2EE 1.3 compatible implementations
which may only implement DOM L2.
Then what changes are allowed? The answer is that changes which are bug
fixes with respect to the spec (otherwise no changes would be allowed).
Spec changes need to wait until the next version of the platform, in
this case J2EE 1.4.
I believe the "endorsed standards" mechanism is something different. It
was something that was added to J2SE 1.4 to allow users to use newer
versions of some packages like DOM. The mechanism works like the
-Xbootclasspath option that Miles mentioned. However, I am less certain
what the rules are with vendors shipping say DOM L3 by default and still
claim to be J2SE 1.4 compliant. It could be argued that this situation
is similar to the J2EE 1.3 example above and may not be allowed.
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: SAX spec bugs (was Re: [Sax-devel] Re: SAX and namespace attributes)
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Edwin Goei wrote:
>
> To be J2EE compliant, app servers must pass signature
> tests. These tests fail with the latest versions of sax2r2. So to
> solve this our reference parser had to be modified to keep the old
> version of the signatures.
> ...
> Not sure what SAX should do with this info b/c these can probably be
> considered SAX spec bugs. For xerces, this means that one could either
> conform to the latest bugfix SAX spec or to the JAXP 1.1 spec (b/c JAXP
> 1.1 froze at SAX 2.0 final), but not both. Hope this makes sense, let
> me know if it is unclear.
Well, IBM, for one, uses Xerces in its Java platform and is facing this kind
of problem too (cf DOM Level 3 vs 2 discussion). The right solution is for
Sun to relax its signature tests concerning "endorsed standards". Now that
Sun officially supports a mechanism to override these endorsed standards it
is only logical to include the same kind of support in its conformance
tests. If you could help in any way on that front that would be very nice of
you.
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: SAX spec bugs (was Re: [Sax-devel] Re: SAX and namespace
attributes)
Posted by David Brownell <da...@pacbell.net>.
> This brings up a related issue. It seems that there were a few minor
> method signature changes made between SAX2.0 final and subsequent sax2
> bugfix releases.
Actually I think that all of those were in the "SAX2 r2pre1" release of
last December. So far as I know, no more signature changes should
be there. (That assumes those "signature tests" don't care about the
RuntimeException subclasses -- any method can throw those, whether
or not they're explicitly declared, so it'd be pointelss to consider them.)
> Here are the signature diffs that were found:
> + 3 SAXException-s had public no-arg constructors added
> + DefaultHandler.resolveEntity() added a throws IOException
>
> Not sure what SAX should do with this info b/c these can probably be
> considered SAX spec bugs.
That's certainly my stance. In fact, that's a top goal of SAX2 r2:
resolving the open spec issues/bugs.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org