My blog has moved and can now be found at http://blog.aniljohn.com

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Monday, September 17, 2007
« Demystifying SCA | Main | Enterprise Security and Responsibility »

When designing schemas, one tries to strive for modularity which allows one to build XML schemas that are composed of other schema documents. The keywords that make it possible are include, import and redefine.  Most folks who are used to schemas are familiar with import and if you want to maximize interoperability you should stay away from redefine since it is not implemented on a consistent basis.

That leaves the include keyword.  When you use include, one of the following should be true:

  • Both schema documents (The including schema and the included schema) must have the same target namespace
  • Neither of the schema documents should have a target namespace
  • The including schema document has a target namespace, and the included schema does not.

In the last case, all components of the included schema document take on the namespace of the including schema document. The included schema document is sometimes referred to as a chameleon schema as its namespace changes depending on where it is included.

A best practice that I normally follow is to use chameleon schemas for common, reusable types so that I don't have to namespace qualify some very common schema types that I normally end up using across multiple schemas. 

I recently ran into an issue when actually working on this in that a particular .NET tool that I was using did not seem understand the use of option (3) i.e. chameleon schemas. Since I know the guys who developed the tool, and they are considered pretty much experts in the field, I was not that surprised when I pinged them on this and got back an answer that it was a known issue.

According to them, the reason that the issue exists is because of a lack of support in the .NET API itself and (this is way too low level for me) has to do with how the ServiceDescriptionImporter(SDI) class is not working properly. So you would have issues if you tried to use wsdl.exe with chameleon schemas in .NET 1.1 and 2.0. Not sure if the issue exists under WCF.

The workaround for this, which I implemented, was to qualify the included schema with the same namespace as the including schema. Not ideal, but got me to where I needed to.

Hopefully this is an issue that will be fixed.

9/17/2007 12:07 PM Eastern Daylight Time  |  Comments [2]  |  Disclaimer  |  Permalink   
Wednesday, September 19, 2007 10:17:41 PM (Eastern Daylight Time, UTC-04:00)
Hi. I have recently started reading about Web Services under SOAP architecture. I find that your blog and discussions are mainly on Windows platform. Is this a conscious choice; meaning, a choice where you have found that Windows is a better platform than -nix platforms.

I was also wondering if there is some good guide you can refer me to, where Apache WS projects have been explained in terms of development. Good blog though.
Thursday, September 20, 2007 8:35:42 PM (Eastern Daylight Time, UTC-04:00)
My focus with web services is on interoperability and I tend to work with web services on both the .NET and Java platforms. Although I can get around in linux, my typical deployment OS is Windows 2003 as I am lot more comfortable in administering that configuration than a linux box. I do not consider one better than the other in terms of web services support. From my perspective, if there can be said to be "reference implementations" of the WS-* specs, I would point to both Microsoft .NET WCF and Apache Axis2 as prime candidates for that designation.

For information on Apache WS projects, check out http://ws.apache.org/axis2/ and http://wso2.org/ as good starting points for web service development information on the Java platform using Apache Axis2 as the SOAP stack.
Anil John
Comments are closed.