Technical Comment 311 Bjrn Lfstrand XML Attributes vs. XML Elements

1
Technical Comment 311 Björn LöfstrandXML
Attributes vs. XML Elements

• Description from proposer
• In the current XML Schema the primary method of
  documenting data is by using XML attributes. XML
  Elements is used where more structure is
  required. The OMT DIF XML Schema Tiger Team have
  exploring the possibility of replacing XML
  attributes with the use of XML elements.
• Rationale from propose
• The primary reason is to enable the format to
  become more extensible (allowing user/vendor
  defined substructures to be included as part of a
  model). Another reason is to reduce the number of
  special notes attributes for each item in the
  OMT. By changing an XML attribute to an XML
  element provides the capability to attach
  "attributes" such as notes to each element.
  Information for which the TigerTeam has not seen
  any need for extensibility and where there are no
  notes to be attached the information is still
  recorded in XML attributes. To follow XML
  conventions Names are always recorded as XML
  attributes and the corresponding NameNotes
  information is also an attribute on the same XML
  element.

2
Technical Comment 311 (continued)
Proposed
Existing
3
Technical Comment 311 (continued)

• Proposers Resolution
• Use the XML Schema defined by the TigerTeam which
  uses XML elements instead of XML attributes for
  the majority of information in a model.
• Recommended action
• A1 Adopt as proposed
• Rationale
• No expressive capabilities are lost.
• Removes the parallel notes attribute structure.
• Follows the typical standard of containg the core
  data in a document in data and supporting
  metadata in elements.
• Supports the extensibility since elements can be
  extended with additional elements and attributes,
  whereas attributes can not be extended.
• Requires conversion of existing object models
  but can be accomplished via XSLT.

4
Technical Comment 309 Björn LöfstrandObject
Model Metadata Representation Consistency

• Description from proposer
• The current XML Schema is structured in a way to
  allow "old" models to still be valid. Metadata is
  therefore contained in two different ways. 1) as
  attributes of the objectModel class (the old
  style) and 2) as elements and attributes of the
  modelIdentification XML element. This XML schema
  should keep the meta-data in one way and in one
  place.
• Proposers Resolution
• Use the XML Schema defined by the TigerTeam which
  uses XML elements instead of XML attributes for
  the majority of information in a model.

5
Technical Comment 309 (continued)
Proposed
Existing
6
Technical Comment 309 (continued)

• Proposers Resolution
• Replace current XML Shema with the TigerTeam
  version.
• Recommended action
• A1 Adopt as proposed
• Rationale
• Puts all the object model metadata in a parallel
  structure.
• Requires conversion of existing object models
  but can be accomplished via XSLT.

7
Technical Comment 312 Björn LöfstrandUnique
Identification of Elements

• Description from proposer
• Elements in a model can be referenced by other
  models or possibly from within the model itself.
  In the current XML Schema there is no built in
  support for attaching unique identifiers to
  elements in the model.
• Proposers Resolution
• Allow unique identifiers to be specified for all
  relevant elements as indicated by the XML Schema
  suggested by the OMT DIF XML Schema TigerTeam .

8
Technical Comment 312 (continued)
Proposed
9
Technical Comment 312 (continued)

• Recommended action
• A1 Adopt as proposed
• Rationale
• Allows internal linkages (referential integrity)
  and external linkages across object models
  (important for concepts like BOMs).
• Requires conversion of existing object models
  but can be accomplished via XSLT.

10
Technical Comment 313 Björn LöfstrandEnforcemen
t of OMT Rules via the XML Schema

• Description from proposer
• The current XML Schema supports structural
  validation and validation of datatypes. Other OMT
  requirements, such as attribute datatypes refere
  to items in the right tables is not currently
  supported. There are however some possibilities
  to include validation of uniqueness and
  references using the XML Schema "unique", "key"
  and "keyref" constraints. The XML Schema proposed
  by the OMT DIF XML Schema Tiger Team include such
  constraints on the following
• Object and Interaction class siblings are not
  allowed to have the same name.
• Datatypes are not allowed to have the same name
• Datatype references (if present) must refer to an
  existing simple, array, enumerated, fixedRecor or
  variableRecord datatype.
• Simple datatype representation must be a
  BasicData
• Attribute and Interaction Class dimensions must
  refere to dimensions defined in the Dimensions
  table.
• Attribute and Interaction Class transportation
  type references must refer to transportation
  types defined in the Transportation Type Table.
• Note. Not all constraints on contents present in
  the specification can be enforced by XML Schema.

11
Technical Comment 313 (continued)Unique sibling
class names
ltxselement name"objectClass"gt ltxscomplexType
gt ltxscomplexContentgt ltxsextension
base"objectClassType"/gt lt/xscomplexContentgt
lt/xscomplexTypegt ltxsunique
name"className"gt ltxsannotationgt ltxsdocum
entationgtensures uniqueness of objectClass names
among class siblingslt/xsdocumentationgt lt/xsan
notationgt ltxsselector xpath"./objectClass"/gt
ltxsfield xpath"_at_name"/gt lt/xsuniquegt lt/xs
elementgt ltxselement name"interactionClass"gt lt
xscomplexTypegt ltxscomplexContentgt ltxsext
ension base"interactionClassType"/gt lt/xscompl
exContentgt lt/xscomplexTypegt ltxsunique
name"interactionName"gt ltxsannotationgt ltxs
documentationgtensures uniqueness of
interactionClass names among class
siblingslt/xsdocumentationgt lt/xsannotationgt
ltxsselector xpath"./interactionClass"/gt ltxs
field xpath"name"/gt lt/xsuniquegt lt/xselementgt
12
Technical Comment 313 (continued)

• Proposers Resolution
• Use XML Schema constraints as defined in the
  sugegsted XML Schema defined by the TigerTeam.
• Recommended action
• A1 Adopt as proposed
• Rationale
• Enforces validation of FOM and SOM contents at no
  penalty to existing models.