Re: Parsing a MODS-document with validation fails

Hi All.

Thanks for looking in to this Michael. I had a look on the xerces side, 
and came up with: https://issues.apache.org/jira/browse/XERCESJ-1474

More interestingly, this exact issue (the one with MODS documents) 
appears to have been identified in 2002: 
https://issues.apache.org/jira/browse/XERCESJ-455

That issue is marked "Won't fix", with the comment: I agree it's a bug, 
but it's not that easy to fix. The problem is what prefix to use for the 
new attribute. I'll think about it more.

The bottom line appears to be that everybody may be right, everybody may 
be wrong: Here's the comment on XERCESJ-1474:

    Michael Glavassevich
    <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=mrglavas%40ca.ibm.com>
    added a comment - 12/Nov/10 18:19
    The conclusions you are drawing are incorrect. Please review the
    section of the schema specification on attribute default values [1].
    Only a [local name] and [namespace name] are contributed to the
    PSVI. There is no prefix. XML Infosets can be constructed in other
    ways than by parsing (see synthetic infosets [2]) and may not be
    consistent with those that were constructed directly from an XML
    document. Your application should be relying on the namespace name
    not the prefix.

    [1]
    http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#d0e8328
    [2] http://www.w3.org/TR/xml-infoset/#intro.synthetic


By reading his referenced 'specs', it does indeed appear that the 
XMLSchema spec determines that the only contribution to the 'infoset' is 
the name and namspace, not the prefix. But, that was for XMLSChema1.0. 
The 'bug' you filed with XMLSchema is for the XMLSchema 1.1 recommendation.

I've tried with the latest xerces Jars, but it's still failing.... 
perhaps I should open up or reopen existing xerces bugs. In fact, I 
will, but I'll put together an xerces-specific test case.

While I feel that the XMLSchema spec has some cracks, my overall take on 
it is that Xerces should be providing the prefixed names... whether it 
is 'specified' that way, or not... but, I don't have the full 
perspective from the Xerces side.

Everyone is 'passing the buck'.

In the interim (the next 10 years before people adopt XMLSchema 1.1 
fully), it makes sense to do the 'belt&braces' approach and put in a 
work around that will keep working if/when the SAXParser 'does the right 
thing'.

Rolf

On 10/08/2011 1:20 PM, Michael Kay wrote:
>
>> 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
>>
>>
>>
>>   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'.
> This is what XSD 1.1 has to say about the attribute that is added to 
> the InfoSet (Part 1, section 3.4.5.1):
>
> <quote>
> [prefix]
> If the {attribute declaration} has a ·non-absent· {target namespace} 
> N, then a namespace prefix bound to N in the [in-scope namespaces] 
> property of the element information item in the 
> ·post-schema-validation infoset·. If the {attribute declaration}'s 
> {target namespace} is ·absent·, then ·absent·.
> If more than one prefix is bound to N in the [in-scope namespaces], it 
> is ·implementation-dependent· which of those prefixes is used.
> </quote>
>
> In this case the attribute declaration has a target namespace, and the 
> namespace prefix bound to N in the instance is "ns", so this prefix 
> should be used in the InfoSet and should be reflected in the SAX 
> events passed to the ContentHandler. I think this Xerces behaviour is 
> incorrect.
>>
>>
>>   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">
>>
>>
>>
> Yes, I think the latter is correct, but the XSD 1.1 spec is not clear 
> about this case. I will raise a bug. I think the answer is that in the 
> Infoset produced by the schema processor, an implementation-defined 
> prefix should be used; allocation of a prefix should be job of the 
> schema processor, not the consumer of the Infoset.
>
> Unfortunately the Infoset spec is rather weak on defining constraints. 
> XDM is clearer: see http://www.w3.org/TR/xpath-datamodel/ section 
> 6.3.1 which states "in the node-name of an attribute node, if a 
> namespace URI is present then a prefix must also be present". A 
> consumer of the data model is entitled to expect these constraints to 
> be satisfied.
>
> I have raised an XSD 1.1 bug: 
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=13750
>
> Michael Kay
>

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