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

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Hi Chee-Kai.  I think I can help with all your questions.  I will 
preserve all of your original post so that a reader of the archive 
doesn't have to go back and forth.

At 2008-09-16 13:40 +0800, Chin Chee-Kai wrote:
>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.

Yes, I am expecting that if a creator of a new document type finds 
everything they need in the CAC that they can reuse the published CAC.

>--> 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.

Well, it does use <xsd:import> to bring in the CBC module in order to 
satisfy references to BBIE definitions.  The BBIE elements are in a 
different namespace than the ABIE elements.

>--> 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>

It would have to be <xsd:import> because the CAC schema defines 
components in a different namespace than the document schema.

>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),

Both of the above do not change the common library.

>    * 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),

That would break the NDR since the *only* ABIE in the document 
namespace is the document element.  For conformant customization all 
other ABIEs are only the existing ones in the CAC namespace.  For 
compatible customization the rules do not apply so I suppose you 
could invent new ABIEs and put them in the document 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?

I suppose so, but I don't think you can augment the CAC module to 
include your own constructs since the committee might come up with 
their own definition in a future 2.x of a construct with the name you 
chose.  If you submitted a user requirement to the committee for your 
MyPartyType to be added to the common library, this could be 
considered, but I'm not aware of any requests for library components 
that aren't being used in UBL committee main documents.

You have to use your own namespace for compatible extensions.  And a 
<MyParty> is a compatible extension since there is no <MyParty> in UBL.

>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.

Yes, the committee has license to do this for 2.x.  Creators of 
compatible extensions do not have such a license.

>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.

"Less stable"?  I'm not sure about that.  All committee additions to 
the CAC and CBC schemas to support 2.x will be done with new ABIEs 
and optional constructs added to existing ABIEs.  Therefore, existing 
users of 2.y instances can continue to validate them with future 2.x 
schemas (where y is less than x).  I think that is very stable.  We 
are ensuring all changes to UBL support this backward compatibility.

>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

True ... it doesn't need to be in the common spreadsheet.  The 
document spreadsheet declares in column M "Associated Object Class" 
is based solely on PartyType so SenderParty doesn't need to be an 
ABIE.  Since SenderParty doesn't need to be an ABIE, there doesn't 
need to be a new ABIE definition in the common spreadsheet.  It is 
sufficient to be defined as an ASBIE of PartyType.

Now, that it is in a document schema as an ASBIE generates in the CAC 
schema a declaration of the SenderParty element ... line 264 of 
UBL-CommonAggregateComponents-2.0.xsd ... and it is defined to be an 
instance of PartyType.  This is consistent with the information found 
in the document spreadsheet column M.  There is nothing needed in the 
common spreadsheet to support that the document spreadsheet 
SupplierParty ASBIE is using the existing Party ABIE in the common 
spreadsheet.  And there is nothing needed in the common spreadsheet 
for another document spreadsheet to define its own SupplierParty 
ASBIE to use the existing Party ABIE.  Of course, because all element 
definitions are global, another document spreadsheet cannot define a 
SupplierParty ASBIE to be anything different than the existing Party ABIE.

>   2. (So) CAC schema generated by UBLish v2.0 (naturally) gives no
>      definition of type cac:SenderPartyType nor element cac:SenderParty

Yes, there is no definition of cac:SenderPartyType, because there is 
no SenderParty ABIE, only the SenderParty ASBIE.  Thus, I see in CAC 
the declaration of the element cac:SenderParty to be defined as 
cac:PartyType.  No SenderPartyType is needed because there is no 
SenderParty ABIE.

>   3. (But) UBL v2.0's CAC schema contains a cac:SenderParty element
>      with (cac:)PartyType.

Yes, as cited above.  It properly uses PartyType because the 
associated object class is Party, thus indicating that Party doesn't 
need to be specialized in another ABIE to satisfy the needs for SenderParty.

>   4. SenderParty is referenced as an ASBIE in ApplicationResponse
>      spreadsheet.

