[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Global vs. Local -- Gunther's Recommendation
----- Original Message ----- From: "CRAWFORD, Mark" <MCRAWFORD@lmi.org> To: <ubl@lists.oasis-open.org> Sent: Monday, March 17, 2003 9:36 AM Subject: RE: [ubl] Global vs. Local -- Gunther's Recommendation Dave C. wrote - > The most difficult problem is with mapping (in UML) a global > element to the namespace in which it is declared. The global element may be > declared in a different schema module, and possibly a different XML > namespace, than the complexType or simpleType on which it is based. Some XML > Schemas (e.g. ACORD) use one very large schema file in one namespace; global > elements are quite straightforward here. Other schemas (e.g. OAGIS 8.0 and 8.1) > use a very large number of schema modules to support reuse and abstraction, > which greatly complicates mapping global elements to schema modules and > namespaces. UML has not yet settled on a rule for determining schema document > modularity and their namespace assignment. Mark C. wrote - > But if we are consistent across schema modules on a unique one-to-one association > of an element to a type, then this does not appear to be a problem. But that's the problem: this is NOT the case. It may be true for ABIEs like PartyType, but there are *many* global elements declared for each complexType definition such as CodeType or DateType. For example, the global elements declared in the 0p70 Invoice schema: <xsd:element name="InvoiceCurrencyCode" type="cct:CodeType"/> <xsd:element name="LineitemCountQuantity" type="cct:QuantityType"/> <xsd:element name="PricingCurrencyCode" type="cct:CodeType"/> <xsd:element name="TaxCurrencyCode" type="cct:CodeType"/> <xsd:element name="TaxPointDate" type="cct:DateType"/> Similarly, it seems likely that there will be many global elements declared for the same complexType in cases like AddressType (right now, I think we have a problem in 0p70 schemas with exact duplicates of the same AddressType and PartyType content with different complexType names; this issue is already in the feedback spreadsheet). Dave C. wrote - > My interest in NDR recommendations is more general than UBL. > I'm looking for a set of industry best practices. I am still testing > alternative approaches to support global element mapping to UML and expect to find a > workable solution, but use of local elements (or restricted use of global > elements in some situations) simplifies the mapping and will reduce long-term > maintenance of UML models used for system integration. Mark C. wrote - > So I read this to mean that local makes it easier, but global works. Given the > benefits of a single, semantically unambiguous universal business language, global still seems the way to go. Use of local elements does NOT prohibit consistent use of a semantically unambiguous business language. I see the unambiguious business language semantics defined primarily by the type definitions, which are the same for both local and global element declarations. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]