The fact that the digester allows for loose interpretation of the standard does
1. old parsers
2. developers lacking knowledge about proper use of namespaces.
If we want to maintain backward support for incorrect behavior, then that is
fine, make it the exception, not the rule. Incorrect behavior SHOULD break.
Don't discourage forward progress and use of the digester for modern purposes
because people want to use what is actually buggy software in terms of the new
specs or modern parsers. This leads to nothing but confusion, and now stands as
a barrier to adoption for those who want to start using it but cannot get it to
I understand how we got here, and thats ok. We have to move forward. I believe
the solution is:
1. commit the code, it is correct
2. allow the code to be incompatible with previous versions. For those who want
to stay at a historical point in time, the maven repository has all releases
There are even more changes that I've run across that I've been hesitant to
change, and it is to the point that either the digester fully understands
namespaces or I need to find a new project that will do the same thing. I just
need something that exhibits behavior that is concurrent with the standards and
(In reply to comment #4)
> Hi Kurt
> Please understand's not quite as simple as that.
> 1. Digester is used extensively where loosy binding is perfectly accceptable.
> 2. Digester is old and flexible enough to have to worry about maintaining
> compatibility with parsers which are not namespace aware.
> However, in this case I've taken a look at the DOM specification and believe
> that the passage of code in question is just buggy. DOM expects the qualified
> (and not the local) name. I suspect that this is so that it can extract the
> prefix for it's own uses. My reading of the API implies that the Element parses
> the qualified name to extract the local name itself. Therefore, applying this
> patch should not change the existing behaviour and so will do no harm.
> Probably worth creating a unit test for the case where there is no namespace,