namespace doubt

[amit sharma]

CASE-I

<?xml version="1.0" encoding="UTF-8"?>
<address
xmlns="http://www.Monson-Haefel.com/jwsbook" >

<name>AMAZON.COM</name>
<street>1850 Mercer Drive</street>
<city>Lexington</city>
<state>KY</state>
<zip>40511</zip>
<address>

Ok in this case all elements are under default namespace

But what about this
CASE - II
<?xml version="1.0" encoding="UTF-8"?>
<addr:address
xmlns:addr="http://www.Monson-Haefel.com/jwsbook" >

<name>AMAZON.COM</name>
<street>1850 Mercer Drive</street>
<city>Lexington</city>
<state>KY</state>
<zip>40511</zip>
</addr:address>

In this case will the child elements (<name>, <street> etc) inherit the namespace of <address> element.


CASE - III

<?xml version="1.0" encoding="UTF-8" ?>
<purchaseOrder orderDate="2003-09-22"
xmlns="http://www.Monson-Haefel.com/jwsbook/PO">
<accountName>Amazon.com</accountName>
<accountNumber>923</accountNumber>

<addr:address xmlns:addr="http://www.Monson-Haefel.com/jwsbook/ADDR">
<name>AMAZON.COM</name>
<street>1850 Mercer Drive</street>
<city>Lexington</city>
<state>KY</state>
<zip>40511</zip>
</addr:address>

<book>
<title>J2EE Web Services</title>
<quantity>300</quantity>
<wholesale-price>29.99</wholesale-price>
</book>
<total>8997.00</total>
</purchaseOrder>

In this case what is the namespace of child elements (<name>, <street> etc)

[Pedro Erencia]

I'd say it's http://www.Monson-Haefel.com/jwsbook/ADDR, since it overrides default namespace.

[Niranjan Deshpande]

Yeah..me too think the same..

[Peer Reynders]

