UBL NDR SC Minutes PM 28 April 2003

["Mavis Cournane" <mavis.cournane@cognitran.com>]

Dear all
please find attached a copy of today's afternoon minutes. The topic of
discussion was Local vs Global.
For those of you from the NDR committee not with us in rainy, grey London -
the Donkey was flogged to death and reincarnated for more of the same on
Wednesday. We miss you guys!

Mavis
------------------------------------------------
Present: Mavis Cournane, Eduardo Gutentag, Gunther Stuhec, Stig Korsgaard,
Mark Crawford, Michael Grimley, Lisa Seaburg. (All UBL)
Sung Hyuk Kim, Thomsa Bikeev, Hisano Sugamata, Luc Mouchot, Bernd Boesler
(ATG2 representatives)

Items for Discussion

1. Discussion of week's schedule
2. Local vs Global

LS: Since the last F2F nothing has moved or changed in the NDR document. We
need to come up with a list of issues, divide up the work and get it done.
Local vs Global has taken alot of our energies and will be a large part of
our debate and discussions.

EG: Discussions are entrenched and we will not arrive at a decision
ourselves. We should send it to the UBL list and vote on it.

LS: Arofan Gregory said that he had a few more questions and might change
his vote.

LS: We do not have quorum but we could have a straw poll.

EG: Since this is such a critical issue, therefore it merits being done over
emial.

MC: One of the reasons we have ATG here is to enter in to a detailed
discussion on this issue. They have very strong ideas on this subject.

EG: Who is ATG here. Gunther Stuhec, Mark Crawford, Lisa Seaburg, Stig
Korsgaard and Arofan Gregory are members of UBL and of ATG.
The purpose of a straw poll is an idea on how the positions are divided.

MC: Let's take a straw poll. 4 for local, 9 for global.

EG: Lisa should lead the discussions.

LS: We have two hours today, Wed pm 12-17:00. Eve will call in from 12-2 on
Wed to discuss it. In total we have 7 hours of discussion time.

MC: We have put together a list of pros and cons from the October F2F. ATG
have a list of pros and cons from their March F2F. As a first step we should
review those to refresh our minds and give Gunther an opportunity to talk
about his paper to set the stage for his discussions. We could recast on Wed
combining the pros and cons from the two groups and Gunther's paper.

LS: Our initial position was local.
EG: Correct, we revised our decision to Global at the Burlington F2F.

LS: Let's look at the F2F minutes 1-4 October 2002 UBL NDR SC Meeting. In
these minutes we said

This is a first cut of our analysis of positives and negatives:

Local element characteristics:
+ Vocabulary can have multiple elements with same name

Global element characteristics:
+ Fragment processing is uncomplicated
+ Can be reused directly
- All elements must have unique names

Qualified element characteristics:
+ Customizers can safely define unqualified elements
. Instances can look clean with defaulting

Unqualified element characteristics:
+ *Very* clean, simple instances
- Customizers can't safely define unqualified elements
- Unusual design choice; in most vocabularies all elems are qualified
[Excerpt taken from the Minutes]

EG: Back at the F2F in October we saw local elements have one thing that is
positive i.e. a vocabulary can have multiple elements with the same name. A
global element con is that they must have unique names within the unique
namespace.

GS: What did we mean by fragment processing?
EG: When you have to take something from an instance to put in another
instance or something from a schema into another schema

EG: For local "Types are required to be re-bound to foreign elements in
attempts to reuse individual components of the UBL Library" was another
point.
GS: I don't see this as a very negative issue for local.

EG: for global " Going forward, there is a cost to ensuring that each new
element name is unique." I don't really buy that.
MC: I do, I think this cost is worth bearing.

GS: I see alot of naming collisions if we use global. This is not a tool or
perl script issue. It is more generic. The best example is identifier. The
global declared element is ID. You have many different identifiers with
specific restrictions. Sometimes you have to restrict identifier which is
problematic for globally declared elements. The names of the globally
declared elements will be very long. From my analysis some databases can't
handle these long names. Also for truncation rules they are difficult to
write for these long element names. I often truncate object classes. You
have globally declared elements that can conflict with other ones. You need
an awful lot of exception rules to restrict successfully.

MC: Let's now look at the ATG Minutes to see the pros and cons identified.

Venetian Blind - Global Types, Local Elements, May be qualified

Pros
a. Binding reflects OO serialization (.Net, JAVA)
b. Supports type reuse
c. well accepted
d. makes for short tag names
Cons
a. Does not support element reuse (even if namespace qualified) except
indirectly through binding the whole type in which it is declared to an
element in the outer schema reuse
b. Allows for the same element to be bound to multiple types
c. Allows the same element name to be used for multiple semantically
non-equivalent elements
d. Requres type aware processor to be able to conclude the semantic
equivalence of two elements
e. Makes reuse of XPath based logic difficult (XSLT and content based logic)
Garden of Eden - Global Elements, Globally Declared Types, FullyQualified
Pros
a. Instance document is semantically unambiguous
b. An element in the instance points to the type
c. Elements and types are reusable
d. Does not require type aware processors
e. Makes reuse of XPath based logic easy
f. Supports building TBG required library
g. Makes mapping between EDIFACT and XML possible at the element level
Cons
a. Not well known
b. Makes for long tag names
c. Increases file size
d. Does not directly support OO serialization
e. Does not support long term direction of IT
f. The ability to extend using both type and element can create
standardization issues
g. Creates many more tag names than venetian blind (some estimates are in
the hundreds of thousands)

Much discussion on merits/drawbacks of each.  Mark had mini meeting with
TBG1 and laid out pros and cons of both.  Consensus of TBG1 was:

¨ Global elements are preferred over local
¨ Semantic clarity in the instance document without reliance on tools such
as XPath is a requirement
¨ The tag names should be harmonized with the CCTS naming conventions
¨ ATG should be delivering a semantically unambiguous glossary of tags

[Excerpt taken from ATG Minutes]

GS: I will now show my paper. See draft-stuhec-globVloc-02.doc. It shows
more pros for the Venetian Blind approach rather than the Garden of Eden.
One of my main points is inconsistency of tag names for global elements.
MC: How is that a global element issue.
Is that a library inconsistency?
GS: No it is as a consequence of using globally declared elements.
EG: I don't see the relationship.
Here you try to design a system with several parts. If you want it to
function in the longterm without breakage you would define interfaces and
you would not want to integrate other people stuffs.  The LCSC defines tag
names which interferes with your architecture as they have to be globally
unique within the namespace. Gunther's example is where they are
inconsistent in their work.
MC: Exactly this is a result of inconsistency within LCSC.
TB: In system design I am responsible for my part. The system you have is
very inter-dependent.
EG: How does this problem step from local vs global.
GS: If we want to have consistency where you define only one address to be
used in the same way. What happens if the address of the organization is
different to the party.
MC: If you have in place a very rigid harmonization and approval process
whose primary responsible is to ensure all the name issues have been
resolved in a consistent manner do you still have an issue?
GS: The problem is for example sometimes you qualify a specific structure of
an ABIE e.g. BuyerContactType and SellerContactType. Sometimes you use
Address which is very generic, and another time you are using very qualified
and specific names. WE have seen if you are defining very specific,
qualified names that makes the schemas huge with lots of redundancy.
SK: Something I don't understand. I agree that there is a role for
harmonization and for that to take out inconsistency. I do know mark you
raised issues of inconsistency.
MC: This is a different one.
TB: Here you have one thing which is a question of policy that is dependent
on people obeying rules. Another question is about a highly inter-dependent
system. Agreed there will be harmonization. I am questioning this policy
thing. What happens in our organizations is that the XML guys get hit by all
the inconsistencies done upstream.
EG: I still cannot see in what manner having local elements would prevent
you from having inconsistencies.
MC: What I hear you saying is that there is inconsistency in the application
of CCTS rules.
GS: I am saying that local elements would prevent inconsistencies.
TB: Venetian Blind would hide all of the inconsistencies and would be very
forgiving, however it would not improve anything.
GS: No it would positively impact it e.g. BuyerPartyAddressType,
SellerPartyAddressType. Defining a new aggregation BuyerParty, you will have
for all the same aggregations the same names. If you wanted to define
Address within BuyerPartyType you can truncate Address because it is locally
defined and refers to BuyerPartyAddressType. The advantage is that you will
always have the same tag names in it.
EG: But they are from totally different types. For me that is a problem. If
you look at it when you are reading the instances it can be very confusing
because you have BuyerPartyTypeAddress and SellerPartyTypeAddress and hidden
behind is the fact that they are different structures.
TB: Does that matter for the machine.
EG: No but the purpose of XML is that it is human readable.
TB: Being able to parse and validate via the type is very elegant.
GS: Truncation is very easy with locally declared elements. One of my
customers wants to exchange 20m messages daily.
EG: Use ASN1 then.
GS: We don't want to do this.
MC: If someone wants to do 20m transactions why not use EDI?
GS: WE are talking about how we can use XML directly in our systems without
mappings. One of the biggest disadvantages of EDI is mappings.
EG: This is a different type of mapping.
LS: Let's summarize what was discussed so far:

Problems with Global
- Inconsistency of tag names
- Difficult truncation rules
- Long names

Positives for Global
- Reuse elements and stylesheets

Problems with Local
- Tools must be type aware, stylesheet reuse.
- Elements cannot be reused, only types.
- no harmonization is done for local elements as there is nothing to
harmonize.

Positives for Local
- Easier to generate tag names.

EG: There are many attractive things about local but this was trumped by
issues of reusability and it would take a very strong argument to convince
me to go back.
LS: You would only register your Types if you go local not your elements.
GS: You can search the registry for types.
MC: But let's say you used a different set of elements for types I have some
real problems because they are not registered so you won't get type reuse as
well.
GS: That is not right.
It is not necessary to harmonize the elements.
MC: So TBG 17 (harmonization is no longer required
How can you tell someone you used the wrong set of local elements.
GS: These can be generated automatically from the dictionary entry names. It
is not necessary to look at the locally declared elements just the
dictionary entry names.
MC: In the instance document? I can have 12 different elements called Name
with a different meaning. We never agreed that our work documents were only
focused on machine processable. They must be human readable as per our
original goals.
GS: They are human readable.
MC: You have yet to give me a technical reason why our accepted solution
won't work.
TB: It is not about working or nor working.
MC: That was our reason for review. We took a formal decisions.
MHC: Yes he said it could not be implemented.
MC: We have heard lots of "preferred" but I don't see what is not
implementable.
GS: I talked to Dave Carlson about these ones. The biggest problem is the
implementation itself. One of them it does not align to the OO approach. You
are defining some Types and some Objects may be based on those types. That
is exactly what you are doing in locally defined elements i.e. defining
types only and using objects based on those specific types. What we are
doing in the Garden of Eden approach is defining elements additionally. It
is very hard to do this implementation. Maintenance would have to be done
twice. If you define global defined elements you have do maintenance on them
and on the type. If you would like to express this in different interfaces
in different applications it becomes very difficult. There is no way to
represent globally declared elements in Databases you need pseudo-classes as
global. This means
MC: Why do I need to represent globally declared elements in DBs.
GS: If we would like to reuse across applications.
TB: Type based schema and instance based tag names are reused which is very
high maintenance. People could parse against the instances or the schema. As
a standard you would probably prefer to give people one option only.
EG: We are only concerned here with schemas.
We are counting on UBL conformant tools and to be UBL conformant these tools
will have to do certain things in a conformant way.
TB: If I am an implementer, you can use any parser but you will need some
applications to apply business logic to the document. there are two ways to
parse the message in two different ways. You can parse it in the current
XPATH way i.e. tag based or you can parse it schema based. The way to do it
is ambiguous.
GS: I have an example See "Generating ABAP-Objects for SAP development
environment" in draft-stuhec-globVloc-02.doc.
MC: Is this a production system.
GS: Yes.  If you need some additional elements you must define pseudo
classes that refer to a datatype.
MC: If I understand, your argument is there is no way to handle global
elements in the database.
GS: Not just in our SAP DB. I have done a rationale Rose experiment also and
you need to define pseudo classes also.
If you generate SAX interface you will always see these pseudo classes and
the developer will not know what their purpose is.
Additionally, I experimented with Tamino and encountered the same issues.
MC: You have stored the Types with all of the elements defined within them
so what is the problem.
GS: In the database table for example, what happens if the ID of buyer has
different characteristics to shipping ID. You need 2 different elements.
Tamino DB handles this as follows: If you use local declared elements it
puts all the information in to one column but if you define globally the
Tamino DB defines an additional row, one is called ShippingID and BuyerID
automatically. This means you have different rows so you have to put the
information in to two different rows.
EG: How is this a problem.
GS: This is not the normal way for DBs. You need some manual maintenance you
have to group the information manually. You then get in to manual
extensions.
I am trying to always use the same model in each case. The biggest advantage
of XML is that you can use the same model in different applications without
transformation/conversions. You can develop your model structure in one
environment and port it to another which is very attractive to us.
BB: You don't have a separating tier.

LM:For me Class is a Type, the Attribute is an element and we want to
harmonize the types. It is not necessary to harmonize the attribute.
GS: I am saying that I would like to harmonize the elements.
LM: If the class is harmonized then so is the attribute.
GS: The characteristics are described on different classes/types. If you
define a new characteristic you define a new type.

Summary of above implementation issues.
Gunther experimented with Tamino from Software AG (native XML), SAP system
(not native XML compliant), J2EE environment 1.3, Rational Rose and perl
developed environment. The results he put forward were:
- pseudo classes had to be used for declared elements in every application
- additional maintenance has to be done to merge pseudo classes if they
express the same information

Tomorrow
We start with the Common Core Component Types. We will present it and it
won't take all morning. This will be led by Gunther. See
draft-stuhec-ccc-09.doc.
-----------------------------------------------
Mavis Cournane
Cognitran Ltd.
Co-chair UBL NDR SC