Yes.  Though I would have said "SenderParty is defined as an ASBIE in 
the ApplicationResponse spreadsheet".

>   5. ApplicationResponse's schema references <cac:SenderParty>, but
>      does not define, leaving definition to CAC.

No, it leaves the "declaration" to the CAC module because all ASBIEs 
are in the CAC namespace.  The definition, found in the document 
spreadsheet, is that the SenderParty ASBIE is satisfied completely by 
the Party ABIE.

>This possibly
>      explains the presence of <xsd:element 
> name="SenderParty"      type="PartyType"> in UBL v2.0's CAC schema.

Yes, it has to be in the CAC schema because the CAC schema declares 
all elements in the CAC namespace.

>However, this  declaration cannot be  traced to any part of 
>CommonLibrary spreadsheet, which is the source modeling document for CAC.

Well, I don't think that is true.  The CAC declares *all* ASBIEs and 
ABIEs because it is the home of the definition of all 
aggregates.  The CBC declares all BBIEs.  Since there are *two* 
sources for aggregates (the common spreadsheet and the document 
spreadsheets), the common spreadsheet is not the sole 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 the modeling practice used in defining UBL says that if a new 
ASBIE doesn't need to specialize an existing ABIE it is obliged to 
use the existing ABIE as the associated object class.  If it isn't 
different, then it doesn't need to be defined in the common 
spreadsheet.  And, since the definition of the SenderParty is 
PartyType, and PartyType is already in the common spreadsheet, there 
is no need to add anything in the common spreadsheet to allow other 
documents to reuse PartyType as SenderParty in those other documents.

>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.

Not if you follow my reasoning above that there are multiple sources 
of definitions of CAC components and one home (because of the 
namespace) for declarations of CAC components.

>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.

I don't see that as "expected" because of the modeling rules.  Now, 
if the committee SenderParty specialized Party then I totally agree 
with you.  We would be obliged to add a new ABIE SenderParty to the 
common library, and we would make Party a child of SenderParty to 
take advantage of the current definition, and then we would add other 
BBIEs and ASBIEs to SenderParty to make it different than Party, and 
then other documents could reuse the definition of SenderParty by 
specifying SenderParty to be the AssociatedObjectClass.

For an example of just this, CustomerParty is such a specialization 
of Party thus has its own CustomerPartyType and has to be defined in 
the common library.  In turn, ContractorCustomerParty is defined to 
be an instance of CustomerParty without specialization so there is no 
need to define a new ContractorCustomerPartyType.  If any other ABIE 
needed a ContractorCustomerParty then it, too, would just use 
CustomerParty since there is no need for specialization.  No other 
ABIE needing a ConstractorCustomerParty could define it any 
differently since all element types are global ... if it were 
different then it would need to use a different name.

>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.

All aggregates (except the 31 document aggregates) are in the CAC 
namespace (ref: [SSM9]) and all atomic values are in the CBC 
namespace (ref: [SSM11]).  This is implied by the rules stating that 
each are all in their respective schema modules, and all items in a 
schema module are in the same namespace.

>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.

I disagree because SenderParty is not a specialization of Party, it 
is just using the existing Party.  Because elements are global, now 
any document schema wanting a SenderParty defined as Party can use 
it.  If it needs something other than Party then it cannot be named 
SenderParty and must be qualified differently.

>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).

But it would introduce a redundant element layer in an instance by 
wrapping a one-element child with a mandatory parent.

   <SenderParty>
     <Party>
       ....
     </Party>
   </SenderParty>

I wouldn't support this.

>So, my question is whether the above interpretation is proper?

I hope that my interpretation above helps with your interpretation.

>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)?

Because of [SSM9].

>If the above interpretation isn't correct, could you help in 
>explaining what is happening?

I hope I have helped, Chee-Kai.

. . . . . . . . . . . Ken

>Thanks much.
>
>
>Chin Chee-Kai


--
Upcoming XSLT/XSL-FO hands-on courses:      Wellington, NZ 2009-01
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal