Containers and XML ADI container names

When data is requested from a resource manager, the granularity of the XML data returned is at the level of a single container of information.

The container is normally also the smallest data element (for example, elements that might be considered for billing purposes). This convention was adopted for the ADI XML model as well. The ADI used in authorization rules is also defined and manipulated as containers of XML data. For example, the JohnSmith XML object defined in XML entitlement example is an example of an ADI container.

The top-most element in the definition of an item of ADI is termed the container name of that item of ADI. To define an authorization rule, always reference the XPath to the XML definition of data in any ADI container. Specify the name of the container as the first element /XMLADI in the XPath specification for the data element.

Returning to the example ADI item JohnSmith, we can assume there is a container received from the data provider named JohnSmith. To access any element within the JohnSmith container, the XPath specification must be prefixed with JohnSmith. For example, JohnSmith/CreditCard/AcctNumber refers to the AcctNumber value. To access this information from within an authorization rule, this XPath must also be prefixed by the top-level element of the XML target ADI input document. The element is XMLADI (for example, /XMLADI/JohnSmith/CreditCard/AcctNumber). However, both of these XPaths are valid when used in an authorization rule. The validity is due to the default template match statement that is added to all authorization rules that do not explicitly include one. The default template match statement matches the ADI XML document from /XMLADI. JohnSmith can be referred to either with a relative reference or with an absolute reference that is prefixed with /XMLADI. See Format and constraints of rules.

Parent topic: ADI XML document model