Greetings
Arofan Gregory, Tony Coates and myself have agreed on the attached forwarded rules for containers / heads.
We would just add that the lines in the List containers will always be 1..n
Tony and I will present these on the LCSC call tomorrow and hopefully all three of us should be there for the NDRSC call on Wednesday.
Regards
Stephen Green
Tony/Stephen:
Here is the result of my recent discussion with Stephen, along with a
proposal of the rules themselves:
- Stephen will take this e-mail and discuss with Tony the contents, to
make sure that we agree on them. Changes should be made if not major -
if they are major, then I'd like a chance to agree (if possible).
- I will not be on the LCSC call, but - since we have met LCSC's primary
requirement that the business models themselves are unaffected, they
shouldn't have a major problem with the proposal.
- We will all be on the call for Wednesday, to present this to NDR.
- I will talk to Lisa Seaburg (who happens to be chairing both meetings
this week) to make sure we are on the agenda, preferably as the first
item of business.
- NOTE: There is one issue that hasn't really been discussed: according
to the rules below, even documents with no 'body' lists will get a
header. There are, in my opinion, good reasons for this:
(1) Any people extending the document with a "____List" element will
need the distinction between Head elements and their additions,
especially when it comes to polymorphic processing of two disparate sets
of extensions (per Context Methodology)
(2) The rules can be much more consistent if we always agree to have a
head container
I leave it up to you to discuss and alter as you see fit, but you know
what my reasoning is.
- Rule (4), below, makes sense to me and addresses some issues that have
been raised about "generic" headers. This rule applies the basic
approach of the Context mechanism, which relies on inheritance in XSD,
to the re-use of header information. TRhis one may get killed if you
think its too far out of scope or whatever, but I think it is a useful
rule.
Here is my proposed full set of rules, as discussed:
_________________________________
(1) All non-repeatable BIEs that are direct children of the
document-level BIE in the model will be child elements of a generated
"Head" element in the schema. The generated "Head" element will be named
"[doctype]Head", and its content model will be a sequence. It will
reference a generated type named "[doctype]HeadType". Both the generated
"Head" element and its type will be declared in the same namespace as
the document-level element. (Note: This rule implies that all documents
will have generated "Head" elements, without exception, regardless of
their other 'body' contents, to cover cases where the document will be
extended with the Context mechanism, and for general consistency.)
(2) All repeatable BIEs in the model will have generated containers. The
containers will be named "[name_of_repeatable_element]List". These
containers will be required if the cardinality of their contained
immediate children requires at least one; if their contained children
are optional; the container itself will be optional. At least one of the
repeatable children of the List will always be required, but there may
be more than one required child if that agrees with the cardinality
found in the business model.
All "_____List" elements will reference a "_______ListType", which will
be declared in the same namespace as the element that represents the
repeatable BIE in the business model. The content model of this type
will have a single child element, which will have a maximum occurrence
that reflects the maximum occurrence in the business model, and a
minimum occurrence as described in this rule, above.
(NOTE: This rule applies equally to 'list' containers at the document
level, and also at lower levels within the document.)
(3) The document element in the schema will have a content model that is
a sequence of elements, the first of which will be the "Head" element,
and the others will be the generated "List" elements, in the order in
which their contained, repeatable children appeared in the model.
(4) All elements in the generated schema that are direct children of the
generated "head" elements in all documents should be gathered together
into a common aggregate type, named "HeadType", which will be declared
in the Common Aggregate Types namespace. This type should be declared
abstract, and all document headers should be extensions - even if only
trivial extensions to facilitate re-naming - of this abstract type.
(Note: This rule allows for polymorphic processing of the set of generic
header elements across all document types.)
____________________________________________
Cheers,
Arofan