Originally posted by Pedro Erencia:
I'd say it's {http://www.Monson-Haefel.com/jwsbook/ADDR}, since it overrides default namespace.

how does xmlns:addr="http://www.Monson-Haefel.com/jwsbook/ADDR" override the default namespace?

In the absence of a schema that specifies the attribute elementFormDefault="qualified" the child elements are automatically assumed to be in the namespace of the parent - however that doesn't mean that the namespace of the parent becomes the default namespace.

CASE III has two possible answers:

The child elements are in the {http://www.Monson-Haefel.com/jwsbook/ADDR} namespace IF the relevant schema doesn't specify elementFormDefault="qualified" - as the child elements inherit the namespace from the parent.

The child elements are in the {http://www.Monson-Haefel.com/jwsbook/PO} namespace IF the relevant schema specifies elementFormDefault="qualified" - as the lack of a prefix clearly indicates that the elements belong to the default namespace.

This even expands to CASE II:

The child elements are in the {http://www.Monson-Haefel.com/jwsbook} namespace IF the relevant schema doesn't specify elementFormDefault="qualified" - as the child elements assume the namespace from the parent.

The child elements are not in any namespace IF the relevant schema specifies elementFormDefault="qualified" - there isn't a default namespace so the lack of a prefix means that they don't belong to any namespace at all.

This can get pretty confusing. That is why the WS-I Basic Profile forces you to always use elementFormDefault="qualified" for XML inside the SOAP body. It puts an end to child elements being automatically in the parent's namespace. If there is no prefix the element is in the default namespace if there is a default namespace - if there is no default namespace the element doesn't belong to any namespace.

Basic Profile 1.0 - 4.1.13

4.1.13 SOAP Body and Namespaces
The use of unqualified element names may cause naming conflicts, therefore qualified names must be used for the children of soap:Body.

R1014 The children of the soap:Body element in a MESSAGE MUST be namespace qualified.

BTW: if you see xmlns="" - that means that the default namespace is being cancelled. An empty string cannot be a valid namespace name because a namespace name must be a valid URI (not to be confused with a URL). So if there is an element that doesn't have a prefix and there is no default namespace and it is not in its parents namespace then that element does not belong to any namespace (there is no null namespace).

See also
NameSpaces doubt
Confused in XML Schema
[ May 07, 2008: Message edited by: Peer Reynders ]

[Niranjan Deshpande]

[Pedro Erencia]

Thanks Peer, great post..

That said, i disagree with you in some aspects..

CASE III has two possible answers:

* The child elements are in the {http://www.Monson-Haefel.com/jwsbook/ADDR} namespace IF the relevant schema doesn't specify elementFormDefault="qualified" - as the child elements inherit the namespace from the parent.
* The child elements are in the {http://www.Monson-Haefel.com/jwsbook/PO} namespace IF the relevant schema specifies elementFormDefault="qualified" - as the lack of a prefix clearly indicates that the elements belong to the default namespace.

For me, CASE III has just one answer, and that is
* The child elements are in the {http://www.Monson-Haefel.com/jwsbook/PO}


The point where i get confused was in thinking that

 <addr:address xmlns:addr="http://www.Monson-Haefel.com/jwsbook/ADDR">

overrides default namespace. That is wrong. In that case the ADDR namespace is only applied to address.

To override default namespace the code must be..

 
<address xmlns="http://www.Monson-Haefel.com/jwsbook/ADDR">

Then all the childs of address would belong to {http://www.Monson-Haefel.com/jwsbook/ADDR}.

All of that is based on RMH 2.2.2 Default Namespaces, Prefixes, and Qualified Names and 3.1.6 Qualified and Unqualified Elements.

The point where i disagree with you is in the use of the schema. Wheter an element belongs to a namespace or another has nothing to do with the schema. The childs of address belong to the PO namespace regardless of what the schema elementFormDefault value is.

This can get pretty confusing. That is why the WS-I Basic Profile forces you to always use elementFormDefault="qualified" for XML inside the SOAP body. It puts an end to child elements being automatically in the parent's namespace...

It doesn't put an end to it.. As you said in the first quote, the elements still belonging to the parent's namespace..

For me the point now is in your quote on BP..

4.1.13 SOAP Body and Namespaces
The use of unqualified element names may cause naming conflicts, therefore qualified names must be used for the children of soap:Body.

It only says that we can't do something like this

 
 
<soap:Body>
<address xmlns="http://uri">
<city/>
</address>
</soap:Body>
 
 

In that case the element "city" could be associated with a namespace other than "http://uri"..
So I suppose that is the motivation to make the body local elements qualified.. It's probably what you meant but the terms seemed confusing to me

[ May 07, 2008: Message edited by: Pedro Erencia ]
[ May 07, 2008: Message edited by: Pedro Erencia ]

[Peer Reynders]

Originally posted by Pedro Erencia:
It only says that we can't do something like this

<soap:Body>
   <address xmlns="http://uri">
      <city/>
  </address>
</soap:Body>

In that case the element "city" could be associated with a namespace other than "http://uri"

What the BP is saying is that in fact the above construct is allowed because the constraint of assuming "qualified" removes any ambiguity from the above construct. When you assume elementFormDefault="qualified" "city" is clearly in the default namespace - therefore its qualified name is {http://uri}city.

<soap:Body>
   <addr:address xmlns="http://uri" xmlns:addr="http://otheruri" >
      <city/>
  </addr:address>
</soap:Body>

This is the case that the BP is worried about and again because of the imposed constraint of elementFormDefault="qualified" there isn't a problem. That attribute declares that local qualified names are required and guarantees that local unqualified names will not be used.

XML Schema Part 0: Primer Second Edition: 3.1 Target Namespaces and Unqualified Locals

Ronald Bourret XML Namespaces FAQ: 8.2) What are qualified and unqualified local names in XML Schemas?

So under BP we know that once again "city"'s qualified name is {http://uri}city.

Without BP and its assumption of local qualified names you revert back to "unqualified" which is the default for plain XML. As now local unqualified names can and will be used "city" is subject to a naming collision (if both schemas contain a "city" element) because we cannot tell whether its qualified name is {http://uri}city or {http://otheruri}city.


In the first item of CASE III I arbitrarily chose to break the tie by proximity. In fact in plain XML which permits local unqualified names name, street, city, state, and zip could simply be local unqualified names OR belong to the default namespace - there is no way tell. At this point you have to check whether these elements actually exist in the respective namespaces - and if they exist in both namespaces then you are dealing with a naming collision. Once you require local qualified names your problems go away.

So elementFormDefault="qualified" doesn't mean that every element has to have a prefix - it simply disallows the use of local unqualified names. It then follows that any element without a prefix either belongs to the default namespace if one has been declared or it doesn't belong to a namespace at all.
[ May 07, 2008: Message edited by: Peer Reynders ]

[Pedro Erencia]

Without BP and its assumption of local qualified names you revert back to "unqualified" which is the default for plain XML. As now local unqualified names can and will be used "city" is subject to a naming collision (if both schemas contain a "city" element) because we cannot tell whether its qualified name is {http://uri}city or {http://otheruri}city.

That's correct. I didn't put enough care when writting the example.

In the first item of CASE III I arbitrarily chose to break the tie by proximity. In fact in plain XML which permits local unqualified names name, street, city, state, and zip [BOLD]could simply be local unqualified names OR belong to the default namespace - there is no way tell. [/BOLD]
At this point you have to check whether these elements actually exist in the respective namespaces - and if they exist in both namespaces then you are dealing with a naming collision. Once you require local qualified names your problems go away.

how it can be local unqualified OR belong to the default namespace ?
When i talk about a qualify name i'm referring to a name which has been assigned a namespace, regardless of the corresponding definition on a schema.
So in the example, the names name, street, city and state are qualifed names. They can't be unqualified since they have been assigned the default namespace, even if the schema associated to that namespace doesn't have a name or city definitions.

I'm trying to understand what name collision means in this context, because as i understand there is no possibility to effectively make a name collision.
Could you please put an example of a name-collision that explains the statement i've quoted ?

[Peer Reynders]

Originally posted by Pedro Erencia:
how it can be local unqualified OR belong to the default namespace ?

if "unqualified locals" are permitted

and a default namespace has been declared

and a local element doesn't have a prefix

Does the "local" element belong to the default namespace or the namespace of the parent element? There is no way to know.

When i talk about a qualify name i'm referring to a name which has been assigned a namespace

A qualified name always identifies an element or attribute, e.g. {http://otheruri.org}city. "http://otheruri.org" is simply the URI (not URL) that identifies the namespace.

See James Clark: XML Namespaces for the curly brace notation.

Could you please put an example of a name-collision that explains the statement i've quoted ?

"unqualified locals" are permitted

a default namespace has been declared {http://www.Monson-Haefel.com/jwsbook/PO}

the parent element exists in a different namespace {http://www.Monson-Haefel.com/jwsbook/ADDR} from the default

"zip" element under parent element doesn't use a prefix

so the "zip" element could either mean {http://www.Monson-Haefel.com/jwsbook/ADDR}zip (if it is an unqualified local) or {http://www.Monson-Haefel.com/jwsbook/PO}zip (if it belongs to the default namespace).

There is no naming collision between {http://www.Monson-Haefel.com/jwsbook/ADDR}zip or {http://www.Monson-Haefel.com/jwsbook/PO}zip, however we can't tell which one the "zip" element is - so the "zip" element creates the naming collision.

Once we disallow "unqualified locals" and require "qualified locals" we know that we are dealing with {http://www.Monson-Haefel.com/jwsbook/PO}zip.

The problem is that is that an association has been created: "qualified = prefixed" and "unqualified = unprefixed"

However

An "unqualified local" element doesn't use a prefix

An element in the default namespace doesn't use a prefix

An element that doesn't belong to any namespace doesn't use a prefix.

So whenever you see an element without a prefix how do you know what you are dealing with? All three don't use a prefix but one of them already uses "unqualified" for itself. So when you are talking about an "unqualified" element, are you talking about unprefixed elements in general or just "unqualified locals" in particular. So really "qualified = prefixed" and "unqualified = unprefixed" doesn't work. elementForDefault="qualified" underlines this because unprefixed elements can still be used - they are either an element in the default namespace or an element without a namespace depending on whether a default namespace is declared.
[ May 07, 2008: Message edited by: Peer Reynders ]

[Niranjan Deshpande]

[Peer Reynders]

Note that even the w3c documents have been updated in regards to what a "qualified name" is:

Namespaces in XML 1.0 (1999)

This one was the one that created the perception that "qualified = prefixed"


Namespaces in XML 1.0 (Second Edition, 2006): 4. Qualified Names

The update corrects that misconception as the namespace can be "contributed" through other means than the prefix, e.g. the default namespace.

2.1 Basic Concepts

Definition: A qualified name is a name subject to namespace interpretation.

Also note that the word "unqualified" is no longer used anywhere in the updated W3C recommendation - simply because it caused too much confusion. The terms used now are "qualified name", "prefixed name" and "unprefixed name".

Now it seems that every XML tag-name implicitly has a "qualified name" even if the name doesn't belong to any namespace basically rendering the term "unqualified name" meaningless.

2.1 Basic Concepts

Definition: An expanded name is a pair consisting of a namespace name and a local name.
Definition: For a name N in a namespace identified by a URI I, the namespace name is I. For a name N that is not in a namespace, the namespace name has no value.
Definition: In either case the local name is N.

Unfortunately the term "unqualified" is set in stone with reference to XML Schema because of the elementFormDefault and attributeFormDefault attribute. However in that context they are dealing with "unqualified locals" vs "qualified locals".


Have a look at Example: Purchase Order with Unqualified Locals, po1.xml

The unprefixed "street" tag-name is clearly assumed to be {http://www.example.com/PO1}street, not {NO NAMESPACE}street because "unqualified locals" are permitted and it is classified as such.

So if the interpretation of "{PARENT NAMESPACE}street" wins over "{NO NAMESPACE}street" then it would not be unreasonable to assume that "{PARENT NAMESPACE}street" also wins over "{DEFAULT NAMESPACE}street" once a default namespace has been declared. The absence of a default namespace simply means that the "interpreted" qualified name for an unprefixed name (that is not an "unqualified local") doesn't contain a "namespace portion".

Now also note that {http://www.example.com/PO1}comment is prefixed even though it is inside of {http://www.example.com/PO1}purchaseOrder - because {http://www.example.com/PO1}comment isn't a "local" but a "global" - {http://www.example.com/PO1}comment has been defined as a top level element in the schema - which means it has to have a prefix in this situation to be correctly interpreted.
[ May 08, 2008: Message edited by: Peer Reynders ]

[Pedro Erencia]

The unprefixed "street" tag-name is clearly assumed to be {http://www.example.com/PO1}street, not {NO NAMESPACE}street because "unqualified locals" are permitted and it is classified as such.

I don't think so. The unprefixed street is assumed to be {NO NAMESPACE}street, exactly because unqualified locals are a must according to the schema. That's why the instance is valid, because street is out of any namespace scope.
street doesn't inherits any namespace as it doesn't do shipTo. An unqualified local, in order to be valid, must be associated to {NO NAMESPACE}street.
[ May 08, 2008: Message edited by: Pedro Erencia ]

[Peer Reynders]

Now Listing 3-34 (p73) gives the XML Schema for {http://www.Monson-Haefel.com/addr} (mistyped later as {http://www.Monson-Haefel.com/ADDR}). Because the elementFormDefault attribute is not specified "unqualified" is in effect for "locals". None of the name, street, city, state, zip elements are top-level elements so they are all "local".

If I could verify this

The child elements (<id>, <thedate>, and <avalue>) are defined as local
elements (defined inside a complex type), and therefore must be unqualified.
Therefore the elements must include the "no default" namespace definitions
(xmlns=""). If you prefer to make these element qualified, you can add the
elementFormDefault="qualified" attribute to the <schema> definition. But
this issue really shouldn't make a difference.

Anne Thomas Manes

then we could say that the example in CASE III is incomplete (a modified version of Listing 3-17 p54) and should in fact be:

<addr:address xmlns="" xmlns:addr="http://www.Monson-Haefel.com/addr" >
  <name>AMAZON.COM</name>
  <street>1850 Mercer Drive</street>
  <city>Lexington</city>
  <state>KY</state>
  <zip>40511</zip>
</addr:address>

to be valid. Note the added xmlns="" which cancels the default namespace so there is no longer any doubt where the name, street, city, state, zip elements belong.
[ May 08, 2008: Message edited by: Peer Reynders ]

[Pedro Erencia]

quote:Could you please put an example of a name-collision that explains the statement i've quoted ?



* "unqualified locals" are permitted
* a default namespace has been declared {http://www.Monson-Haefel.com/jwsbook/PO}
* the parent element exists in a different namespace {http://www.Monson-Haefel.com/jwsbook/ADDR} from the default
* "zip" element under parent element doesn't use a prefix


so the "zip" element could either mean {http://www.Monson-Haefel.com/jwsbook/ADDR}zip (if it is an unqualified local) or {http://www.Monson-Haefel.com/jwsbook/PO}zip (if it belongs to the default namespace).

----


Maybe the key is in the last paragraph.

The zip element is clearly associated with the default namespace. If the schema determines that it must be unqualifed then the instance is invalid because the zip should be associated with no namespace.

If the schema claims that localy element zip must be qualifed, then the instance is again invalid, but in that case because it's associated with the default namespace, instead of the parents namespace.

There's no point to doubt that zip is in the default namespace, because it doesn't inherits address namespace.

<?xml version="1.0"?>
<addr:address xmlns:addr="http://www.Monson-Haefel.com/jwsbook/ADDR">
<name>AMAZON.COM</name>
</addr:address>

So if the schema says locally elements to be unqualified the instance will be valid.

It only would inherit the parents namespace in that case

<?xml version="1.0"?>
<address xmlns="http://www.Monson-Haefel.com/jwsbook/ADDR">
<name>AMAZON.COM</name>
</address>

In that case if schema says locally elements to be unqualified the instance will be invalid.

[ May 08, 2008: Message edited by: Pedro Erencia ]
[ May 08, 2008: Message edited by: Pedro Erencia ]

[Peer Reynders]

Originally posted by Pedro Erencia:
because street is out of any namespace scope.

I disagree. And here is why:


From the defining schema po1.xsd

<complexType name="USAddress">
  <sequence>
    <element name="name"   type="string"/>
    <element name="street" type="string"/>
    <!-- etc. -->
  </sequence>
</complexType>

"street" is part of {http://www.example.com/PO1}USAddress

<complexType name="PurchaseOrderType">
  <sequence>
    <element name="shipTo"    type="po:USAddress"/>
    <element name="billTo"    type="po:USAddress"/>
    <element ref="po:comment" minOccurs="0"/>
    <!-- etc. -->
  </sequence>
  <!-- etc. -->
</complexType>

{http://www.example.com/PO1}shipTo is of type {http://www.example.com/PO1}USAddress

The only top level elements are purchaseOrder and comment

<element name="purchaseOrder" type="po:PurchaseOrderType"/>
<element name="comment"       type="string"/>

therefore {http://www.example.com/PO1}street is a local in {http://www.example.com/PO1}.

{http://www.example.com/PO1}street is a local to {http://www.example.com/PO1}shipTo which is local to {http://www.example.com/PO1}purchaseOrder which establishes the scope of its own namespace for any elements local to it.

[Pedro Erencia]

I think we must concentrate on that your last post and prove it. I'll do some coding to try to find to which namespace is street associated.

[Peer Reynders]

Originally posted by Pedro Erencia:
If the schema determines that it must be unqualifed then the instance is invalid because the zip should be associated with no namespace.

Again I have to disagree. Plain XML by default uses "unqualified locals". The zip element is clearly not a top-level element, so it is a local - i.e. it can only belong to a parent element in the same namespace. With "unqualified locals" in effect, elements local to their parent elementaren't allowed to have a prefix. Which is why it makes sense that you have to cancel the default namespace in the parent scope because the local elements belong to the parent's namespace and aren't allowed to have a prefix - having a default namespace (or a "no namespace" default) would only create ambiguity.

[Pedro Erencia]

this is the xml(3.xml)

<?xml version="1.0" encoding="UTF-8"?>
<apo :p urchaseOrder xmlns:apo="http://www.example.com/PO1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.example.com/PO1 po1.xsd">
<shipTo>
<name>Alice Smith</name>
<street>123 Maple Street</street>
<!-- etc. -->
</shipTo>
<billTo>
<name>Robert Smith</name>
<street>8 Oak Avenue</street>
<!-- etc. -->
</billTo>
<apo:comment>Hurry, my lawn is going wild</apo:comment>
<!-- etc. -->
</apo :p urchaseOrder>

and this the xsd(po1.xsd)

<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns :p o="http://www.example.com/PO1"
        targetNamespace="http://www.example.com/PO1"
        elementFormDefault="unqualified">
        
 
  <element name="purchaseOrder" type="po :p urchaseOrderType"/>
  <element name="comment"       type="string"/>
 
  <complexType name="PurchaseOrderType">
    <sequence>
      <element name="shipTo"    type="po:USAddress"/>
      <element name="billTo"    type="po:USAddress"/>
      <element ref="po:comment" minOccurs="0"/>
    </sequence>
  </complexType>
 
  <complexType name="USAddress">
    <sequence>
      <element name="name"   type="string"/>
      <element name="street" type="string"/>
    </sequence>
  </complexType>
  </schema>
 

This is a piece of code to validate and show which uri is associated with each element:

 
package com.micasa;
 
import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;
 
import javax.xml.XMLConstants;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;
import javax.xml.transform.Source;
import javax.xml.transform.sax.SAXSource;
import javax.xml.validation.Schema;
import javax.xml.validation.SchemaFactory;
 
import org.xml.sax.Attributes;
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;
import org.xml.sax.SAXParseException;
import org.xml.sax.helpers.DefaultHandler;
 
public class SAX2Validator {
 
    static class Handler extends DefaultHandler {
 
        @Override
        public void error(SAXParseException e) throws SAXException {
            // TODO Auto-generated method stub
            super.error(e);
        }
 
        @Override
        public void startElement(String uri, String localName, String name, Attributes attributes)
                throws SAXException {
            // TODO Auto-generated method stub
            super.startElement(uri, localName, name, attributes);
            System.out.println(name + " ns = " + uri);
        }
        
 
    }
 
    public static void main(String[] args) throws FileNotFoundException {
 
                   try {
            SchemaFactory schemaFactory = SchemaFactory
                    .newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
            Schema newSchema = schemaFactory.newSchema(new Source[] {
//                    new SAXSource(new InputSource(new FileReader("schema3.xsd"))),
                    new SAXSource(new InputSource(new FileReader("po1.xsd"))) });
            newSchema.newValidator().validate(
                    new SAXSource(new InputSource(new FileReader("3.xml"))));
         
                 SAXParserFactory factory= SAXParserFactory.newInstance();
                 factory.setFeature("http://xml.org/sax/features/namespaces", true);
                 SAXParser newSAXParser = factory.newSAXParser();
                 System.out.println(newSAXParser.isNamespaceAware());
                 newSAXParser.parse(new File("3.xml"), new Handler());
                 
                } catch (SAXException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                } catch (IOException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                } catch (ParserConfigurationException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
 
    }
 
}

When i run the code the validation is correct and this is the output of uris to element mappings:

true
apo :p urchaseOrder ns = <a href="http://www.example.com/PO1" target="_blank" rel="nofollow">http://www.example.com/PO1</a>
shipTo ns = 
name ns = 
street ns = 
billTo ns = 
name ns = 
street ns = 
apo:comment ns = <a href="http://www.example.com/PO1" target="_blank" rel="nofollow">http://www.example.com/PO1</a>

If, as you say, shipTo and street belong to {http://www.example.com/PO1}USAddress} then the following will be a correct xml instance.

...
<apo:shipTo>
<name>Alice Smith</name>
<street>123 Maple Street</street>
<!-- etc. -->
</apo:shipTo>
...

This is the output when i run the program above again:

org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'apo:shipTo'. One of '{"":shipTo}' is expected.

So, according to the schema, shipTo belongs to no namespace at all. The same is true for street.

[ May 08, 2008: Message edited by: Pedro Erencia ]
[ May 08, 2008: Message edited by: Pedro Erencia ]

[Pedro Erencia]

because the local elements belong to the parent's namespace

With unqualifed locals, local element doesn't belong to any namespace at all.

http://www.oracle.com/technology/pub/articles/srivastava_namespaces.html

An unqualified setting means that only the globally declared elements must be explicitly qualified, and the locally declared elements must not be qualified.

[Peer Reynders]

Apparently you haven't come across the following:

Just because your compiler compiles your code doesn't imply that either your code is syntactically correct or that the output of the compiler is semantically correct with respect to the langauge specification.

So the output of that program doesn't prove anything.

Furthermore:

org.w3c.dom.Node.getNamespaceURI()

The namespace URI of this node, or null if it is unspecified. This is not a computed value that is the result of a namespace lookup based on an examination of the namespace declarations in scope. It is merely the namespace URI given at creation time.

So basically the entire JAXP library simply returns the registered namespace on the prefix if a prefix is present.
[ May 08, 2008: Message edited by: Peer Reynders ]

[Peer Reynders]

XML Schema: Understanding Namespaces

In contrast, when we choose unqualified, we are specifying that only the globally declared elements and attributes in the instance must have a namespace

That statement is plain wrong. It should have been:

In contrast, when we choose unqualified, we are specifying that only the globally declared elements and attributes in the instance must have a prefix

And even that is not entirely accurate because a prefix is not needed if the global element is in the current default namespace. The pertinent fact is that the local elements cannot have a prefix.


XML Schema Part 0: Primer Second Edition: 3.1 Target Namespaces and Unqualified Locals

Furthermore, elementFormDefault[="unqualified"] and attributeFormDefault[="unqualified"] require that the prefix is not applied to any of the locally declared elements such as shipTo, billTo, name and street, and it is not applied to any of the attributes (which were all declared locally).

[ May 08, 2008: Message edited by: Peer Reynders ]

[Peer Reynders]

Throw a "apo:" in front of the "street" in your sample XML. In my DOM version I get the following

org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'apo:street'. One of '{street}' is expected.

So basically it is telling me that I'm not allowed to used a prefix.
Not that error messages have ever been that correct or informative.

[Pedro Erencia]

Apparently you haven't come across the following:

quote:
Just because your compiler compiles your code doesn't mean that your code is syntactically correct with respect to the language specification, nor does it imply that the

output of the compiler is semantically correct with respect to the langauge specification.



So the output of that program doesn't prove anything.

So Xerces doesn't have any credit about the XML and Schemas spec.

It could be wrong, and don't follow the specs.

That code validates the instance against an schema, and i think it's pretty reasonably to assume it does it well as a reference implementation in jwsdp2.0. And that schema says

that the shipTo element is expected to not belong to any namespace.
If you have some other and better form to prove that the shipTo element is intended to be in the {http://www.example.com/PO1} namespace on an xml instance according to that schema

- the specs i.e - i'd be glad to know.

Furthermore:

org.w3c.dom.Node.getNamespaceURI()

quote:The namespace URI of this node, or null if it is unspecified. This is not a computed value that is the result of a namespace lookup based on an examination of the

namespace declarations in scope. It is merely the namespace URI given at creation time.

Assuming the context of the schema and the xml i've provided, i'd like to know what other result could be.

Moreover,

if we do,

 
<shipTo xmlns="http://www.example.com/PO1">
<name>Alice Smith</name>
<street>123 Maple Street</street>
<!-- etc. -->
</shipTo>

The result is:

 
shipTo ns = <a href="http://www.example.com/PO1" target="_blank" rel="nofollow">http://www.example.com/PO1</a>
name ns = <a href="http://www.example.com/PO1" target="_blank" rel="nofollow">http://www.example.com/PO1</a>
street ns = <a href="http://www.example.com/PO1" target="_blank" rel="nofollow">http://www.example.com/PO1</a>
 

No prefixs were present in name or street. They were qualified without prefix, and the code detects it.

Furthermore, elementFormDefault[="unqualified"] and attributeFormDefault[="unqualified"] require that the prefix is not applied to any of the locally declared elements such as

shipTo, billTo, name and street, and it is not applied to any of the attributes (which were all declared locally).

That quote says nothing about namespaces. You can't figure out that it is wrong only by the statement you quote.

The first says locally element cannot have namespaces. The quote, that locally elements cannot be prefixed. It doesn't imply that they can have namespaces.

Where did you find the statements that made you think that shipTo is expected to be in the http://www.example.com/PO1
in a valid instance ?

I'm going to check the spec now.. at least we have reduced the question to a very simple question..

[Pedro Erencia]

Throw a "apo:" in front of the "street" in your sample XML. In my DOM version I get the following

code:


org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'apo:street'. One of '{street}' is expected.



So basically it is telling me that I'm not allowed to used a prefix.
Not that error messages have ever been that correct or informative.

Qualify it whithout a prefix

<street xmlns="http://www.example.com/PO1">123 Maple Street</street>

It will insist in the same error.

So it's no the prefix which turns the error on. So i think it's reasonably to think that when it says

org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'street'. One of '{"":street}' is expected.

it's saying that it expects a non qualified conformance. An street element which doesn't have any namespace associated - is not qualified = unqualified -.
[ May 08, 2008: Message edited by: Pedro Erencia ]

[Naren Chivukula]

I agree with Peer. Just paraphrasing what Peer has said many times above.

Consider the following example

<addr:address xmlns:addr="http://www.Monson-Haefel.com/jwsbook" xmlns="http://www.Monson-Haefel.com/po">
....
<city>New York</city>
....
</addr:address>

If the supporting schema(not declared for simplicity) for the above XML says elementFormDefault="qualified", then the above XML instance is CORRECT because
-> The local element <city> is qualified because it comes under default namespace xmlns="http://www.Monson-Haefel.com/po"

If the supporting schema(not declared for simplicity) for the above XML says elementFormDefault="unqualified", then the above XML instance is INCORRECT because
-> The local element <city> has two conflicting namespaces
1. Default Namespace xmlns="http://www.Monson-Haefel.com/po"
2. Explicitly declared one xmlns:addr="http://www.Monson-Haefel.com/jwsbook" because child inherits from the parent.

Correct me Peer if I'm wrong.

[Pedro Erencia]

Namespaces in XML 1.0

We can infer from that that a child of an element with a namespace declaration declaring a prefix doesn't inherits that namespace if it is not prefixed. ( the shipTo case ).

[Pedro Erencia]

Hi Naren,

2. Explicitly declared one xmlns:addr="http://www.Monson-Haefel.com/jwsbook" because child inherits from the parent.

In the post above i refer to the spec piece which makes me thing that statement is wrong - not mentioning the programs result -.


I'd say
...
If the supporting schema(not declared for simplicity) for the above XML says elementFormDefault="unqualified", then the above XML instance is INCORRECT because
-> The local element <city> is qualified with default Namespace xmlns="http://www.Monson-Haefel.com/po".
[ May 08, 2008: Message edited by: Pedro Erencia ]

[Naren Chivukula]

Hi Pedro, I've just gone through the W3C spec and found this.

If there is a default namespace declaration in scope, the expanded name corresponding to an unprefixed element name has the URI of the default namespace as its namespace name. If there is no default namespace declaration in scope, the namespace name has no value. The namespace name for an unprefixed attribute name always has no value. In all cases, the local name is local part (which is of course the same as the unprefixed name itself).

It seems that I'm wrong. Thanks for pointing out that. But still wondering where Peer's analysis have gone away from your's!

Thanks and Regards,
Naren

[Peer Reynders]

Originally posted by Pedro Erencia:
That code validates the instance against an schema

I'm not arguing that the instance is invalid with reference to the schema. I'm arguing that the tools are purely prefix driven, not namespace driven. They know that "unqualifed locals" are the default and that the "local" shipTo isn't allowed to have a prefix - that is enough to satisfy the validation. Namespace analysis would be too complex and slow. So what I am arguing is that the parsers/validators don't have any idea what namespace the element belongs to if there is no prefix and therefore cannot be relied upon to tell you which namespace an element belongs to.

And that schema says that the shipTo element is expected to not belong to any namespace.

This is where I disagree. By virtue of the schema "targetNamespace" declaration shipTo should be part of {http://www.example.com/PO1}.

No prefixs were present in name or street. They were qualified without prefix, and the code detects it.

OK, I agree that you have shown that the parser/validator does keep track of the default namespace and can use it when there is no prefix.

That quote says nothing about namespaces.

Exactly! It's about prefixes! Not namespaces - an element doesn't have to have a prefix to belong to a namespace! An element that shows a prefix is part of a namespace - an element without a prefix can still belong to a namespace. So (namespace != prefix).

Where did you find the statements that made you think that shipTo is expected to be in the {http://www.example.com/PO1} in a valid instance?

By virtue of the "targetNamespace" declaration of the schema which the identifies the namespace that everything is "created into".


If you are right, how do you prevent naming collisions between locals? The only possible way that I can see how to resolve that is by saying that locals belong to the enclosing element rather than any namespace that the global at the top may reside in i.e.

{http://tempuri.org}global/local is different from {http://tempuri2.org}global/local

Furthermore you would be saying that by switching from elementFormDefault="unqualified" to elementFormDefault="qualified" you are actually changing the nature of local elements rather than simply their representation because you are stating that for "unqualified" they do not belong to the targetNamespace while for "qualified" they do belong to the targetNamespace - that I have a problem with.

[Peer Reynders]

Originally posted by Pedro Erencia:

Qualify it without a prefix
...

It will insist in the same error.

That simply tells me that the parser/validator is placing the default namespace as an "implicit prefix". This underlines the necessity to cancel the default namespace when your enter an element with "unqualified locals".

Invalid content was found starting with element 'street'

Note that it doesn't mention any namespace name even though the default namespace implies {http://www.example.com/PO1}street.

One of '{"":street}' is expected.

Note that the colon separates the prefix (not the namespace) and the local name. So it's asking for an empty prefix. Which further makes me suspect that it interprets the presence of the default namespace as an implicit prefix.

[Peer Reynders]

Originally posted by Naren Chivukula:
If the supporting schema(not declared for simplicity) for the above XML says elementFormDefault="unqualified", then the above XML instance is INCORRECT because

So far the evidence suggests that you are not allowed to have an active default namespace within an element with "unqualified locals" - period. The default namespace must be canceled by the global element that contains "unqualified locals". Therefore a default namespace cannot exist within the confines of a global element that has "unqualified locals".

[Naren Chivukula]

Hi Peer,
I'm not quite understood by what you meant. Can you please a bit more clearer on this below? thanks.

Originally posted by Peer: So far the evidence suggests that you are not allowed to have an active default namespace within an element with "unqualified locals" - period. The default namespace must be canceled by the global element that contains "unqualified locals". Therefore a default namespace cannot exist within the confines of a global element that has "unqualified locals".

Kind Regards,
Naren
[ May 09, 2008: Message edited by: Naren Chivukula ]

[Pedro Erencia]

Namespace analysis would be too complex and slow

So Xerces is not namespace aware. It doesn't understands namespaces when validating.

This is where I disagree. By virtue of the schema "targetNamespace" declaration shipTo should be part of {http://www.example.com/PO1}.

http://www.w3.org/TR/xmlschema-1/#cElement_Declarations
3.3.2 XML Representation of Element Declaration Schema Components

If form is present and its �actual value� is qualified, or if form is absent and the �actual value� of elementFormDefault on the <schema> ancestor is qualified, then the �actual value� of the targetNamespace [attribute] of the parent <schema> element information item, or �absent� if there is none, otherwise �absent�.

[ May 09, 2008: Message edited by: Pedro Erencia ]

[Peer Reynders]

OK, I've done some more research and it seems that XML Namespaces are not like traditional Namespaces (e.g. Namespace Myths Exploded). It seems that by default only global elements, attributes and types are associated with the targetNamespace - local ones aren't.

Pedro your last quote from 3.3.2 XML Representation of Element Declaration Schema Components points out the fact that I found the most unsettling: the setting of the form attributes changes the universal names of locals (universal names: see James Clark: XML Namespaces)! So "unqualified" results in "street" as the universal name and "qualified" results in "{http://www.example.com/PO1}street" as the universal name. There it is. You are right.

So it seems:

A prefixed element is associated with the namespace assigned to that prefix.

An unprefixed element is associated with the default namespace if one has been declared.

An unprefixed element is not associated with the any namespace if no default namespace has been declared.

For now, until I can find evidence to the contrary, I'm going to assume that both a prefixed element and an unprefixed element inside a default namespace classify as "namespace qualified".

So back to CASE III.
Pedro was correct in stating that name, street, city, state, and zip are associated with {http://www.Monson-Haefel.com/jwsbook/PO}.
If you map the tags to universal names it would look like this:

<{http://www.Monson-Haefel.com/jwsbook/ADDR}address>
  <{http://www.Monson-Haefel.com/jwsbook/PO}name>AMAZON.COM</{http://www.Monson-Haefel.com/jwsbook/PO}name>
  <{http://www.Monson-Haefel.com/jwsbook/PO}street>1850 Mercer Drive</{http://www.Monson-Haefel.com/jwsbook/PO}street>
  <{http://www.Monson-Haefel.com/jwsbook/PO}city>Lexington</{http://www.Monson-Haefel.com/jwsbook/PO}city>
  <{http://www.Monson-Haefel.com/jwsbook/PO}state>KY</{http://www.Monson-Haefel.com/jwsbook/PO}state>
  <{http://www.Monson-Haefel.com/jwsbook/PO}zip>40511</{http://www.Monson-Haefel.com/jwsbook/PO}zip>
</{http://www.Monson-Haefel.com/jwsbook/ADDR}address>

That is it, as far as namespaces go.


However SOAP web services deal with XML Schema to help define the structure of the documents. So if somebody tells you that the XML is valid with respect to the relevant schemas you know that name, street, city, state, and zip have to be global elements in their schema. While this is a possible way to design the address structure it is actually more likely that the entire address complex type is defined in one single schema, i.e.:

<address xmlns="http://www.Monson-Haefel.com/jwsbook/ADDR">
  <name>AMAZON.COM</name>
  <street>1850 Mercer Drive</street>
  <city>Lexington</city>
  <state>KY</state>
  <zip>40511</zip>
</address>

which clearly maps to

(Version Q):

<{http://www.Monson-Haefel.com/jwsbook/ADDR}address>
  <{http://www.Monson-Haefel.com/jwsbook/ADDR}name>AMAZON.COM</{http://www.Monson-Haefel.com/jwsbook/ADDR}name>
  <{http://www.Monson-Haefel.com/jwsbook/ADDR}street>1850 Mercer Drive</{http://www.Monson-Haefel.com/jwsbook/ADDR}street>
  <{http://www.Monson-Haefel.com/jwsbook/ADDR}city>Lexington</{http://www.Monson-Haefel.com/jwsbook/ADDR}city>
  <{http://www.Monson-Haefel.com/jwsbook/ADDR}state>KY</{http://www.Monson-Haefel.com/jwsbook/ADDR}state>
  <{http://www.Monson-Haefel.com/jwsbook/ADDR}zip>40511</{http://www.Monson-Haefel.com/jwsbook/ADDR}zip>
</{http://www.Monson-Haefel.com/jwsbook/ADDR}address>

Now from a schema design perspective you have a choice to make. Do you make name, street, city, state, and zip global or local? Making them global is no different from before. However if you want to make them local AND you want the above universal names then you will have to set form or elementFormDefault to "qualified". If you do not, the schema will default to "unqualified" which actually maps to this:

(Version U):

<{http://www.Monson-Haefel.com/jwsbook/ADDR}address>
  <name>AMAZON.COM</name>
  <street>1850 Mercer Drive</street>
  <city>Lexington</city>
  <state>KY</state>
  <zip>40511</zip>
</{http://www.Monson-Haefel.com/jwsbook/ADDR}address>

which is clearly different from the former (Version Q). Furthermore with (Version U) you can no longer use a default namespace, as the default namespace would force itself onto the unprefixed elements - making them invalid. So (Version U) would appear in the instance document something like this:

<addr:address xmlns="" xmlns:addr="http://www.Monson-Haefel.com/jwsbook/ADDR">
  <name>AMAZON.COM</name>
  <street>1850 Mercer Drive</street>
  <city>Lexington</city>
  <state>KY</state>
  <zip>40511</zip>
</addr:address>

(Note the resemblance to CASE III)
Note that you have to cancel any default namespace with xmlns="" in this case to ensure that the default namespace does not have any effect on the unprefixed local elements.


Now in reference to The WS-I BP

Basic Profile 1.0 - 4.1.13

4.1.13 SOAP Body and Namespaces
The use of unqualified element names may cause naming conflicts, therefore qualified names must be used for the children of soap:Body.

R1014 The children of the soap:Body element in a MESSAGE MUST be namespace qualified.

I'm going to assume that an unprefixed element name is permissible as long as there is a default namespace which "qualifies" it. Whether this affects "unqualified locals" seems unclear as you can't place a local directly under soap:Body. (It says "for the children" not "as a direct child").
[ May 09, 2008: Message edited by: Peer Reynders ]

[amit sharma]

Thanks Peer for so much effort in explaining
[ May 09, 2008: Message edited by: amit rossi ]