Re: [ubl-dev] UBLish v2.0: Problems found with QDT & CAC

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

Your comment or feedback on the following would be most appreciated in 
the following observation.

* (What I think is reasonable) Assumption: CommonAggregateComponent 
(CAC) schema is a library of ABIEs so that main document schemas, 
whether or not UBL-developed, could reuse these.

--> Deduction: So we would  say that CAC schema types are 
self-contained  ABIEs built from CommonLibrary spreadsheet, so that CAC 
schema is only included by other (higher-level) schemas and itself does 
not include other types, whether explicitly through <xsd:include> or 
implicitly through additional declaration of types outside of what are 
found in CommonLibrary spreadsheet.

--> Further Deduction: A litmus test is that if a main document 
(UBL-developed or otherwise) needs certain common library ABIE, say 
MyParty, it would include CAC schema through <xsd:include> and then 
reference the types and elements.  If the needed type is not found in 
CAC, as is the case with MyParty example, then the main document 
designer might choose to:

    * remodel his data model requirements so as to be able to use
      existing  types/elements in CAC (eg Party),
    * refrain from using types/elements not found in CAC by limiting the
      extents of his modeling (ie don't use MyParty somehow),
    * declare additional elements and types peculiar to  that main
      document so as to complete it (eg declare complexType inside of
      main document to supplement needed MyPartyType under main
      document's namespace),
    * other methods.


Now we logically would not expect the "other methods" to imply changing 
CAC so that CAC includes MyPartyType under UBL namespace.  Fair to say 
this?  For otherwise, the implication is that additional main documents 
included into UBL package would imply changing CAC to include additional 
main-document-peculiar types & elements.  It makes CAC & CBC schemas 
very vulnerable to changes and less stable for existing users if that 
happens (or was the intent).  I highly doubt so.

Now, working on UBLish v2.0 and from my exploration with the CAC, CBC 
and ApplicationResponse (a main document), here are the observations:

   1. No SenderParty is found in CommonLibrary spreadsheet
   2. (So) CAC schema generated by UBLish v2.0 (naturally) gives no
      definition of type cac:SenderPartyType nor element cac:SenderParty
   3. (But) UBL v2.0's CAC schema contains a cac:SenderParty element
      with (cac:)PartyType.
   4. SenderParty is referenced as an ASBIE in ApplicationResponse
      spreadsheet.
   5. ApplicationResponse's schema references <cac:SenderParty>, but
      does not define, leaving definition to CAC.  This possibly
      explains the presence of <xsd:element name="SenderParty" 
      type="PartyType"> in UBL v2.0's CAC schema.

However, this  declaration cannot be  traced to any part of 
CommonLibrary spreadsheet, which is the source modeling document for 
CAC.  The likely way to understand such a structural arrangement is that:

    Since  SenderParty is used in ApplicationResponse (a main document
    and likely other main documents), we should define it in CAC  so as
    to reuse the element.

But in the initial exposition, if we change "MyParty"  to "SenderParty" 
to interpret the above observations, it would seem strange to find the 
presence of SenderParty in CAC schema and yet undefined in CommonLibrary 
spreadsheet.  Further, the implication of  modifying CAC schema just 
because other main document schema/s is/are using certain element seems 
to fall short of an expected clean layout where CAC/CBC form the basic 
foundation of ABIEs unshaken and unstirred by usages and definitions of 
other main documents.

A check with UBL v2.0 Naming & Design Rules (NDR) shows:

    [ELD11] When a ccts:ASBIE is qualified, a new element MUST be
    declared and bound to the xsd:complexType of its associated ccts:ABIE.

What it didn't say is in which namespace that new element MUST be 
declared.  The natural interpretation would be to assume the namespace 
of the defining main document in which the ccts:ASBIE was declared.  
Going back to the SenderParty element used in ApplicationResponse main 
document shown above, this would have implied the need to  define 
doc:SenderParty element within ApplicationResponse, where doc has the 
namespace value of ApplicationResponse instead of CAC's namespace.

Another way to "resolve" the SenderParty issue is just to define 
SenderParty in Common Library spreadsheet as another ABIE with 1 ASBIE 
element that references PartyType.  This way, it would be consistent 
with the independence of Common Library model (independent of any 
existing or newer main documents).

So, my question is whether the above interpretation is proper?
If so, how do we explain the presence of cac:SenderParty element 
declaration in the present UBL v2.0 CAC schema (and not defined in 
CommonLibrary spreadsheet)?
If the above interpretation isn't correct, could you help in explaining 
what is happening?

Thanks much.


Chin Chee-Kai