9.15 XPathNodeType

An enumeration of the types of results that may come back from an XPath query.

Note: This enumeration is compatible with a similar enumeration utilized in the Microsoft .NET framework.

10 Data Exchange Model Conventions

Models that can be used by the model-based DataExchange interface methods are defined in Annex A. These models are defined in the form of XML Schemas written in Relax NG Compact form of DSDL as specified by ISO/IEC 19757.

Note: An implementer may translate the Relax NG Compact form to other forms for use within their implementation as long as the exchanged XML Infosets will validate against the schema specified by the standard. For example, a particular implementation may internally utilize a schema with stronger validation rules (e.g. using Schematron rules as specified in ISO/IEC 19757, or using XSDL with assertion rules) as long as the XML produced for exchange over the interface can be parsed with the schema specified in the standard, and that XML from well-formed DICOM objects produced by the schema specified in the standard can still be utilized by the implementation's internal schema.

Actual instances of the models are XML Infosets. Annex A follows the following conventions in describing models.

Notes: 1. The models are defined via XML schemas to allow the use of commonly available tools to manipulate and navigate the model. For example, an XPath statement can be used to identify portions of interest within the model such as a particular DICOM Attribute and extract it.

2. Some implementations may parse directly from the incoming object, which may not be in XML form, into an internal representation, such as the domain object model (DOM) without ever having converted the object to XML.

Within each model description is a table of XML Elements and XML Attributes used to describe an XML Infoset of that model. These tables utilize the following conventions:

  1. XML Element names (listed in the first column) are in CamelCase, with the first letter capitalized.

  2. XML Attribute names (listed in the first column) are in camelCase with the first letter in lower case.

  3. XML Element and XML Attribute names with a set of “>” characters in front of them are nested within the first preceding XML Element with one fewer “>” characters in front of its name. A nested XML Attribute is associated with the immediately enclosing XML Element.

  4. The entries in the “Optionality” column have the following interpretations:

  5. “R” indicates that the XML Element or XML Attribute is required in all models.

  6. “C” indicates that the XML Element or XML Attribute is required in all models if the condition stated in the Description is met.

  7. “O” indicates that the XML Element or XML Attribute is optional.

  8. If the XML Element or XML Attribute is nested inside another XML Element, and that enclosing XML Element is not present (i.e. it is defined with an Optionality of “O” and is not present in the XML Infoset, or it is defined with an Optionality of “RC” and is not included in the XML Infoset because the condition was not met), then the nested XML Element or XML Attribute shall not be present in the XML Infoset irrespective of its optionality.

  9. The entries in the “Cardinality” column have the following interpretations:

  10. “A” indicates that this is represented as an XML Attribute instead of an XML Element, hence has a cardinality of 1 by definition.

  11. “1” indicates that only a single instance of this XML Element is included inside the immediately enclosing XML Element, or at the top level if this XML Element is not nested inside another XML Element.

  12. “0-n” indicates that zero to n instances of this XML Element are included inside the immediately enclosing XML Element, or at the top level if this XML Element is not nested inside another XML Element.

  13. “1-n” indicates that one to n instances of this XML Element are included inside the immediately enclosing XML Element, or at the top level if this XML Element is not nested inside another XML Element.

  14. Sets of XML Elements and XML Attributes that are often repeated within models may be defined as macros. Macros that may have general applicability are defined in this section. Macros that are unique to a particular model may be defined in the Annex specific that model. When a macro is included within a table, it is as if the contents of the Macro’s table were inserted within the table referencing the macro. Any set of “>” characters in front of the directive to include a Macro in the table are prepended to the XML Element and XML Attribute names listed in the Macro’s table.