<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I'm busy hunting through the specs to find a sensible answer to this
quandry too...<br>
<br>
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...<br>
<a class="moz-txt-link-freetext" href="http://www.w3.org/TR/xmlschema-0/#import">http://www.w3.org/TR/xmlschema-0/#import</a> <-- see the last
paragraph of 5.4:<br>
<br>
Quoting:<br>
When schema components are imported from multiple namespaces, each
namespace must be identified with a separate <code><a
href="http://www.w3.org/TR/xmlschema-0/#element-import">import</a></code>
element. The <code> <a
href="http://www.w3.org/TR/xmlschema-0/#element-import"> import</a></code>
elements themselves must appear as the first children of the <code><a
href="http://www.w3.org/TR/xmlschema-0/#element-schema"> schema</a></code>
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, <code><a
href="http://www.w3.org/TR/xmlschema-0/#element-import">import</a></code>
elements optionally contain a <code><a
href="http://www.w3.org/TR/xmlschema-0/#attribute-schemaLocation">schemaLocation</a></code>
attribute to help locate resources associated with the namespaces.
We discuss the <code><a
href="http://www.w3.org/TR/xmlschema-0/#attribute-schemaLocation">schemaLocation</a></code>
attribute in more detail in a later section. <br>
<br>
<br>
In theory, by spec, at least, there should be a way to positively
associate the namespace URI <a class="moz-txt-link-freetext" href="http://www.w3.org/1999/xlink">http://www.w3.org/1999/xlink</a> 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.<br>
<br>
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.<br>
<br>
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...<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Rolf<br>
<br>
On 07/08/2011 11:34 PM, Jason Hunter wrote:
<blockquote
cite="mid:119D72CF-1AA2-4969-9D72-A243FF8F5B7C@servlets.com"
type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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 = <a class="moz-txt-link-freetext" href="http://www.loc.gov/mods/v3">http://www.loc.gov/mods/v3</a>
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 = <a class="moz-txt-link-freetext" href="http://www.w3.org/1999/xlink">http://www.w3.org/1999/xlink</a>
attribute type = CDATA
attribute value = simple
********************************************
namespaceURI = <a class="moz-txt-link-freetext" href="http://www.loc.gov/mods/v3">http://www.loc.gov/mods/v3</a>
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:
<a class="moz-txt-link-freetext" href="http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com">http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
To control your jdom-interest membership:
<a class="moz-txt-link-freetext" href="http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com">http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com</a>
</pre>
</blockquote>
<br>
</body>
</html>