Re: [ubl-ndrsc] Rule: 115 and 116 Containers

[Chin Chee-Kai <cheekai@softml.net>]

>>[R 115]  All documents shall have a container for metadata  and which
>>proceeds the body of the document and is named  "Head" _____________.
>>(anything but header)

>>[R 116]  All elements with a cardinality of 1..n, (and lack a qualifying
>>structure) must be contained by a list container named  "(name of repeating
>>element)List", which has a cardinality of 1..1.

I remain critical of having to maintain such virtual structure
for no apparent use.  I've heard that the rules don't affect FPSC
at all.  By design, they should not affect LC.  So who's benefiting
from carrying all the empty luggages around?


That said, I pointed out last time that the [R 115] should have
"precedes" instead of "proceeds", unless the proponent of the
rule wants Head sitting at the tail.



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/


On Wed, 16 Jul 2003, Lisa-Aeon wrote:

>>Rules for Voting:  Each email will have only one rule in it, I will try to
>>mark the rules that group with it, or rules that might duplicate it.  The
>>membership has 5 working days to bring forth objection or discussion, after
>>the 5 working days, if there are no objections, the rule will be assumed to
>>be "ACCEPTED" and be given to the LCSC for their implementation.
>>
>>Please Reply leaving first email in Reply.
>>
>>Voting period on this rule ends:  July 23, 2003
>>
>>*******************************
>>I am combining the last two rules, because we have already voted on a
>>decision.  These are the old rules:
>>
>>[R 115]  All documents shall have a container for metadata  and which
>>proceeds the body of the document and is named  "Head" _____________.
>>(anything but header)
>>
>>[R 116]  All elements with a cardinality of 1..n, (and lack a qualifying
>>structure) must be contained by a list container named  "(name of repeating
>>element)List", which has a cardinality of 1..1.
>>
>>These are the new rules agreed upon during the teleconference call on 9
>>July.  These are voted as approved, just need polishing up.  To remind
>>everybody, here is the motion and it was approved.
>>
>>***Motion:(Arofan) We agree in the direction of the rules being submitted,
>>a. Endorse the direction as indicated in this proposal.
>>
>>b. Authorize Arofan to make the changes that were discussed in this meeting.
>>
>>Changes:
>>
>>Substitute the word "Top" for "Head",
>>
>>Make sure we have explicitly covers the 1..n in the wording.
>>
>>c. Authorize Mark to make editorial changes.
>>
>>d. Submit to list for final approval. (vote by email)
>>
>>******
>>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 "Top" element in the
>>schema. The generated "Top" element will be named "[doctype]Top", and its
>>content model will be a sequence. It will reference a generated type named
>>"[doctype]TopType". Both the generated "Top" 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 "Top" 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 "Top" 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 "top" elements in all documents should be gathered together into a
>>common aggregate type, named "TopType", 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.)
>>
>>
>>---
>>Outgoing mail is certified Virus Free.
>>Checked by AVG anti-virus system (http://www.grisoft.com).
>>Version: 6.0.498 / Virus Database: 297 - Release Date: 7/8/2003
>>
>>
>>
>>---
>>
>>File has not been scanned
>>
>>Checked by AVG anti-virus system (http://www.grisoft.com).
>>Version: 6.0.498 / Virus Database: 297 - Release Date: 7/8/2003
>>