OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [ubl-ndrsc] MINUTES: Face to Face 5 Feb 2003

Here are the minutes from today's very lively discussion of Local vs. Global.  Please read through and be ready to start again tomorrow!  Only kidding! 
1. Roll call ** didn't get roll call complete **
       Bill Burcham - phone in
       Mavis Cournane
       Mark Crawford
       Fabrice Desr 
       Arofan Gregory  - phone in
       Michael Grimley - phone in
       Eduardo Gutentag
       Lisa Seaburg             
       Gunther Stuhec           
       Paul Thorpe
       Anne Hendry - phone in
       Danny Vint (observer, ACCORD)
       Dave Carlson (observer)
2. Current position summary
 Mavis: issues discussion procedure:
  - list issues
  - speak by invitation
Fabrice summarizes the case so far. In Burlington we agreed on Global. The main reasons behind Global was element reuse. Qualified elements were also easier to customize. The "Garden of Eden" define a CT and for each CT at least one global element and these global elements are then reused in the BIE.
For each complex type at least one global element.
Mavis: In 0p70 release what did they do?
Mixture - Gunther's algorithm is to first generate for each complex type an element and then wherever complex type is used generate element whose name is derived from the property type name.
Arofan: given that intent was reuse, maybe that's ok.
Bill: you can always make a new type
Eduardo: this is a tangent; should come back to global vs. local.
Mavis: Did we have to bodge our rules for 0p70 to get something usable?  Is there anything in 0p70 that we might have to revisit this.
Gunther presents slides (this was sent to list).  Over 1700 BIEs.  Strongly derived from ebXML CCs.  Example of 2 diff BIEs expressing same ABIE.  EG. global declared element 'ID'.  But then might need restrictions: "Dunns", etc.  So need to declare new global declared element.  Then must change all aggregate types which are using that global declared element.  e.g.. buyer address and seller address aggregate types; and manufacturer address and delivery address - also types. 4 BIEs, 4 separate types.  All reference element 'ID' (ref='id').
 manufacturer using a specific address (e.g.. Dunns), not this one.  What happens then?  Have to change all these. Impacts implementation, schemas, any interfaces or applications that are based on or using this aggregation.  A better way?
