Schema Namespaces


With WebLogic Server 10.3, there have been some changes in deployment descriptor schemas. This post discusses some of the issues that we faced in maintaining multiple loosely related XML schemas and how we tackled them. Note that none of these changes require changes to deployment descriptors. As always, old applications would continue to deploy and run without any change.

Old Namespace
We started off with a shared & stable set of schema in 9.0, all of which shared a common namespace URI: Since then we haven’t made any incompatible changes to the schemas, and making any such change seems unlikely. However, the schemas do change across major releases, minor releases and even in maintenance packs. Such changes are almost always independent of each other, that is, it’s highly likely that only one of the schema document changes.

The main problem with was that it included version information. When schema changes were made for a minor release or for a maintenance pack, we had to update the namespace for that schema. This was usability issue. In such a release, when an application developer wrote new descriptors, she had to deal with similar looking but different namespaces.

We could come up with a solution to schema versioning without changing the namespace within a major release, but we would still have to change the namespace once the schema changes happen for the next major release. This was a tooling issue. An application developer who performed pre-validation on her descriptors would have to change her descriptor to use the new namespace. This was also a maintenance issue for us. Each time we changed the namespace, we had to change our internal components that took care of backward compatibility.

The old convention also forced the same namespace on all the schemas. This contributed to the usability issue mentioned in the previous section. Also, it added to maintenance by forcing us to move the unchanged schemas to a new a namespace, every major release. This model did not fit well with modularity either. As teams owning the schemas spread out, we would need extra communication and co-ordination to avoid type name collisions for new types being added.

New namespaces
With WebLogic Server 10.3, all schemas now declare their own namespaces, none of which have any version in namespace URI. The general pattern of new namespace URIs is For example, the namespace URI for weblogic.xml is

This change addresses the two major problems and lays out a road map for schema versioning in the future. This will help the schemas evolve independently. Representing an entire namespace in one schema also provides a cleaner extensibility model for our application developers and ISVs.

In general, namespace URI wouldn't be changed even across major releases, unless drastic changes occur and we are forced to introduce incompatible changes. Again note that even if drastic changes to schema force us to change the namespace URI, old applications would continue to work without any change.

For documentation and referencing, we do need to capture the version information of the schema, inside the schema. This is done using the “version” attribute of element at the top of each schema:

<xsd:schema ..

We also introduced “version” attribute at the root element of each descriptor. This is somewhat similar to the version attribute for each of the Java EE descriptors. The Java EE descriptors version attribute is required and is an enumeration of supported versions. But we are not strict about this because our parsing infrastructure does a good job of in-memory conversion of document into the latest schema structure. Also, our schemas are revised more often than those of Java EE. So introducing an enumeration of possible values would be cumbersome to maintain in the future. Hence, our version attribute is optional and and of string type. Containers might use this value in the future. Here is how this would look in a descriptor:

<weblogic-web-app version=”1.0”>

Schema Locations
Each version of every schema is published on the web for reference. The same location may also be used for schema validation in case an XML parser or editor honors schemaLocation attribute. To get the URL for a given version of any schema use the namespace URI as a URL and visit this URL using your browser. An index of various versions for that schema would show up. Each of these entries links to the published schema for that version. For example, if you visit you would find link to version 1.0 of this schema pointing to

In due course, the schemas would be migrated from BEA domain to Oracle domain. The namespace URIs themselves might be changed too, for branding and consistency purposes. But the pattern of namespace URIs would continue to be the same. Whenever these changes happen, they'll be duly documented.

(Picture licensed from Brian Marco under Creative Commons)


Post a Comment:
  • HTML Syntax: NOT allowed

Posts about application development


« June 2016