optional elements in HL7

If an HL7 TC does not specify that an element is required then each implementation must choose whether to make it required or not permitted. If your implementation requires the element then the 1..1 cardinality means that each message instance must have a value for that element but that value could be a nullFlavor. (Gregg Seppala)

XML namespaces for HL7

Charlie et al.,
Please understand that many developers are going to work at the schema
level. I do sympathize that the present means of importing schemas is very
wordy. Since complexType definitions are identified by their name and target
namespace, overloading of type names can cause problems. In large projects,
the use of the same name for different datatypes is hard to avoid. In XML
schema, the unambiguous identification of the namespace where the type was
created is achieved by the use of prefixes. The combination of prefix and
type are validated.

I agree that a single namespace is easier for the original programmer of the
schema generator; however, minimization of the number of keystrokes required
to create code is of a low priority. HL7 is used in medical devices, which
requires that good software engineering principles be followed. The schemas
need meaningful names. The present design is too hazardous to be used in
medical devices. Readability and traceability reduce mistakes. A single
namespace will result in a horrible maintenance problem. How many lines of
code are included in the present XML schemas? One of the first rules of
software engineering is to divide and conquer. The present design does not
permit one to readily trace the source of a datatype.

There are only two places where I might use an include element: 1) to make
directly visible parent schemas into their children and 2) for the types of
the schema for XML. Placing xs: before all of the common datatypes is
incongruous and clutters up the schema code. Periods or another separator
can be used in the names to show inheritance trees.

"Creating a separate namespace for every message type results in a huge
proliferation of different representations for the same underlying semantic,
and this problem persists to a lesser degree as you walk back up the stack
towards the most abstract (ie the RIM)."

No! One can group closely related datatypes into one schema. Inheritance by
extension and composition (group containing a sequence of elements,
attribute groups, and substitution groups) works in XML schema. We need an
expert opinion to determine if in XML schema 1.1 inheritance by restriction
works between schemas (see quotation below).

From: XML Schema 1.1 Part 1: Structures
W3C Working Draft 31 August 2006
(http://www.w3.org/TR/2006/WD-xmlschema11-1-20060831/)
"Issue (RQ-17i):Issue 2820 (RQ-17 simplify restriction rules)"

"Version 1.0 made clear that the intention for derivation by restriction was
that restrictions validated a subset of what their base validated. However,
the constructive rules for what constituted valid content model restrictions
for complex type definition not only failed to enforce this completely
correctly, but also ruled out various cases which evidently should have been
allowed. The Working Group has decided to shift to a much higher level
statement of what constitutes a valid restriction, appealing directly to the
subset requirement, in order to address these problems."

"Resolution:

A major change in definition/presentation, with only modest changes in
consequences for schemas and validity, will be made, by defining restriction
for complex type definitions in terms of the desired result, that is that
all members of a restricted type are members of its base type. In the
normative part of the spec. this will be done by appeal to local validity."

"Clarifying: R restricts B: any EII that is locally valid [per R] must also
be locally valid [per B], with side conditions on properties on terms you
appeal to [to] get same child allowed by two content models." [-F2F
2004-03-12, section Subsumption (W3C-member-only link)]"

This appears to mean that the XML schema language will have a significant
improvement in the capacity to design and create datatypes according to
object-oriented techniques. I should note that the capacity to group
related complexTypes in one schema appears to be persevered. This permits
construction of large projects, such as HL7 from a hierarchy of schemas that
is based upon a reasonable number of schemas. It also minimizes the size of
small projects that are developed by domain experts and derived from HL7
schemas. The capacity to create this type of small project will permit the
development of a web of clinical and research services based on HL7.

Yours,
Bob Leif