cobigen xmlplugin

Table of Contents

• CobiGen - XML Plug-in
  • Trigger extension
    • Matcher types
    • VariableAssignment types
    • XML input reader
  • Merger extensions

CobiGen - XML Plug-in

The CobiGen XML Plug-in comes with an input reader for xml artifacts, xml related trigger and matchers and provides different merge mechanisms for XML result documents.

Trigger extension

(since cobigen-xmlplugin v2.0.0) The XML Plug-in provides a trigger for xml related inputs. It accepts xml documents as input (see XML input reader) and provides additional matching and variable assignment mechanisms. The configuration in the context.xml for this trigger looks like this:

• type 'xml'

  Example of a xml trigger definition

  <trigger id="..." type="xml" templateFolder="...">
      ...
  </trigger>

  This trigger type enables xml documents as inputs.

Matcher types

(since cobigen-xmlplugin v2.0.0) With the trigger you might define matchers, which restrict the input upon specific aspects:

• type 'nodename' → document’s root name matching

  Example of a xml trigger definition with a nodename matcher

  <trigger id="..." type="xml" templateFolder="...">
      <matcher type="nodename" value="\D\w*">
          ...
      </matcher>
  </trigger>

  This trigger will be enabled if the root name of the declaring input document matches the given regular expression (value).

VariableAssignment types

(since cobigen-xmlplugin v2.0.0) Furthermore, it provides the ability to extract information from each input for further processing in the templates. The values assigned by variable assignments will be made available in template and the destinationPath of context.xml through the namespace variables.<key>. The XML Plug-in currently provides only one mechanism:

• type 'constant' → constant parameter

  <trigger id="..." type="xml" templateFolder="...">
      <matcher type="nodename" value="\D\w*">
          <variableAssignment type="constant" key="domain" value="restaurant" />
      </matcher>
  </trigger>

This variable assignment assigns the value to the key as a constant.

XML input reader

(since cobigen-xmlplugin v2.0.0) The Cobigen XML Plug-in implements an input reader for parsed xml documents. So API user can pass org.w3c.dom.Document objects for generation. For getting the right parsed xml inputs you can easily use the xmlplugin.util.XmlUtil, which provides static functionality to parse xml files or input streams and get the appropriate Document object.

Template object

Due to the heterogeneous structure an xml document can have, the xml input reader does not always create exactly the same model structure (in contrast to the java input reader). For example the model’s depth differs strongly, according to it’s input document. To allow navigational access to the nodes, the model also depends on the document’s element’s node names.

%TODO allow both, navigational acess AND ieration over list

The XML input reader will create the following object model for template creation (EXAMPLEROOT, EXAMPLENODE1, EXAMPLENODE2, EXAMPLEATTR1,…​ are just used here as examples. Of course they will be replaced later by the actual node or attribute names):

• _EXAMPLEROOT

  • nodeName ('String' :: Simple name of the root node)

  • text ('String' :: Concatenated text content (PCDATA) of the root node)

  • TextNodes ('List<String>' :: List of all the root’s text node contents)

  • at_EXAMPLEATTR1 ('String' :: String representation of the attribute’s value)

  • at_EXAMPLEATTR2 ('String' :: String representation of the attribute’s value)

  • at…​

  • Attributes ('List<Map<String, Object>>' :: List of the root’s attributes

    • at ('Map<String, Object>' :: List element)

      • attName ('String' :: Name of the attribute)

      • attValue ('String' :: String representation of the attribute’s value)

  • EXAMPLENODE1~ ('Map<String, Object>' :: One of the root’s child nodes, with the common element sub structure)

    • nodeName ('String' :: Simple name of the current node)

    • text ('String' :: Concatenated text content (PCDATA) of the current node)

    • TextNodes ('List<String>' :: List of all the node’s text node contents)

    • at_{EXAMPLEATTR11} ('String' :: String representation of the attribute’s value)

    • at_{EXAMPLEATTR12} ('String' :: String representation of the attribute’s value)

    • at…​

    • Attributes ('List<Map<String, Object>>' :: List of the node’s attributes

      • at ('Map<String, Object>' :: List element)

        • attName ('String' :: Name of the attribute)

        • attValue ('String' :: String representation of the attribute’s value)

    • EXAMPLENODE11~ ('Map<String, Object>' :: One of the nodes’s child nodes)

      • …​common element sub structure…​

    • EXAMPLENODE12~ ('Map<String, Object>' :: One of the nodes’s child nodes)

      • …​common element sub structure…​

    • EXAMPLENODE…​

    • Children ('List<Map<String, Object>>' :: List of the nodes’s child elements

      • child ('Map<String, Object>' :: List element)

        • …​common element sub structure…​

  • EXAMPLENODE2~ ('Map<String, Object>' :: One of the root’s child nodes)

    • …​common element sub structure…​

  • EXAMPLENODE…​

  • Children ('List<Map<String, Object>>' :: List of the root’s child elements

    • child ('Map<String, Object>' :: List element)

      • …​common element sub structure…​

In contrast to the java input reader, this xml input reader does currently not provide any additional template methods.

Merger extensions

There are two merge strategies for XML documents, which can be configured in the templates.xml:

• Merge strategy javamerge (merges two XML documents and keeps the existing XML elements on conflicts)

• Merge strategy javamerge_override (merges two XML documents and overrides the existing XML elements on conflicts)

As XML is a meta-language, it is not possible to compare all the different XML-based languages in a correct semanitcally way. Thus the current merge algorithm is based on some documents, which have been interesting to be merged in the past, like, spring bean specifications and xml specifications of named queries.

The current algorithms looks like this:

1. If the two elements declare an id attribute

   • If the two elements declare an attribute id

     • the value of the attribute id will be compared and result of the comparison

2. If the two element’s qualified name is "import"

   • If the two elements declare an attribute resource

     • the value of the attribute resource will be compared and declared as the result of the comparison

3. If the two element’s qualified name is "query", "property", or "define"

   • If the two elements declare an attribute name

     • the value of the attribute name will be compared and declared as the result of the comparison

4. If the two element’s qualified name is "transition"

   • If the two elements declare an attribute on

     • the value of the attribute on will be compared and declared as the result of the comparison

5. If the two element’s qualified name is "outputLabel" or "message"

   • If the two elements declare an attribute for and an attribute value

     • both values will be compared and declared as the result of the comparison

   • If the two elements only declare the attribute for

     • the value of the attribute for will be compared and declared as the result of the comparison

6. If the two element’s parents are equal

   • the value text value will be compared and result of the comparison

7. All other elements will only be compared by the precondition (equal node name)