[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl] Which namespace for global elements?
To evaluate the local vs. global elements question from another angle, I am updating my UML-to-XSD generator to support UBL design rules. This has raised a question about what design rule is used to determine which namespace and schema file should contain a global element declaration. I conclude that there is no rule for this, which results in inconsistencies and arbitrary assignment. If we retain the rule for using all global elements, then we need an additional rule about determining element declaration namespace. If local elements are used, then this problem goes away. For me, this presents another argument for changing to local elements. First, look at the end of two schemas from 0p70: UBL_Library_0p70_Invoice.xsd UBL_Library_0p70_Order.xsd Each contains several global element declarations. They *both* contain a global element for: PricingCurrencyCode These two elements with the same name are in fact different when qualified, because they are in different namespaces. Technically valid, but confusing. If you look at the end of the UBL_Library_0p70_Reusable.xsd schema file, there are many global element declarations, presumably because those elements were first used by complexType content in this schema. Now we end up with global elements like "IssueDate" that are part of this namespace with the "cat:" prefix. If we reorganize the modularity of schemas by reallocating some of these reusable complexTypes into the Order or Invoice schemas and respective namespaces (as was suggested by Bill Burcham), then some of these global element declarations would move to the Order or Invoice schemas. But, what if (like PricingCurrencyCode) some of these global element names are used by both Order and Invoice, but not by Reusable? They will require duplicate element names in different namespaces. This is very likely to occur with any modularity reallocation. We also end up with a confusing mix of global element namespaces in the content top-level business documents. An excerpt of the current Order schema looks like this: <xsd:schema targetNamespace="urn:oasis:names:tc:ubl:Order:1.0:0.70" xmlns:cat="urn:oasis:names:tc:ubl:CommonAggregateTypes:1.0:0.70" xmlns="urn:oasis:names:tc:ubl:Order:1.0:0.70" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:complexType name="OrderType" id="UBL100001"> <xsd:sequence> <xsd:element ref="cat:ID"/> <xsd:element ref="cat:IssueDate"/> <xsd:element ref="AcknowledgementResponseCode" id="UBL100004" minOccurs="0"/> <xsd:element ref="TransactionCurrencyCode" id="UBL100005" minOccurs="0"/> <xsd:element ref="PricingCurrencyCode" id="UBL100006" minOccurs="0"/> ... <xsd:element ref="TaxTotalAmount" id="UBL100011" minOccurs="0"/> <xsd:element ref="cat:LineExtensionTotalAmount" minOccurs="0"/> <xsd:element ref="TotalPackagesCountQuantity" id="UBL100013" minOccurs="0"/> Note the intermingling of global elements from the Order namespace (default prefix) and elements with the cat: namespace prefix from the Reusable schema. Technically valid, but a bit confusing. The UML class diagrams included in the 0p70 release were reverse engineered using the same toolset that I use to generate schemas from UML. I need a well-defined set of rules to enable round-trip design with bidirectional mapping between UML and XSD. This is easy with local element declarations, but the variety of namespaces for global element declarations as described above is difficult to support. Regards, Dave Carlson http://XMLmodeling.com
Powered by eList eXpress LLC