JeeWiz Architect's Guide - Work With Namespaces In XML Specifications


	The Model-Driven System Builder

JeeWiz Architect's Guide

Contents > 11. How To

11.9 Work With Namespaces In XML Specifications

Some XML documents can use namespace qualifiers, so you may want to use such documents as JeeWiz specifications. When using namespaces, XML elements, attributes and values can have a namespace qualifier - e.g.

	<xsd:schema xsi:type="xsd:string">

This is a meaningless example just to show that the namespace can appear in all places.

JeeWiz does not need to use namespaces, because it uses meta-models to group related concepts, and uses context-sensitive 'adders' to tell what sort of model object should be created. Therefore, namespaces are not generated by

the JeeWiz XML editor
transforming from UML.

This means that this section only applies when using XML documents created elsewhere as a JeeWiz specification.

Element Type Disambiguation

XML namespaces allow disambiguation of element types between different schemas.

In JeeWiz metamodels, you can do roughly the same thing in terms of disambiguation: you can say "java:type" to target the Java metamodel, and distinguish the Java "type" from the type in the current metamodel. JeeWiz therefore does not need namespaces to disambiguate model (not meta-model) objects with the same element name, because the meta-model (schema) is specified in the meta-model.

The only place where this falls down is that we cannot define multiple types of nested elements of the same unqualified name. For example, XML Schema can say <x> <schema1:y> <schema2:y> </x> and know that the first 'y' and second 'y' elements are different. You can't do this distinguishing in JeeWiz. In practice, we haven't come across this yet.

Finding the class

XML elements are mapped to Java objects. The class types of the Java objects for nested elements are defined by the meta-model, using the unqualified element name.

Note the unqualified name is used and the namespace is ignored. In the example above, JeeWiz throws away 'schema1/2:' and just uses '<y>'.

The actual class chosen is defined by the metamodel, and this may reference different metamodels. In the example about type, a list of 'java:type' and 'type' will yield different types of objects, but the element name for both will be 'type'. Furthermore, lists can have different names from the type generated, which gives a way of disambiguating in the meta-model. This means, for example, that a <java-type> nested element could be defined to produce a 'java:type' model object, and a <type> nested element to produce a 'type' model object.
br> The only place where we look up the name 'bare' is the root element. The model object for the root element is looked up based on its name and the order of the meta-models. The top meta-model will take precedence, and this gives a deterministic way of fixing the class of the root element. This means that we can ignore the XML namespace qualifier and still disambiguate - but in this case, this is done by the order of the meta-models. This 'top-most' meta-model with the right Java class (e.g. for 'application' in a J2EE system) will govern the type of model object generated at the root. This indirectly determines all the other meta-classes used to create model objects created during the XML-to-Java-object transformation.

Finding rendering files

For now, the rendering files - pattern and templates - will be looked up in directories based on the unqualified element name ('schema' rather than 'xsd:schema'). In other words, we are ignoring the namespace again.

In a future version, we may offer a configuration-time option to base the name for the lookup directory on some additional discriminator defined in the meta-model. For example, this could be 'xsd/' for XML schema, which would introduce an extra directory. This would mean that where the rendering files would normally be searched for in control/schema directories, say, this feature would redirect the lookup to control/xsd/schema directories for the XSD schema element).

Note that the lookup will be independent of the actual namespace used in the document, which can be anything. Any correspondence between the namespace qualifier in the XML and the discriminator defined in the meta-model will be purely coincidental.

Namespaces in attributes

The only common place where namespaces are used in attributes is using xmlns: to qualify the namespace name. Currently JeeWiz ignores the namespace in attributes. Eventually we may need to discriminate.

Namespaces in values

We won't do anything about these. The interpretation of a value is up to the schema-based processing rather than JeeWiz. If the eventual processiing knows that a particular value is going to have a namespace, it should handle it.