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 David Brownell <da...@pacbell.net> on 2001/11/27 07:34:00 UTC
Re: [Sax-devel] Re: SAX and namespace attributes
> > According to the SAX documentation namespace attributes should have no
> > namespace URI, and no local name:
> > ...
> > This information is based on Namespaces in XML REC.
> >
> > However, the XML Information Set W3C REC specifies that namespace
> > attributes should be bound to "http://www.w3.org/2000/xmlns/" :
> > ...
> > In my opinion, SAX definition for namespace attributes is incorrect and
> > needs a fix.
> > Any comments?
When you believe that sort of thing, you should file a bug or RFE against
SAX using the bug database accessible through the URL below.
> My guess is that SAX2 was defined before InfoSet came out. I hope you
> don't mind if I cc sax-devel@lists.sf.net (http://www.saxproject.org).
The SAX2 spec does indeed conform to the Namespace spec, rather than
to the (new) Infoset spec or (less new) DOM L2 spec. The namespace folk
were pretty adamant that "xmlns" isn't a namespace at all. I went around
with them on that issue more than once. Though I can't say I'm glad to see
the W3C change its mind on that issue well _after_ the Namespace REC
was finalized! (*)
Re what to do ... changing the default behavior of a SAX2 parser isn't
something that could be done while retaining backwards compatibility.
One could define a feature flag (another "SAX2 Extensions 1.1 flag)
to kick in this behavior as a non-default mode, but I'm not sure that'd
be very beneficial -- apps couldn't rely on it, they'd have to code the
workaround in any case, and given that, what's the benefit of adding
another confusion of codepaths that needs testing/updating?
- Dave
(*) The first of the three DOM L2 Candidate Recommendations,
dated 10-Dec-1999, conformed to the 14-Jan-1999 Namespace
REC ... but the second of three (!) DOM L2 CRs, 7-Mar-2000,
changed this. SAX2 finalized two months after that, DOM L2
in November 2000, and Infoset just a few months ago. Just to
track the publicly visible milestones of this change.
---------------------------------------------------------------------
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-devel] Re: SAX and namespace attributes
Posted by Elena Litani <el...@ca.ibm.com>.
David Megginson wrote:
> Wrong. There's no such thing as a backwards-compatible change to an
> API: either you break the drivers or you break the clients. In this
> case, clients that expect the old behaviour will probably be OK
> (they're unlikely to rely on the Namespace URI being null), but
> clients that expect the new behaviour will break on SAX drivers that
> implement the old behaviour. This will be a typical bug report:
>
> I'm using the ACME Java game development kit, and it requires a SAX2
> parser. I installed the FooBar parser, which says it is
> SAX2-conformant, and now I get a NullPointerException. Can anyone help?
David, as far as I know SAX specifies that namespace URI must be an
empty string if there is no URI.
Thus, no user should receive NPE (unless SAX driver does not comply with
the SAX specification). So the example you give above should not break
anybody.
In addition, I believe the new code should still rely on xmlns prefix to
recognize the namespace attributes (see http://www.w3.org/2000/xmlns/)
[[
Note that you must use the reserved prefix xmlns: when declaring
namespaces. It does not work to declare another prefix with this
namespace name and then try to use it for namespace declarations.
]]
Thank you,
--
Elena Litani / IBM Toronto
---------------------------------------------------------------------
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-devel] Re: SAX and namespace attributes
Posted by David Brownell <da...@pacbell.net>.
> ... isn't this just the kind of thing API versioning is for?
Sometimes. Folk talk about both "major versions"
and "minor versions". Incompatible changes, as a
rule, only show up in "major versions" which are
widely advertised as breaking things, and forcing
rewrites of applications.
There have to be very strong reasons for the user
community to adopt such incompatible changes.
Coping with a W3C inconsistency-du-jour seems
to be at best a weak reason to start defining a
SAX3 that's incompatible with SAX2 ... :)
- 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-devel] Re: SAX and namespace attributes
Posted by David Brownell <da...@pacbell.net>.
Arnaud, who is the "you" being addressed? I notice you sent
"To:" a Xerces list, not the SAX developer list...
Please reread my original response. I said that could be done,
but doubted it would be beneficial since it would just increase
the number of optional (== bug-friendly) code paths in layers
using the API. (No RFE filed yet either, FWIW.)
Re "particularly painful" ... it's unclear what you mean by
that, but please remember that this problem arose because
W3C defined specs that are self-inconsistent.
If you're just saying don't want painful API transitions,
then I hope you won't find disagreement! That's been
the whole premise of SAX2 "extensions" from day one.
- Dave
----- Original Message -----
From: "Arnaud Le Hors" <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <sa...@lists.sourceforge.net>
Sent: Tuesday, November 27, 2001 11:52 AM
Subject: Re: [Sax-devel] Re: SAX and namespace attributes
> Are you ruling out the option of having a new feature that allows the
> application to ask for the new behavior? This feature off by default would
> allow for changes while keeping full backwards compatibility.
> I know in SAX2 you decided to reinvent most of the interfaces but I hope
> this isn't to say that it's the only way new versions will be defined from
> now on. I find this particularly painful as it very significantly raises the
> cost of moving from one version to another.
> --
> Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
>
> _______________________________________________
> sax-devel mailing list
> sax-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sax-devel
---------------------------------------------------------------------
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-devel] Re: SAX and namespace attributes
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Are you ruling out the option of having a new feature that allows the
application to ask for the new behavior? This feature off by default would
allow for changes while keeping full backwards compatibility.
I know in SAX2 you decided to reinvent most of the interfaces but I hope
this isn't to say that it's the only way new versions will be defined from
now on. I find this particularly painful as it very significantly raises the
cost of moving from one version to another.
--
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-devel] Re: SAX and namespace attributes
Posted by Gunnlaugur Thor Briem <gt...@dimon.is>.
Oops,
my gripe was actually not about the namespace of NS nodes
issue, but about the use of the empty string instead of
null, for "no value" of the namespaceURI and qName args
... but it's equivalent, a desired change that is resisted
by the (entirely reasonable) inertia of an open API spec.
Another issue is de facto compliance ... are most drivers
complying already, or would the API change perhaps just
be breaking about as many as are already broken? I dunno,
just speculating! SAX is itself a de facto standard, so
de facto compliance should probably be a consideration in
the cost estimate.
In the present state of affairs we'll all end up writing
our apps to check both cases for robustness, I guess.
That's a small but permanent cost, whereas the API change
would be a larger but one-time cost.
OK, enough one-and-a-half cents from me! :)
Cheers,
- Gulli
> -----Original Message-----
> From: Gunnlaugur Thor Briem [mailto:gthb@dimon.is]
> Sent: 27. november 2001 19:13
> To: xerces-j-dev@xml.apache.org
> Cc: sax-devel@lists.sourceforge.net
> Subject: RE: [Sax-devel] Re: SAX and namespace attributes
>
>
> Hi,
>
> I may be taking a naive view here, so please excuse
> me if I'm making you roll your eyes, but isn't this
> just the kind of thing API versioning is for? If SAX2
... [snip]
---------------------------------------------------------------------
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-devel] Re: SAX and namespace attributes
Posted by Gunnlaugur Thor Briem <gt...@dimon.is>.
Hi,
I may be taking a naive view here, so please excuse
me if I'm making you roll your eyes, but isn't this
just the kind of thing API versioning is for? If SAX2
as specified requires applications to expect empty
instead of null, then that's that and we can grumble
about it all we want, but if you change it, it just
has to be in a different version, SAX2.1 or SAX3 or
whatever. As long as the definition of each version
of the API is clear, then SAX2 drivers behave well
with SAX2 apps, and SAX3 drivers behave well with
SAX3 apps.
SAX1 apps weren't compatible with SAX2 drivers either
(different interface name altogether), so there is
precedent for completely non-backwards-compatible API
changes here. And I guess it's not just limited to
new major versions, since David maintains there's no
such thing as a backwards-compatible API change at
all, minor or major (unless minor versions are only
supposed to be documentation fixes only?)
I understand that rolling out a new major version of
SAX is not something you do at the drop of a hat :)
but SAX2 still isn't conceived of as "final" anyway,
is it? So if other changes are made, then this change
can be made at the same time, since *any* change is
going to be non-backwards-compatible anyway. Right?
(i.e. this will change *sometime*, right? Please? :)
Cheers,
- Gulli
> -----Original Message-----
> From: David Megginson [mailto:david@megginson.com]
> Sent: 27. november 2001 16:20
> To: xerces-j-dev@xml.apache.org; sax-devel@lists.sourceforge.net
> Subject: Re: [Sax-devel] Re: SAX and namespace attributes
>
>
> Elena Litani writes:
>
> > I don't think adopting this change will break backwards
> > compatibility: the information that users get today will remain
> > unchanged. We will provide one additional piece of information -
> > namespace for namespace attributes and I don't see how this may
> > break users code... ?
>
> Wrong. There's no such thing as a backwards-compatible change to an
> API: either you break the drivers or you break the clients. In this
> case, clients that expect the old behaviour will probably be OK
> (they're unlikely to rely on the Namespace URI being null), but
> clients that expect the new behaviour will break on SAX drivers that
> implement the old behaviour. This will be a typical bug report:
>
> I'm using the ACME Java game development kit, and it requires a SAX2
> parser. I installed the FooBar parser, which says it is
> SAX2-conformant, and now I get a NullPointerException. Can anyone help?
>
> > I believe that it is better to try to expose consistent information
> > via different APIs (e.g. DOM/SAX).
>
> I think that's a worthy goal (that's why I pushed the W3C to create
> the Infoset WG in the first place) but denying the costs isn't the
> right way to get there. You have to start by acknowledging that this
> is a major change that will break all existing SAX2 *drivers*, and
> then decide if (or when) the benefits of making the change will
> outweigh the costs.
>
>
> All the best,
>
>
> David
>
> --
> David Megginson
> david@megginson.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
---------------------------------------------------------------------
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-devel] Re: SAX and namespace attributes
Posted by David Megginson <da...@megginson.com>.
Elena Litani writes:
> I don't think adopting this change will break backwards
> compatibility: the information that users get today will remain
> unchanged. We will provide one additional piece of information -
> namespace for namespace attributes and I don't see how this may
> break users code... ?
Wrong. There's no such thing as a backwards-compatible change to an
API: either you break the drivers or you break the clients. In this
case, clients that expect the old behaviour will probably be OK
(they're unlikely to rely on the Namespace URI being null), but
clients that expect the new behaviour will break on SAX drivers that
implement the old behaviour. This will be a typical bug report:
I'm using the ACME Java game development kit, and it requires a SAX2
parser. I installed the FooBar parser, which says it is
SAX2-conformant, and now I get a NullPointerException. Can anyone help?
> I believe that it is better to try to expose consistent information
> via different APIs (e.g. DOM/SAX).
I think that's a worthy goal (that's why I pushed the W3C to create
the Infoset WG in the first place) but denying the costs isn't the
right way to get there. You have to start by acknowledging that this
is a major change that will break all existing SAX2 *drivers*, and
then decide if (or when) the benefits of making the change will
outweigh the costs.
All the best,
David
--
David Megginson
david@megginson.com
---------------------------------------------------------------------
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
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
SAX spec bugs (was Re: [Sax-devel] Re: SAX and namespace attributes)
Posted by Edwin Goei <ed...@sun.com>.
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-devel] Re: SAX and namespace attributes
Posted by David Brownell <da...@pacbell.net>.
> > 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
knock-on impact to the application layers -- it's fairly certain that
some stable infrastructure would break in a hard-to-diagnose way.
That kind of minor incompatibility is actually worse to deal with than
a major incompatibility, since most things still work. Creating such
minor system breakage is like having a low level infection: things just
stop being as good as they were, and it's often never cured.
It's really not so hard for layers to tweak this, when they need to.
> I believe that it is better to try to expose consistent information ...
Me too, but when W3C causes such problems by changing their
own specifications to create internal inconsistencies, "better" is
the wrong game to play. A better one is "stable". (Sigh.)
I think that what I'll do for now is update the SAX2 docs to
identify this case. It's not a widely recognized issue.
- 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-devel] Re: SAX and namespace attributes
Posted by Elena Litani <el...@ca.ibm.com>.
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. We will
provide one additional piece of information - namespace for namespace
attributes and I don't see how this may break users code... ?
I believe that it is better to try to expose consistent information via
different APIs (e.g. DOM/SAX).
Since Infoset and DOM already require assigning a namespace to NS
attributes and I think it is only a matter of time the Namespace spec
requires it too, it is better to have a consistent model.
For more information, please refer to http://www.w3.org/2000/xmlns/
documentation.
--
Elena Litani / IBM Toronto
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org