Re: Parsing a MODS-document with validation fails

Hi Michael.

Feel free to butt-in!

As a 'summary' for you, I believe that there are 'valid' and 'specified' 
instances where you *may* get attributes in a namespace where there's no 
prefix for the attribute's qName from the SAX Parser.

It would be great if you could look in to it, and help decide whether it 
is an issue that needs fixing in JDOM, or whether it is something that 
needs a work-around, or a bug-report to Xerces/SAX, whatever.

Of course, I've read the (relevant parts of the) specs, and, these 
particular use cases appear to fall through the cracks a bit, so it is 
very hard to assign 'blame' for where the parsing 'fails'.

Specifically, I believe there are three broad conditions for all 
"attributes in a namspace":
1. The normal condition where an attribute in a namespace is given to 
the startElement() method with the correct (prefixed) qname.
2. The 'unusual' condition where an attribute is in a namespace, and the 
namespace is available with a prefix, but the SAX Parser(Xerces) does 
not set that prefix on the qName (maybe an xerces bug?)
3. The even more unusual condition where an attribute is in a namespace, 
but there is no declared version of that namespace with a prefix, and 
SAXParser has an unqualified qName


You should be able to test these conditions 'easily'.


  Situation 1


The normal situation:

<doc xmlns:attns="myns" attns:att="value" />

in this case, the co-ordinates for the attribute as supplied in 
startElement are: localname=att    qName=attns:att    value=defval    
URI=myns


  Situation 2


The second and third examples both rely on there being a 'default' or 
'fixed' attribute of form="qualified" declared on an XML Schema. For 
example with the XMLSchema:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="myns"
         xmlns:xs="http://www.w3.org/2001/XMLSchema"  targetNamespace="myns"
         elementFormDefault="qualified">
   <xs:element name="doc">
     <xs:complexType>
       *<xs:attribute name="att" default="defval" form="qualified"/>*
     </xs:complexType>
   </xs:element>
</xs:schema>


With the above schema, here are two representative documents. The first 
document is a representation of situation 2, where the SAX parser 
'should' know the prefix for the attribute:

<ns:doc xmlns:ns="myns"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation="myns ./MySchema.xsd">


This should be parsed by the SAXParser, and it should add in the 
'default' attribute 'att' as part of the startElement() call. The 
resulting 'parsed' document 'should' look like:

<ns:doc *ns:att="defval"*
                xmlns:ns="myns"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation="myns ./MySchema.xsd">


But, using xerces, the SAXParser is giving the 'co-ordinates' of the 
'att' attribute as   localname=att    qName=att    value=defval    URI=myns

This is situation 2, where it would 'make sense' for the parser to 
specify the qName as 'ns:att' instead of just 'att'.


  Situation 3


Situation 3 is like situation 2, but gives the SAXParser less 
information to go on. This situation uses the exact same XMLSchema as 
situation2, only it does not declare a 'prefixed' namespace, just a 
'default' namespace.

<doc xmlns="myns"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation="myns ./MySchema.xsd">

In this case, we expect the default attribute 'att' to be added to the 
schema, but in the 'myns' namespace. Unfortunately there is *NO* 
declaration for that namespace which is 'prefixed'.

The following is the *wrong* result (att attribute should be in 'myns' 
namespace!):

<doc *att="defval"*
                xmlns="myns"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation="myns ./MySchema.xsd">

The real question is 'What is the correct result'....? Is the following 
'correct' ?

<doc *attns0:att="defval" xmlns:attns0="myns"*
                xmlns="myns"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation="myns ./MySchema.xsd">


Not sure how that affects Saxon, but it should be easy to get some idea.

Rolf



On 10/08/2011 5:03 AM, Michael Kay wrote:
>
>> You are right, it is extra work to maintain these structures for a 
>> case that no one hit before. One can find arguments for one or the 
>> other solution. The amount of addition memory should be negligible 
>> but my patch introduced a bit of work while parsing every document 
>> while you suggested changes seems to produce more work in the rare 
>> case that...
>
>
> Forgive me butting in to a thread that I've only been skim-reading 
> until now. But I thought I would look at what Saxon does about this 
> problem.
>
> Firstly, Saxon states in its documentation that it expects the stream 
> of ContentHandler events to correspond to those that come from a 
> parser that has been configured with namespaces="true" and 
> namespace-prefixes="false". It has no way of checking this in general 
> (though it does so on paths where it has access to the XMLReader).
>
> Saxon does a few checks on the consistency of the event stream where 
> these can be done cheaply. For example, it checks for the attribute 
> names "xmlns" and "xmlns:*" and ignores them if they appear, even 
> though they shouldn't appear in theory.
>
> But there's one area Saxon relies on something that isn't guaranteed 
> by the SAX spec, namely it assumes that the QName will be present and 
> correct, even though it is optional when namespace-prefixes="false". I 
> made this decision because all known XML parsers supply the QName, and 
> because coping with its absence would incur significant cost on a 
> performance-critical path. I've reasoned in the path that if someone 
> needs to work with a source of SAX events that doesn't supply the 
> QName, a filter could be added to the pipeline to make good the 
> deficiency.
>
> In this particular case, if I've understood the thread correctly, the 
> QName is present but doesn't contain a legitimate prefix. In Saxon 
> (where I'm sure the same sequence of SAX events might be received) I 
> think I would have similar problems in dealing with this input. My 
> response to a bug report on this would be that the input is invalid 
> according to the SAX spec and should be corrected by inserting a 
> filter: there is an implicit constraint that the stream of SAX events 
> represents a well-formed XML document, and in a well-formed XML 
> document, if an attribute is in a namespace then it must have a 
> prefix. I wouldn't be prepared to add a performance penalty into the 
> mainstream document building path in order to detect or repair this 
> rare anomaly.
>
> Michael Kay
> Saxonica
>
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/[email protected]
>

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/[email protected]