Mark Wilson I am the creator of TopXML. I am available for international and local (Australia) contracts. I am a Solution Architect/Business Analyst. I have worked in IT in several countries (NZ, Australia, South Africa, UK) building and training teams for government and very large non-governmental organizations. I am ex-Microsoft Consulting Services. I wrote the first book on Microsoft XML published in 2000 called XML Programming with VB and ASP. Most recently I have been building tools for the SEO industry. Ask me for a 37 point SEO health-checkup for your website.
First posted :
03/24/2008
Times viewed :
845
any and anyAttribute
So far we always maintained a close relationship between a .NET
class and an XML schema type. However, in many cases XML schema types feature
some room for extensibility or customization. Take the types in the SOAP
protocol for message exchange between applications for example. The SOAP XML
format defines types as structured containers to transmit application specific information,
like in the following outline:
<Envelope>
<Header>
<!-- application
specific headers go here -->
</Header>
<Body>
<!-- application
specific message content goes here -->
</Body>
</Envelope>
The XmlSerializer also enables us to design classes for these
container types as well. With these classes we can modes of the structure of
the types and provide room for application specific content without having to
write custom classes for each XML message.
Since most of the content of a SOAP message is application
specific, the SOAP schema has to describe the overall structure of the message
without restricting the content of the Header or Body elements. For cases like
this, the XML schema standard defines the <any /> content model for arbitrary
XML content and the <anyAttribute /> item to allow extensible document
definitions for cases like this. A simplified version of the Envelope and the
Body definitions in the SOAP schema looks like this:
8
Listing 10.4: Two
extensible XML types (adapted from the SOAP protocol)
<xs:element name="Envelope"
type="Envelope_T" />
<xs:complexType name="Envelope_T" >
<xs:sequence>
<xs:element
ref="Header" minOccurs="0" />
<xs:element
ref="Body" minOccurs="1" />
<xs:any
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
<xs:anyAttribute
/>
</xs:complexType>
<xs:element name="Body" type="Body_T"
/>
<xs:complexType name="Body_T" >
<xs:sequence>
<xs:any
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
<xs:anyAttribute
/>
</xs:complexType>
This concept of open extensibility does not map well to what we
have learned so far about mapping .NET classes to XML types with the
XmlSerializer. We always required a one-to-one mapping between an XML element
or attribute and a field in a .NET class. What we have yet to learn is how we
can design classes to access XML content that was not explicitly defined in an
XML schema.
