Introduction
This weblog is about XML processing in ABAP. In the first part of this we weblog discussed the expressiveness of Simple Transformations, the second part was about conditions. The focus of this issue is on namespaces in Simple Transformations (in short ST).
Namespaces in Simple Transformations
XML namespaces are a convention for using attributes to associate URIs (Universal Resource Identifiers) with some element and attribute names (later on I will drop some comments to URIs). Every ST program uses a namespace to distinguish ST commands from literal text, which is used for serialization resp. deserialization. The start of a Simple Transformation consists of such a namespace declaration:
The use of URIs is a little bit confusing. An URI is either an URL (Universal Resource Locator) or an URN (Universal Resource Name). There are different URI schemes, think of "http://www.sap.com/transformation-templates" for example. When dealing with namespaces just think of it as a special string but don't assume you can fetch resources using URIs.
But back to namespaces: lots of people think that they are more complicated than they ought to be. Most annoying is that there are different terms for the same thing in different specifications of XML family: 'qualified names', 'expanded names', 'namespace-style names' and so on. I hope I won't make the same mistake...
In the last issue of my weblog I discussed applications of the tt:cond statement which is an example for an explicit namespace tt of an element: .
Of course there are more applications of namespaces in data exchange: generic XML interfaces can include different vocabularies (just think of type libraries for example) or can be build up using standardized schemas that are defined using their own namespaces.
Namespaces can be written explicitly as a prefix to an element or attribute like above as well as they can be declared as default for an element and its children. Both possibilities are equivalent but the use of prefixes allows to mix up different vocabularies; Simple Transformations considered as XML documents are a typical example.
Namespaces during deserialization
In the following example, the namespace of element <X> and its children is declared without prefix:
To transform this XML document we use the following ST code:
Let's remark that the declaration of the namespace using the attribute xmlns:xyz="urn:001" is necessary to deserialize the XML document above.
We can use the same transformation for this equivalent XML document with qualified elements (explicit namespace declaration using a prefix):
Of course we can redefine the prefix in the XML document above to for example, as long as the namespace prefix 'new' refers to the URI "urn:001" that is declared in the ST code.
Both XML documents above can be deserialized with following transformation, too, that doesn't contain an namespace prefix (besides 'tt="http://www.sap.com/transformation-templates"'):
This means that we only have to take care about correct namespaces in our ST programs, but not how they are declared.
Namespaces during serialization
At first I want to present the output of the two transformations above used to serialize a string 'text1'.
Without an explicit prefix the ST processor will omit namespace declaration whenever it is possible. If you serialize the string `text1` using following transformation you will get the XML document listed after the transformation. The attribute 'xmlns:test="urn:002"' is left out:
In fact ST adds the attribute 'xmlns:prefix="..."' everytime a qualified element or attribute occurs. We can test it with following transformation. Just remark that xmlns:xyz="urn:001" is added in the resulting XML document (again following the transformation) although it is missing in the element <xyz:X> of the ST code:
tt:namespace command
The tt:namespace command allows you to insert namespace declarations with prefixes. Again I present the ST code and the resulting XML document after serialization of the string 'text1':
But what is it good for? Let's modify our example slightly and introduce another element to be transformed and look at the result:
If we insert the tt:namespace command the result will be different:
If we define the namespace using the tt:namespace command in the context of the <X> element this namespace won't be inserted in each of the child elements that belong to that namespace. As a consequence your serialized XML document will be shorter and more readable.
Summary
I gave a short introduction into namespaces and showed the flexibility of Simple Transformations: during deserialization the namespace of your elements and attributes must match with the namespace declared in your transformation but it's not important how it is defined within the XML document. During serializiation the tt:namespace command can help you to generate shorter and more readable documents.
