Clarification of Containership rules

[Tim McGrath <tmcgrath@portcomm.com.au>]

Following our phone conference yesterday, I agreed to provide you with 
some guidelines that will enable you to refine the current position 
paper and NDR Rules on this matter.

The following have agreed to assist in your work, to provide examples 
and comments on your drafts.

Stephen Green (stephen_green@bristol-city.gov.uk)
Tony Coates (abcoates@londonmarketsystems.com)

The timeframe for completion of this task should be Tuesday July 8th - 
the LC team have a meeting at 08:00 California time at which we would 
like to table your findings.

Scope of Work:
-------
Currently the NDR Checklist contains two rules:
1. All documents shall have a container for metadata and which proceeds 
the body of the document and is named "Head" _____________. (anything 
but header)
and
2. 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 rules require refinement and clarification.  Your mission (should 
you accept it), is to present a revised set of rules with documentation 
and examples that can be unambiguously and consistently implementable 
across the UBL Library.  To assist in this I have tried to summarise the 
points as a  problem statement...

Problem Statement:
--------------------
The LC group have had difficulty in implementing these rules 
unambiguously for all document types and structures.  We understand that 
these rules should not be dependent on semantics or business context and 
this prevents us from automatic generating them from our models.

Some issues (and these are not all) we have encountered are:
* Documents which have more than one 1:many association at the 
"Header"/root level.  That is, where not only the "lines" can repeat 
indefinitely, such as Invoice with AllowanceCharge, 
OrderDocumentIdentification, TaxTotal.  We are concerned that this 
portends more ambiguities when we deal with documents that are not 
simple Header+LineItem(s),structure such as the transportation 
documents.  This is already seen in the DespatchAdvice, where the 
document may be viewed as Header+TransportHandlingUnit(s) or 
Header+Goods. A further compelxity is also seen in the DespatchAdvice 
where we have a document that may contain the sub-structure of other 
documents (in this case the OrderedItem(s)).
* If we implement the  "(name of repeating element)List" rule, what is 
done about:
    (a) 0..n structures
    (b) extensions/derivations/customizations that chnage the 
cardinality of an ABIE (e.g. make an optional ABIE, mandatory)
Do we want additional levels of nesting that may hold empty containers, etc?

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160