[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] UBLish v2.0: Problems found with QDT & CAC
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]