RE: [ubl-lcsc] Global versus Local

["CRAWFORD, Mark" <MCRAWFORD@lmi.org>]

Title: Global versus Local

:

• 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.
  [CRAWFORD, Mark] I don't see 1 as being compliant with the NDR.  We talked about this in Burlington and Menlo Park.  I don't see a problem with 2 as this is what we are supposed to be about and I have been arguing for from the very beginning.  Remember, we all agreed that UBL was providing a business vocabulary.  That means fully qualified dictionary entry names for all of our content.  We developed our truncation rule only after a great deal of discussion, and only after it was determined that we would retain semantic clarity.  We also discussed global vs. local at great length, and arrived at a near unanimous agreement.  I think we should retain both.  If we have to give up something, the first to go should be the truncation capability as it is the least valuable to human (read that SME) use.  I would suggest however that a logical rule can quite possibly be developed that would retain full semantic clarity in conjunction with global declarations.    I would suggest that the rule should be [xx] Element names MUST not be truncated in accordance with rule xx, if such truncation creates duplicate element names within the schema with different semantic meanings.  in other words -
•     The element PaymentTermsDetails can be declared as PaymentTerms as long as it is the only BIE with an Object Class of Payment and Property Term of Terms.  The element PaymentTermsDetails can not be declared as PaymentTerms If the element PaymentTermsText also occurs.

        This should be a simple add to the script

•  
• 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?
  [CRAWFORD, Mark] see previous proposal.
• 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.
  [CRAWFORD, Mark] I don't think I understand this.  We never represent CCs in an instance document.  If we want to be fully compliant, then lets forget completely about truncating names and simply use the BIE name as the tag. 
• 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.
  [CRAWFORD, Mark] Whets wrong with that? 
• 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. [CRAWFORD, Mark] Sorry, this is not a valid argument.  I could as easily say that some users have mandated the use of all global (i.e. U.S. government) and will not use any standard that supports use of local. 
  
  [CRAWFORD, Mark] In my opinion, we should never loose sight of the fact that the spreadsheet is simply a convenience for doing our work, and will not have a life after we deliver our products.  The real value is in the schemas and in the library components.  None of the aforementioned arguments in my mind justify reversing our decision on global.