TransacXML Other Uses

Introduction    Implementing    Other Uses    Parts    Tutorial    Glossary

• Exporting Data From a Database

• Performing Other Data Processing

• Inheriting from Untyped Abstract Fields

• Type Conversion

• Long Names

• Defining Null Value Literals

• Simple Element with Attributes

• Create Document Definitions

Exporting Data From a Database

When exporting data from a database into an XML document the structure of the XML document is modeled in Plex using the WsyXml objects XmlElement, XmlRepeatingElement, ElementField, RepeatingElementField, and AttributeField. The XML structure defined in Plex is called a model of the XML document.
Please refer to Implementing Import and Export of XML Document in the tutorial for further details.

The data from the database are represented in the model with fields inheriting from either ElementField, RepeatingElementField, or AttributeField. However, in some situations it is preferable to reuse the existing database fields for the XML document model in Plex, e.g. when the database is very complex and contains many fields. This way a very close relation is maintained between the database model in Plex and the XML structure.

To use database fields in the XML structure model for a specific element (MyXmlElement) enter the following triples in the Plex model:

If the database field names does not follow the XML Standard (e.g. if a name contains spaces) use the option UseImplementationNameForFields. Then the field implementation name will be used as the element name instead of the field name.

Performing Other Data Processing

In real world applications there is not always an one-to-one match between the elements defined in the XML document structure and the data structure of the application database.  Often, processing needs to be defined which walks through the data being read. For instance, the values of certain fields in the application database might depend on other data read from the XML document. 

In some cases it is best to resolve any derived database field values on-the-fly as data is being read from the XML document. In other situations the best approach is first to populate the application database with as many data as possible, and then resolve the values of the rest of the database fields in subsequent processing.

Inheriting from Untyped Abstract Fields 

When modeling the XML structure into triples and objects in the AllFusion Plex model, the fields thus created inherit from either of the abstract fields AttributeField, ElementField, or RepeatingElementField. These three abstract fields in turn indirectly inherit from the XmlDataString. This way, all fields created as part of the  Implementation process will have the common ancestor XmlDataString, which by inheritance has the field type Character. 

In some cases it is desirable to avoid inheritance from XmlDataString. This is the case when fields in the model created via the implementation guide should have the same types as their application database counterparts. 

Three extra abstract fields AttributeFieldUT, ElementFieldUT, and RepeatingElementFieldUT have been provided. These three fields, which are ancestors of AttributeField, ElementField, and RepeatingElementField respectively, do not inherit from XmlDataString. Therefore, fields inheriting from either AttributeFieldUT,  ElementFieldUT, or RepeatingElementField have no field type.

A field being created as part of the modeling  process should inherit from either the appropriate un-typed abstract field (e.g. AttributeFieldUT) or the appropriate typed abstract field (e.g. AttributeField), depending on the application being built.

When a field inherits from the un-typed fields, remember to specify a type for the inheriting field.

Type Conversion

Transferring data from fields created as part of the modeling process into their application database counterparts may in some situations be non-trivial.

For instance, when retrieving a date from an XML document into a corresponding date field, the string format of the date might not be the same as that of the corresponding database date field. In this case, type casting by means of the Cast statement is not feasible. 

In such cases of non-trivial type casting, the Websydian developer should add the code necessary to carry out the appropriate type casting, instead of using Cast.

Long Names

TransacXML uses entities and fields to reflect XML elements and attributes in the AllFusion Plex model. The name of the entity or field reflecting either an element or attribute in the XML document is the same as that of the XML element/attribute. However, in AllFusion Plex the maximum length of an object name is 32 characters. Therefore, when the DTD of the XML document to be read contains elements or attributes with names longer than 32 characters, extra inheritance triples have to be added as part of the modeling process. 

Letting entities corresponding to XML elements inherit from the abstract LongName entity yields a source code object LongName scoped to the inheriting entity. Similarly, letting fields corresponding to XML elements and attributes inherit from the abstract LongName field yields a source code object LongName. 

The real (long) name of the entity/field can now be specified in the large property of the LongName source code object. For details on how exactly to specify the long name, refer to either the section about long name entities or the section about long name fields in the Implementation Guide.

Defining Null Value Literals

The SingleFetch and FlatView functions will return null values in the fields whose corresponding elements/attributes are not present in the XML document being read. This is useful when attributes or simple elements are optional.

Through their (indirect) inheritance from  NullValue, the fields reflecting XML simple elements or attributes scope a value Null which by inheritance contains the empty string as its literal.

The inherited Null value literal of a field can be overridden by a new literal. When the corresponding element/attribute is not found in the XML document being read, the SingleFetch and FlatView functions will return the specified null value string in the relevant field. For further information, refer to the section about null values in the Implementation Guide.

Simple Element with Attributes

TransacXML does not support simple element with attributes. For a workaround to this restriction please refer to this document.

Create Document Definitions

When designing XML documents it is often a requirement to describe the structure of the XML document using either DTDs or schemas.

With TransacXML it is easy to create a DTD or schema representation of the XML model in CA Plex. The only requirement is that all of the XMLElement entities in the document must inherit from the XMLElementWithServiceFunctions entity to be able to create a schema for the document.

For more details concerning the creation of DTDs see CreateDTD.

For more details concerning the creation of schemas see the Create Schema Guide.