[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ubl-ndrsc][ubl-lcsc] Agreed Container Rule
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
- From: "A Gregory" <agregory@aeon-llc.com>
- To: "'Stephen Green'" <stephen_green@bristol-city.gov.uk>,<abcoates@londonmarketsystems.com>
- Date: Mon, 7 Jul 2003 11:15:20 -0700
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]