conciliator
conciliator

Reputation: 6138

Trouble understanding particular XSD validation result (Xceres)

I'm implementing a XML solution conforming to two externally provided XSDs. First, we have ns1.xsd:

<schema xmlns:ns1="http://www.test.com/ns1" 
        xmlns:ns2="http://www.test.com/ns2" 
        xmlns:xsd="http://www.w3.org/2001/XMLSchema.xsd" 
        xmlns="http://www.w3.org/2001/XMLSchema" 
        targetNamespace="http://www.test.com/ns1" 
        elementFormDefault="qualified">
    <import namespace="http://www.test.com/ns2" 
        schemaLocation="http://www.test.com/ns2.xsd"/>
    <element name="Root">
        <complexType>
            <sequence>
                <element name="Child" type="ns2:ChildType" 
                         minOccurs="0"/>
            </sequence>
        </complexType>
        <attribute ref="ns2:field3" use="optional"/>
    </element>
</schema>

and ns2.xsd:

<schema xmlns:ns2="http://www.test.com/ns2" xmlns:xsd="http://www.w3.org/2001/XMLSchema.xsd" xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.test.com/ns2" elementFormDefault="qualified" attributeFormDefault="qualified">
    <complexType name="ChildType">
        <attribute name="field1" type="string" use="optional"/>
        <attribute name="field2" type="string" use="optional"/>
    </complexType>
    <attribute name="field3" type="string"/>
</schema>

Over at liquid-technologies.com there is a tutorial showing how XSDs using referenced types should be implemented. Following that logic, I get:

<?xml version="1.0" encoding="UTF-8"?>
<Root xmlns="http://www.test.com/ns1" 
      xmlns:ns2="http://www.test.com/ns2" 
      ns2:field3="test">
    <Child ns2:field1="test" ns2:field2="test"/>
</Root>

which validates using Xerces 2.11.0. If I change attributeFormDefault="unqualified" in ns2.xsd I have to drop the namespace prefixes in the implementation to get it to validate:

<?xml version="1.0" encoding="UTF-8"?>
<Root xmlns="http://www.test.com/ns1" 
      xmlns:ns2="http://www.test.com/ns2" 
      ns2:field3="test">
    <Child field1="test" field2="test"/>
</Root>

As I asked a while back, field3 is (correctly) still prefixed. Now I wonder:

  1. What is the true difference between field1 and field2 in contrast to field3? Why do Xceres force me to omit prefixes for field1 and field2? Is it because field1 and field2 are really part of a type while field3 is a reference to an attribute?
  2. How do the receiver tell what namespace attributes field1 and field2 belongs to in the second case?

(And if anyone know what part of the W3C recs that describe these rules, I'd be really greatful for that too.)

Additional info

I feel an urge for pointing out the consequences of this example. In case 1 field1 and field2 are prefixed with ns2 which clearly establish them as attribute names in the ns2-namespace. In case 2, where neither of said attribute names are prefixed, it is hard to come to any other conclusion than these attributes belongs to the default (ns1) namespace.

Why does this matter? Well, this matters because it has effectivly turned attributeFormDefault into a namespace qualifier. I have serious problems understanding how this was the intention of the W3C committee, and thus I consider it a bug. If anyone can enlighten me, I'd be thrilled!

Upvotes: 1

Views: 149

Answers (1)

Michael Kay
Michael Kay

Reputation: 163458

Attributes that are not prefixed are generally taken as being in no namespace. They are not in the default namespace. (I say generally, because there are some people who prefer a different interpretation, like that they are in an unspecified namespace, but such distinctions are too subtle for me.)

When you say attributeFormDefault="unqualified", locally-declared attributes in the schema document for ns2 will be in no namespace, which means they must appear in the instance with no prefix.

As for ns2:field3, this is a little odd because there doesn't seem to be a declaration for the attribute. But if there were one, it would have to be a global attribute declaration, and global attributes always go in the target namespace of the containing schema document.

Upvotes: 1

Related Questions