ubl-ndrsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [ubl-ndrsc] Global versus Local
- From: "Stuhec, Gunther" <gunther.stuhec@sap.com>
- To: "UBL-NDRSC (ubl-ndrsc@lists.oasis-open.org)"<ubl-ndrsc@lists.oasis-open.org>, "UBL-LCSC (ubl-lcsc@lists.oasis-open.org)"<ubl-lcsc@lists.oasis-open.org>
- Date: Thu, 16 Jan 2003 18:21:46 +0100
Title: Global versus Local
Hello all,
here I have generated an xml-schema with declared global elements now. Tim modified this schema a little bit. You'll find Tim's package as a zipped attachment with the file name: UBL_LCSC_2002_01_16_Tim.zip.
<<UBL_LCSC_2002_01_16_Tim.zip>>
Since I have a reasonable perl-script for generating xml-schema output from the different kinds of excel spreadsheets, I'm testing the different possibilities for the representation of xml-schemas. Therefore, for me it was very easily possbile to see the advantages and disadvantages of the declaration of global elements or local elements which are based on complex types. I mentioned these problems since our Burlington meeting last year and a gave some reminders about difficulties of global elements in a couple of mails. I know, that we made a decision using the declaration of global elements only. But at this time, we hadn't the idea how this decision impacts very huge and complex xml-schema structures. I guess, these outputs question our decisions.
Our main criterias for using global elements are the direct usage of elements as the typical design choice. See our discussion in http://lists.oasis-open.org/archives/ubl-ndrsc/200210/msg00003.html. But I have seen that the using of global elements do have much more disadvantages, which might be k.o. criterias. I know, that we will distribute our packages at the beginning of next week. But I think, it is very important to discuss about the global versus local issue, again. For this discussion I collected all known disadvantages of using global elements:
- Fixed element names - All element tag names are fixed. That means that we have two possibilites: 1.) We're declaring global elements with very generic and short tag names (like in the attached example). By that way, we will have one global element for many BIEs with different semantic meanings. This will be not the right way, because every BIE can have different characteristics and definitions. 2.) Otherwise, we're generating unique tag names according the dictionary entry names. That means that we will have huge tag names (exp. DespatchedTransportHandlingUnitTypeCode). Or we need a logical rule for generating shorter names.
- Logical rules for tag names missing - I said it before. We need a logical rule for generating shorter tag names. But this is very hard to do that, because we don't know, which kind of term we can eliminate from each tag name. I thought, we defined the rule for representation of tag-names of child elements. It says that, if the the object class of the aggregation and the child BIE is the same, than we can delete the object class from that BIE. That is very easy and understandable and furthermore, it is automatically processable. Furthermore, we defined some rules for deleting the words: "Details" and "Text". By this, you'll get sometime the same tag names (exp. PaymentTermsDetails and PaymentTermsText). What do you do with that elements?
- It is not really compliant with ebXML CCTS - If you using local elements, it will be very easy to distinguish between CCs and BIEs. All complex types representing a ACC or BCC and can be used as ASBIE or BBIE within an ABIE. The ACCs or BCCs do not have any qualifiers, but the ASBIEs or BBIEs can have. If you using local elements, which are based on a complex type, you can named this BIE according the conventions of ebXML CCTS. Furthermore, the BIEs should be not reusable any more, like the local element within an aggregation.
- All namespaces will be in the tag-names, too - If the global element prefixed by a namespace, you'll see the prefix in the xml-instance, too.
- The global elements will be not implemented in some interfaces as well as software components - Some software vendors have seen that local elements which based on complex types will have much more advantages in reusability, short tag-names, modularity etc. These software vendors are concentrating into this direction and do not plan implementing any feature for handling global elements.
I generated xml-schema output, which every CC (ACC and BCC) representing on complex type. And all local elements are BIEs (BBIEs or ASBIEs) with short tag names. And this BIEs based on the complex types. You'll find this example as a second attachment. I guess this representation is highly reusable, although.
<<UBL_LCSC_2002_01_16.zip>>
Kind regards,
Gunther
Attachment:
UBL_LCSC_2002_01_16_Tim.zip
Description: Binary data
Attachment:
UBL_LCSC_2002_01_16.zip
Description: Binary data
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC