XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
schema validation in view of references to fragments

Hello,

 

I have an XML Schema that describes a vocabulary used in a WSDL and the resulting SOAP traffic. In some cases the SOAP traffic generated keeps the original structure as described in the XML Schema. On some other cases the traffic uses notation described in sections such as in http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383519:

 

That is, there is a usage of the href="”#someid” notation.

My question is with regards to the referenced fragment.

While the ad-hoc element that will have an id=”someid” is expected to be in the same namespace as the element in the original location of the document, I see that its child elements appear in such traffic as unqualified elements (or is it that they are qualified by some how are implicitly get a default namespace as the same namespace as their parent ad-hoc element?!).

 

What’s the proper interpretation in such cases?

 

Let’s look at an example: There’s an XML Schema document with a target namespace and a value “qualified” for an elementFormDefault. The element “Book” is a top level element in this XML Schema document.

 

<xsd:element name="Book">
<xsd:complexType>

<xsd:sequence>

  <xsd:element name="title" type="xsd:string"/>

 <xsd:choice>

  <xsd:element name="author" type="xsd:string"/>
  <xsd:element name="preface" type="xsd:string"/>
   <xsd:element name="intro" type="xsd:string"/>

 </xsd:choice>

</xsd:sequence>
</xsd:complexType>
</xsd:element>

 

Say that the elementFormDefault is set to “qualified” in the XML Schema document where the element “Book” is defined. The XML Schema document also has a targetNamespace. As a result, I expect that the child elements of “Book” be qualified and belong to the same namespace as the target namespace. For example, case onethis is how the problematic traffic looks like:

 

<e:Book>
   <e:title>The book Title</e:title>
   <adhocElt href=""#details"/> </e:Book>

 

<!--

      a lot later in the message…

-->


<e:referencedElt id="details">
   <name>Foo Bar</name> <!-- no default namespace -->
</e:referencedElt>

 

Or alternatively as case two – this is how I expected the traffic to look like:

 

<e:Book>
   <e:title>The book Title</e:title>
   <e:name>Foo Bar</e:name>
</e:Book>

 

But if not, then the following is what I’d expect to see  when such href references exist (case three):

<!--

      In the root element there’s a namespace binding

Definition:

 

xmlns:e=”someNamespaceURL”

-->

 

<e:Book>
   <e:title>The book Title</e:title>
   <adhocElt href=""#details"/> </e:Book>

 

<!--

      a lot later in the message…

-->


<e:referencedElt id="details">
   <e:name>Foo Bar</e:name>
</e:referencedElt>

 

Or perhaps something like this (case four):

<!--

      In the root element there’s a namespace binding

Definition:

 

xmlns:e=”someNamespaceURL”

-->

<e:Book>
   <e:title>The book Title</e:title>
   <adhocElt href=""#details"/> </e:Book>

 

<!--

      a lot later in the message…

-->


<e:referencedElt id="details" xmlns=”someNamespaceURL”>
   <name>Foo Bar</name>
</e:referencedElt>

 

 

I expected to see case two but the traffic looks like case one. What’s the explanation? Is this behavior described somewhere in the SOAP specs?  What would be the proper interpretation in order to properly validate such fragments with references against the XML Schema document?

 

What if the elementFormDefault is not even explicitly defined in the XML Schema Document? What would be the expected interpretation then?

 

Thanks.

 

Shlomo



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS