Online documentation - Websydian v6.5 |
This is the third document in the introduction to TransacXML.
This document describes the basic rules of how to model an XML document in TransacXML.
You need to model the XML document to be able to process or create the XML documents.
The following section describes the rules you need to know to be able to model an XML document in TransacXML.
The first two parts: "Object types and inheritance" and Complex element content" are the most important.
The "Namespaces" section is relevant for all documents that use namespaces. As this is a very common occurrence, this part is also recommended reading.
The rest of the modeling rules descriptions describe how to model special cases. You should have a look at them so that you know that there are solutions for these cases if you encounter them - but you do not need to go into details with them.
This describes how XML objects are mapped to objects in the Plex model. All the referenced objects are found in the WSYXML model.
The distinguishing property of complex elements is that they can contain structures. The complex element can contain other complex elements, simple elements, and attributes.
The content of the complex elements are modeled as follows:
Namespaces are found in many real-life XML documents. TransacXML offers a way to assign namespaces to each of the object types.
In both cases, the object that inherits from NamespaceAware will get two new scoped source codes called Namespace and Prefix. By specifying values for the literals of these objects you can specify the namespace of the object and the prefix to use when creating the object in an XML document.
In some cases, you can find complex elements that have text content in addition to the simple elements and attributes.
This construct is not very common in real-life documents.
For example:
In this document, the complex element MyElement contains two simple elements SubElement1 and SubElement2.
In addition to this, it contains text content (abcd).
In some cases, a complex element has more than one simple child element with a specific name.
This construct is not very common in real-life documents.
For example:
In this case, the complex element "Comments" contains a number of simple child elements named "Comment".
This is modeled by letting the field Comment inherit from WSYXML/RepeatingElementField.
The default behavior of TransacXML is to insert the simple elements first, followed by the complex elements - as for example:
In many cases this is no problem, but if other parties have described the format, the following cases is possible:
Here, the complex element "complex" is places between the two simple elements. This means that you will have to be able to specify the position of the complex element in relation to the simple elements.
This is done by using a "ComplexElement" field. A field that inherits from ComplexElement is a placeholder that is only used to specify the position of the corresponding complex element (XMLElement) in relation to the simple elements.
The definitions for the above example would be (only the definitions relevant for the top element is shown):
Source Object | Verb | Target Object |
---|---|---|
top | is a ENT | XmlElement |
complex | is a ENT | XmlElement |
top.Fields | field FLD | simple1 |
top.Fields | field FLD | simple2 |
top.Fields | field FLD | complex |
top.Fields.simple1 | is a FLD | ElementField |
top.Fields.simple2 | is a FLD | ElementField |
top.Fields.complex | is a FLD | ComplexElement |
top | has FLD | simple1 |
top | has FLD | complex |
top | has FLD | simple2 |
Note that it is the sequence of the "has" triples that specifies the order of the elements. The relation between the ComplexElement field and the XMLElement is that the name is the same.
This is only relevant when creating documents. TransacXML does not use the specified order when reading documents.
This will show how you manually can model an XML document in Plex using the rules described above.
Not all of the rules will be shown in the example; only the most common constructs will be shown.
If you are implementing a web service client and the publisher of the service can provide a wsdl-file describing the service, you can also use the import tool to auto-generate the definitions.
The following example will show how to model the document introduced in the document explaining the structure of XML documents. If you have not already done so, it is recommended that you read this document.
When modeling XML documents in TransacXML, we follow the convention that all fields that belong to an XMLElement entity are scoped by the Fields function scoped by the entity. This convention ensures that you easily can find the fields used by a specific XMLElement - and that you can change the fields without influencing other documents.
However, you do not have to follow this convention, the patterns works as well when the fields are placed elsewhere. What is important for the patterns are that the fields have the correct inheritance and that the ENT has FLD triples are correct.
The complex element "Race" is modeled as an XMLElement entity with two AttributeFields using the following triples:
Source Object | Verb | Target Object |
---|---|---|
Race | is a ENT | XmlElement |
Race.Fields | field FLD | date |
Race.Fields | field FLD | name |
Race.Fields.date | is a field | AttributeField |
Race.Fields.name | is a field | AttributeField |
Race | has FLD | Race.Fields.date |
Race | has FLD | Race.Fields.name |
The fact that "race" has a child element "Course" and a child element "Horses" is modeled using ENT includes ENT triples:
Source Object | Verb | Target Object |
---|---|---|
Race | includes ENT | Course |
Race | includes ENT | Horses |
At this point, you have defined the entire content of the complex element Race:
The complex element "Course" is modeled as an XMLElement entity with two ElementFields using the following triples:
Source Object | Verb | Target Object |
---|---|---|
Race.Course | is a ENT | XMLElement |
Race.Course.Fields | field FLD | CourseName |
Race.Course.Fields | field FLD | Address |
Race.Course.Fields.CourseName | is a FLD | ElementField |
Race.Course.Fields.Address | is a FLD | ElementField |
Race.Course | has FLD | Race.Course.Fields.CourseName |
Race.Course | has FLD | Race.Course.Fields.Address |
After creating these triples, you have defined the entire content of the complex element Course.
The complex element "Horses" is modeled as an XMLElement without any fields.
Source Object | Verb | Target Object |
---|---|---|
Race.Horses | is a ENT | XMLElement |
"Horses" contains a number of "Horse" child elements. This is modeled as follows:
Source Object | Verb | Target Object |
---|---|---|
Race.Horses | includes ENT | Horse |
After creating these triples, you have defined the entire content of the complex element Horses:
The complex element "Horse" is modeled as an XMLRepeatingElement with an AttributeField and three ElementFields using the following triples:
Source Object | Verb | Target Object |
---|---|---|
Race.Horses.Horse | is a ENT | XMLRepeatingElement |
Race.Horses.Horse.Fields | field FLD | Name |
Race.Horses.Horse.Fields | field FLD | Value |
Race.Horses.Horse.Fields | field FLD | DateOfBirth |
Race.Horses.Horse.Fields | field FLD | Gender |
Race.Horses.Horse.Fields.Name | is a FLD | AttributeField |
Race.Horses.Horse.Fields.Value | is a FLD | ElementField |
Race.Horses.Horse.Fields.DateOfBirth | is a FLD | ElementField |
Race.Horses.Horse.Fields.Gender | is a FLD | ElementField |
Race.Horses.Horse | has FLD | Race.Horse.Fields.Name |
Race.Horses.Horse | has FLD | Race.Horse.Fields.Value |
Race.Horses.Horse | has FLD | Race.Horse.Fields.DateOfBirth |
Race.Horses.Horse | has FLD | Race.Horse.Fields.Gender |
After creating these triples, you have defined the entire content of the repeating complex element Horse - and the entire document:
If the fields you handle in the XML document maps directly with your existing database fields, consider inheriting from ElementFieldUT and AttribtuteFieldUT instead. By doing so you can also inherit from the corresponding database field - thus making the mapping of values between XML and database easier.
To show the modeling of namespaces, three namespace declarations have been added to the example document and all elements have been assigned to a namespace.
The basic definitions are exactly the same as for document with no namespaces. In the following description, only the additional definitions will be described.
This defines the elements as belonging to a namespace.
Source Object | Verb | Target Object |
---|---|---|
Race | is a ENT | NamespaceAware |
Race.Course | is a ENT | NamespaceAware |
Race.Horses | is a ENT | NamespaceAware |
Race.Horses.Horse | is a ENT | NamespaceAware |
Race.Course.Fields.CourseName | is a FLD | NamespaceAware |
Race.Course.Fields.Address | is a FLD | NamespaceAware |
Race.Horses.Horse.Fields.Value | is a FLD | NamespaceAware |
Race.Horses.Horse.Fields.DateOfBirth | is a FLD | NamespaceAware |
Race.Horses.Horse.Fields.Gender | is a FLD | NamespaceAware |
This inheritance provides two source-codes "Namespace" and Prefix" for each element.
To assign the specific namespace and prefix to each element specify the following literal values for these source codes:
Race.Namespace
http://www.websydian.com/examples
Race.Prefix
ex
Race.Course.Namespace
Race.Course.Fields.CourseName.Namespace
Race.Course.Fields.Address.Namespace
http://www.websydian.com/examples/course
Race.Course.Prefix
Race.Course.Fields.CourseName.Prefix
Race.Course.Fields.Address.Prefix
co
Race.Horse.Namespace
Race.Horses.Horse.Namespace
Race.Horses.Horse.Fields.Value.Namespace
Race.Horses.Horse.Fields.DateOfBirth.Namespace
Race.Horses.Horse.Fields.Gender.Namespace
http://www.websydian.com/examples/horse
Race.Horse.Prefix
Race.Horse.Horses.Prefix
Race.Horses.Horse.Fields.Value.Prefix
Race.Horses.Horse.Fields.DateOfBirth.Prefix
Race.Horse.Fields.Gender.Prefix
ho
If you have a lot of elements in the same namespace, consider creating an abstract XMLElement and ElementField (and AttributeField if necessary) for the namespace. Let the abstract objects inherit from NamespaceAware and specify the values for namespace and prefix on these abstract Plex objects.
Inherit from these entities/fields instead of directly from the NamespaceAware objects. By doing so, you can be certain that the namespace and prefix are the same for all elements and attributes that should use this namespace. It also ensures that you only have to change one thing if the namespace changes.
More information about modeling, creating and processing XML
Parts documentation for TransacXML
Other Uses documentation for TransacXML
Namespace declarations explained