Re: [ubl-ndrsc] Containers: R116

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

I'd like to elaborate on Lisa's initiation of the discussion.
As LC plans to implement NDR checklist for 1.0, and time is
running short, supporting or differing opinions should be
heard very soon.  Otherwise, downstream work will get stuck.
So members of the list please kindly respond.

If there is no consensus, or no proposed responses to the
questions, or simply no discussions, then it may be necessary 
to remove this rule from the NDR checklist and defer 
containership altogether until the time the issues reach
further maturity.



On Fri, 27 Jun 2003, Lisa-Aeon wrote:

>>...
>>The questions still outstanding are:
>>
>>1.  Why are there so many container types as opposed to one generic UBL one?
>>This has been answered, but would like to see rationale behind it.

It was not stated how containers are to be implemented from
reading the latest NDR Checklist, but from discussions done in
the past, the assumed implementation appears to be one container
type per 1..n type element declaration.  

This results in many container types, as essentially all 1..n
types will have twice the schema types.  And if 0..n gets 
implemented similarly, then all 0..n types will also have 
twice the schema types.  Why do we need so many container types
that load up the UBL processor's memory and slow things down?

The rationale behind such proliferation of container types
is not satisfactorily explained.  This is especially so when 
these container types are just carriers that contribute nothing 
to the model.  A simpler solution could be used to reduce this
"80%-resource-usage/20%-work-done" situation.

A single container type that permits any type can be a solution 
to all locations where containers are needed.  This has the
implication that the schema validator part of UBL processor
need not do that much validation work with the entire container
containing the list of elements as a whole.  Instead, as the
list of elements in the instance space will need to be 
looped through for processing anyway, individual elements will 
have to be visited again during list step-through, thus presenting
another opportunity for validation of individual list elements.  




>>2.  0..n has not been addressed.

Previous discussion ended somewhat with the deferral to NDR Chair 
to decide whether to open up this topic for discussion.

It is necessary for 0..n's case to be rounded up and fully explored
side-by-side the 1..n case in order for implementation of containers
to be systematic and symmetric.  This is obvious from the fact that
0..n instance can easily become 1..n as soon as one element is
instantiated.  So ignoring this 0..n issue is not a satisfactory 
treatment of the containership solution to me.

This topic has been opened.  Please kindly respond with a proposal
for 0..n that is symmetric in treatment to 1..n.




>>3.  The way to implement list containers.  It seems to be assumed that
>>container tags will be generated on the fly.  There is conflict in the way
>>this is assumed.  Discussion has it that there is one type for each list,
>>where are these types in schema?

It is not clear from reading the NDR checklist how the mechanism
of implementing containers should be carried out by UBL processors.

On one hand, the multiply-typed containers mentioend but disagreed
in (1) seem to suggest that multiple schema types be defined
for the containers.  This is presumably a result of overloading
the schema validator portion of a UBL processor to also validate
containers with all its list elements as a whole.  If containers
are validated by schema validators, then we'll need the proposer
of containership to define the schemas and describe means to
merge in a non-conflicting way with existing non-containered 
schemas.

Email correspondences, on the other hand, appear to suggest 
(and please correct me if I'm mistaken in summarizing here) that
containers are not part of the model and thus do not appear in
the UBL schemas.  If they're implemented on the fly, then all
the more we need detailed specifications on what on-the-fly
implementation can/cannot/must/must-not/shall/shall-not do
to containers and their list elements.

How do the two expectations reconcile with each other?





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