No Subject

For (1), the primary advantage I see is in helping schema designers
(ie. those applying context methodology to derive their localised
schema set from UBL's schema set).  That said, I also see that the
cons are that it tends to increase the depth level in the schema
space, without a corresponding depth synchronisation in the instance
space.  As much as an advantage in hiding the contained elements
as it is a disadvantage in misaligning depth levels between
schema space elements and instance-space elements, it seems to me
the confusion might not be worth the bit of visual advantage gained.

Second reason is that applying multiply the containership in 
the schema space will mean nested containers that have to bear some
sort of business meaning.  Who defines such meaning, how should
such nesting be interpreted, etc are questions not immediately
clear why we are introducing questions just to try to answer them.
By and large, some of the legacy messaging standards don't have
an equivalent schema container concept.  Such a "new" concept
might become a hindrance to understanding and porting instead
of helping.  For 1p00 at least, I'm incline to actually think
that a simple and "flatter" one-to-one sort of schema, as 
demonstrated explcitily well in 0p70, could be more helpful
to those migrating, doing it first-time, or getting lured into
e-business because of the simplicity of UBL.


For (2), I tend to agree that some long list of related items in
the instance space will better be bunched together, and thrown
into a container.  This is helpful as long as the "related items"
can have business or semantics meaning to the originator or receipient,
so that the depth-level carry some sort of meta-information.
Provided this exists, tools such as XSLT and other visualization
and rendering conversions could bring out such meta-info by
positioning them in some meaningful hierarchical way, such as
box-within-box, tree-links, top-to-bottom topology, etc.  
This makes understanding the biz doc clear and meaningful.
So I do hope something useful can come out from the F2F discussion
on this topic.

Thanks.




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