Specifying Matching Element Types

This should be a string specifying the list of one or multiple matching Element Types.

Some FlexQuery functions working with DSM (Data Source Model) elements use such a specification as a parameter to filter elements to be included in the result of a certain operation (e.g. searching or filtering).

The list of matching Element Types can be defined as:

An element is considered to satisfy such a specification only when it complies with at least one of the specified matching Element Types.

Each Element Type name provided in the specification must be uniquely resolvable to a certain Element Type found in the DSM Type, which the given template is associated with. If that is not the case, an error will be raised.

DSM Types based on XML schemas may contain multiple equally named Element Types, however, with very different content (so they should be treated as different Element Types). Such equally named Element Types arise from locally defined XSD element components, whose names are used also in some other element components defined in that XML schema.

When an XML file based on such an XML schema is parsed, the association of particular XML elements found in it with their types defined in the XML schema is done according to the context, where the given XML element is found (depending on the types of its ancestor elements).

To deal with that problem, for each Element Type, besides its original name obtained from the XML schema (which is called here local name), the XML Type Driver generates also a unique global name. For more details, please see: Generator Object Model | Object Types | GOMElementType.globalName.

Exactly that global name should be used to identify the particular Element Type in most Matching Element Type specifications. However, there are two special cases:

  1. When the tested element has a parent and its type is already known on the moment of writing the Matching Element Type specification (so the parent Element Type is its context), then using local names in the specification will suffice.

    Most frequently, that applies when writing location paths made of child steps.

    It is also applicable for FlexQuery functions like findChild() and similar, when the type of the contextElement actual in that expression is known on the moment of designing the template.

  2. When all equally named Element Types will match, then, instead of listing all of them in the Matching Element Type specification, it is possible to write: ~localName

    For example, the call like:

    instanceOf (
      "xs:restriction |
       xs:restriction%xs:complexRestrictionType |
       xs:restriction%xs:simpleRestrictionType"
    )

    can be replaced with just:

    instanceOf("~xs:restriction")

Example:
"Class"
"Class | Method | Field"
"*"