Re: Parsing a MODS-document with validation fails

I'm busy hunting through the specs to find a sensible answer to this 
quandry too...

My take is that it may be an issue with the parser, in the sense that, 
by the spec, when you import an XSD in to another, there needs to be a 
prefix declared for that namespace/import...
http://www.w3.org/TR/xmlschema-0/#import <-- see the last paragraph of 5.4:

Quoting:
When schema components are imported from multiple namespaces, each 
namespace must be identified with a separate |import 
<http://www.w3.org/TR/xmlschema-0/#element-import>| element. The |import 
<http://www.w3.org/TR/xmlschema-0/#element-import>| elements themselves 
must appear as the first children of the |schema 
<http://www.w3.org/TR/xmlschema-0/#element-schema>| element. 
Furthermore, each namespace must be associated with a prefix, using a 
standard namespace declaration, and that prefix is used to qualify 
references to any schema components belonging to that namespace. 
Finally, |import <http://www.w3.org/TR/xmlschema-0/#element-import>| 
elements optionally contain a |schemaLocation 
<http://www.w3.org/TR/xmlschema-0/#attribute-schemaLocation>| attribute 
to help locate resources associated with the namespaces. We discuss the 
|schemaLocation 
<http://www.w3.org/TR/xmlschema-0/#attribute-schemaLocation>| attribute 
in more detail in a later section.


In theory, by spec, at least, there should be a way to positively 
associate the namespace URI http://www.w3.org/1999/xlink with the prefix 
'xlink'. Both by the declaration on the main document, and the duplicate 
declaration on the XSD as part of the import requirements.

The way I see it is that the parser should be providing the correct 
prefix 'xlink' with the attribute, and it is a parser bug.

What is confusing me is the duplicate declaration of the xlink 
namespace, once on the main document, and the second time in it's XSD... 
I wonder if that is where the confusion lies...

Anyway, based on my initial inspection, it should be possible to 
*always* scan up the JDOM tree to find a namespace matching the 
attribute's URI, and then reuse that prefix.

This is a test/process that could be used for any attribute, not just 
those cases where you have a duplicate declaration for a local name.

Unfortunately, it's 23:53 for me, and my head is a little twisted up by 
this issue right now... so I need a fresh look at it too.... I can't 
even seem to be able to put together a 'simple' test case with all the 
confusing extraneous stuff removed.

But, as for the ns0 'default' name, I think that is a poor solution, and 
that it should be possible to scan up the tree to find a real prefix for 
that namespace... If the parser is not going to provide it, I think the 
JDOM SAX Handler can fall back on a work-around solution that does not 
'lose' the attribute - a solution that is a combination of Thomas's fix, 
and a smarter prefix determination routine.

Rolf

On 07/08/2011 11:34 PM, Jason Hunter wrote:
> I tested the same thing with DOMBuilder.  It shows two attributes with the same name on the same element.
>
> name: type
> value: simple
>
> name: type
> value: personal
>
> My guess is in Thomas' sample code it's the transform action that did the ns0 addition.
>
> JDOM doesn't error out when it sees this, the code just lets setAttribute() overwrite any previous assignments.
>
> It seems like the input is technically malformed.  Has there been official advice given on what an object model should do in this case?
>
> -jh-
>
> On Aug 7, 2011, at 12:42 PM, Bradley S. Huffman wrote:
>
>> 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.
>>
>> JDOM should take the events as presented and build a object tree to
>> represent it.  It shouldn't "generate" anything.  However, in this
>> case I don't know who to point the finger at, but it's not JDOM.
>>
>> Elliotte, are you still lurking around?
>>
>> ********************************************
>> namespaceURI = http://www.loc.gov/mods/v3
>> localName = name
>> qName = name
>> attribute local name = type
>> attribute qname = type
>> attribute uri =
>> attribute type = CDATA
>> attribute value = personal
>> attribute local name = type
>> attribute qname = type
>> attribute uri = http://www.w3.org/1999/xlink
>> attribute type = CDATA
>> attribute value = simple
>> ********************************************
>> namespaceURI = http://www.loc.gov/mods/v3
>> localName = namePart
>> qName = namePart
>> attribute local name = type
>> attribute qname = type
>> attribute uri =
>> attribute type = CDATA
>> attribute value = family
>> _______________________________________________
>> 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]
>

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