Fragment processing is uncomplicated etc.
B: we are defining the global element as an outcome of where the CT is used in a content model, if some of the ABIEs are never referenced we should never generate the element.
Bill: if I want to do a specialization of a ubl BIE type like id and define a new abie type that will use that bie type id.  How do I get a ubl document to carry that new type - can a local element that refs a global element declaration carry a specialization of that global?  [Ed note: see last few paras for Bill's test of this - it does work, is possible]
A: for each instance of use where the name is new we generate a new element. In the 0p70 release, they did a mixture.
G: algorithm is to first generate for each CT an element and wherever the CT is used generate a Global element whose name is derived from the property and we end up with spurious generated global element.
G: we made the decision based on short examples and we did not use all the CCTS rules and definitions. This works fine where you are defining a few elements only.
G: We (SAP) looked at the Boeing, EAN.UCC and we have over 1700 different unharmonized BIES and to harmonize them makes it very difficult using Global elements
All BIES based on the CCTS and we need to look at how we can use it for our definitions of our schemas. We have to use the DictionaryElementNames and how do we get short tag names.
One or more global elements are derived from an aggregate TYPE. A bunch of aggregate types have some elements and these refer to global declared elements. the global element will be reusable in the aggregate types. What happens if the same element expresses two different BIEs and they have two different characteristics. For example ID, EANID or DUNSID and we have to define a new global element with a specific name and then new complex types. This new global element will get a completely new name and this new global element impacts some already defined aggregate types. Because I need some restrictions for EANID I have a new ID tag and I have to change all aggregate types which are using that global declared elements.
B: is your concern while CCTs might be derived from one another there is no way to do that with elements. 
G: Manufacturer and Seller use specific IDs like EANID of type EANID.type with new characteristics and restrictions, you have to change all your refs into EANID. This impacts our interfaces and our applications i.e. everything that uses those aggregations.
G: all tag names must be unique we have 1700 BIEs we need unique tagnames. The ebXML CCTS dictionary entry names are unique and these are too long for our tag names.
A: It is not clear what a global element is it a BIE or a Core component.
G: Modifications of BIEs lead to change of type and tag names. Changing tag names requires additional effort. Our defined truncation rules cannot be used for global element tag names. Truncated tag names can have different semantic meanings.
B: any discussion predicated on global meaning we have to use long tag names is specious. Op70 has short tag names.

List of issues with Gunther's presentation
-What does it mean to "change" and the use of namespaces
-Impact on Instances with namespaces, long tag names and semantics
-Benefits of instance rules and impact on understanding and processing
-Complexity of schema, ebXML compliance, organization of namespaces in a library
-LCSC process, the need to always generate unique names
-Detailed exception handling
What does it mean to "change" and the use of namespaces
E: The departure point is the UBL library and schemas and those are changed by someone just by adding types and elements at will, with no modification of metadata in the schema itself. It all becomes just a modification of the original schema.
E: You can't just do that. For UBL compliance you have to add a new namespace in which you add a Type and an element but it is in that namespace. It is irrelevant if this is local or global.
B: If I want to do a specialization of some UBL BBIE type like ID and I want to define a new ABIE . How do I get UBL document to carry that new ABIE. If we took schema as it stands and try to do a specialization. Gunther's presentation makes me think there is no way with 0p70 to come in and do a specialization and have it carried in a UBL doc.
A: Import an existing type and extend it with my restriction. Everything using it in the schema must be declared in the new namespaces and be part of the extension. You have created a new doc type that can be processed excluding that one modified bit.
E: If we had local elements, would that be as extensive a modification?
A: There is no diff. Once you change a type you have to change everything between it and the doctype.
B: Under local element schema it is not necessary to do this much modification. You can specialize it at the point of where the specialization wants to be used.  You use xsi:type.
A: This dynamic remains true regardless if you use local or global
B: With global elements you won't have the option  to use XSI:type at the point of use.
A: XSI type is in the document
G: "change" at the design time of the library. How do you generate new tag names.
If we have 3 new global elements you have to put the object class on to the tag name itself the name is very long.
E: Gunther was talking about design of libraries and not customization.
E: In customization you would use different namespaces.
Impact on namespaces:
A: It is said we have 1700 unique elements, but that is untrue, because they are under different namespaces.  You assume that if you have several IDs, they are part of the reusabletypes, their specialization belongs to the new namespace of the document.
A: Example, product ID, restriction of the core ID, in that case disambiguating them with different names, is not true.  Don't buy that there are 1700 different elements.
G: The BIEs are collected from different organizations and can be in different namespaces. When we harmonize those into one library what happens.
E: You have to change names. There is no way to avoid huge clashes and issues if you try to harmonize
G: Enormous consequences, some names will be very long,others very short. Not very elegant.
B: Local names means you don't have 1700 things to resolve. You have to resolve the types and not every element of every type.
M: Does not mean you don't have to resolve the BIEs.
G: How can we use the same types of aggregation in the same way. Long tag names not very helpful. Interfaces are not readily shareable.
A: What is a type and a BIE. Is a BIE a semantic model to pin down one and only one definition.
M: CCTS calls for everyone of those to be a unique BIE and therefore unique complex type.
G: If you have a library with 1000 different BIES, then same number of complex types and global elements. How do you handle those global tag names efficiently in many different interfaces. For each dictionary entry name and defining the tag name.
A: Last release proved it was unnecessary to do that.
E: At some time using the local element method. Doubts were raised about it . We talked about global and we weighted this. Very unscientific but Eduardo was very conservative. However, resistant to going back to it. The main motive for global was the issue of reusability. At this point we can boil it down to reusability. Gunther is objecting that it does not make reusability easier.
A: Understanding of  large vocabulary, it is very easy if within each namespace each name means one set of semantics and one structure. We should use slightly longer tagnames where there are nuances of meaning.
G: We are defining alot of extra rules to handle this issue then.
A: CBL used one namespace and some fairly long tag names. You are trading difficulty in creating the library against the difficulty of using it.
B: IF people agree local would be nice if all our tools understood types and we were all using Xpath 2.0, then a short cut would be to make it incumbent upon the local party to show why this does not matter or demonstrate this can be handled with existing tools.
M: Mark does not agree. It violates a Universal Business Language in XML expressions.
B: what decision would we make if xpath and XSLT 2.0 were in place?
E: decisions shouldn't be based on technology that doesn't exist. but as soon as xpath 2 and XSLT 2 are ready they will explode in the market place.  how painful will it be in 2 years to switch decision?
A: also other things like versioning which will benefit, like with CBL, people stuck with a thing that worked best until they could switch - wasn't big deal. 
G: Yes, would not be big deal.
G: The automatic generation of these global elements, the developer is not interested in the tag names himself, he is interested in the dictionary entry name.  The fixed rules to output these, are more important.
A: I don't think having to fix clashes is as big a problem as the trade off of the locally defined names.  Example: When you have 4 things with different names but they are the same things.  At that point I should be able to go look at them in the schema and resolve the clashes then.
G:  At that point you have to write a tool to go look at this a second time, I am saying the BIE's are unique within the library locally, so I do not need any further tools to do any further work. 
A: It doesn't complicate all things, it does not impact users at all.  If we have to write more tools, I don't think that is so bad.
E: Either way tools are not relevant., I want to go back to the issue of reusability.  I also have an issue with customization.  about a half hour ago, I heard it said that local makes customization easier.  If we go local it impacts many more issues than just reusability.
B: We keep saying that a name is a sequence of names divided by slashes.  the principle is tree structuring our namespace.  XPath makes each name globally unique.  If we can agree that local has alot of good attributes...
G: If you are using local defined elements you still have the unique names.  Sometimes if you use global defined elements, using XPaths, the dictionary entry names...
A: We said that each construct would be uniquely named.
M: I need to clarify something.  There is no requirement to follow the tripartite naming.  There is no rule saying the name has to be tripartite in the CCTs.
G: ebXML CC in the future will be the standard.  This is the preferred
E; Lets try to resolve this.
M: Do we need to discuss how to reverse the last decision made.
E: Those that are meeting today and this week, should come up with a proposal.
A: What is necessary to reverse the decision.  Based on the criteria of usability and reusability.  What does it look like if you make these changes. 
M: Until I see instances documents, I will remain in the other camp.  I want to know what is wrong with the current approach and I want to see the new proposed approach.
B:  We need to keep processing logic as well (stylesheets) in this debate.
E: I want to see the issue of context modification included.
M: This needs to become a position paper.
A: This F2F should record the issues.

We have decided it is now time for the parties who would like to reverse the decision to concretely demonstrate the problem encountered with concrete examples that would effect whatever we have at this point.
Meeting adjourned: 18:35 GMT

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.441 / Virus Database: 247 - Release Date: 1/9/2003

Attachment: Lisa Seaburg.vcf
Description: text/vcard

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC