[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