[jdom-interest] Preparing JDOM 1.1.2 ?

Rolf jdom at tuis.net
Wed Aug 31 22:36:42 PDT 2011


I have committed the change I suggested in to the JDOM2 branch (master).

https://github.com/hunterhacker/jdom/commit/7ff5828dffdda871f418632604df0739c76651a5

This has helped me by allowing me put through 'passing' junit tests on 
the JDOM2 code base.

On the other hand, I have spent a number of hours (too many) considering 
this issue, and am still not 100% satisfied with the options, etc.

Specifically, I investigated using an XMLFilter for the SAX Parser and 
while it seems like a good idea at first, it quickly becomes a problem 
when you realize that the filter would have to keep track of a complete 
namespace stack in order to choose/build the correct prefix on the 
occasions that it is needed. This is inconvenient for the same reason 
that Thomas's patch, that it has to duplicate the bulk of the complexity 
of namespace tracking that is already built in to JDOM.

Additionally, I am not happy with the fact that the only parser I hav 
tested has been xerces. That feels like bad planning.

So, I have pushed through my code fix as a stop-gap, until someone can 
think of a better solution.... or until the 'feeder' systems (xerces) 
themselves are fixed.

If by the end of next week (about the 9th september) there is still no 
better alternative then I will likely push the same fix through in to 
the 1.1.2 release.

Rolf

On 25/08/2011 11:24 PM, Rolf Lear wrote:
> On 25/08/2011 9:54 PM, Elliotte Rusty Harold wrote:
>> I don't have a github account but something is off here, and it may
>> not be JDOM. Jason says:
>>
>> "I did a simple test and printed out what was being given to SAXHandler
>> by the parser. Sure enough, on this document when validation is turn
>> on, the SAX parser is reporting two attributes with the same qname
>> (which happens to be the local name since they are both unprefix), but
>> in different namespaces."
>>
>> That should *NOT* be happening. There is no such thing as an
>> unprefixed attribute that is in a namespace. That simply does not
>> exist in XML. If the parser is reporting such an attribute, the parser
>> is *wrong*. If XML Schema can define an unprefixed attribute in a
>> namespace, then XML Schema is *wrong*.
>>
>
> Hi Elliotte
>
> I think everyone is in violent agreement here... it sucks, and it's
> 'wrong'.
>
> XMLSchema should make it clear what should happen in this case, but XSD
> 1.0 is 'clear' that it should do nothing, and XSD 1.1 has partial
> coverage of the issue... (or, if you interpret it in just the right way,
> it does cover it, and say the prefix should be generated by the parser).
>
> Xerces (the parser) currently takes the XSD1.0 view, and claims that
> it's 'right' to not be prefixing the attributes.
>
> JDOM is the victim (other than the end user like Thomas) because it is
> getting bad information, and then doing worse things with it.
>
> Michael filed a 'ticket' against XMLSchema (1.1) to clarify/resolve it.
> You can see the discussion at:
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=13750
>
> I filed a ticket against xerces at:
> https://issues.apache.org/jira/browse/XERCESJ-1524
>
> Then there is the JDOM issue at:
> https://github.com/hunterhacker/jdom/issues/1
>
> ahh, you found it.
>
> Rolf
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com
>



More information about the jdom-interest mailing list