Re: [ubl-ndrsc] UBL NDR SC Minutes PM 28 April 2003

["Eve L. Maler" <eve.maler@sun.com>]

Hi folks-- I'm trying to keep up with all your progress (and failing), 
but look forward to calling in tomorrow.

I note below that Gunther mentioned the problem with the many different 
IDs with different restrictions all needing to have a different element 
name with global.  As I proposed several weeks ago and in my Word 
comments on his local vs. global paper, perhaps a hybrid solution is the 
way to go: global in general, but local for selected leaf-node elements 
where this situation obtains.  Perhaps ID and Code are the only good 
candidates, or perhaps there are others.

I hope you will have a chance to go over those Word comments from 
several weeks ago, either with me present or not.  I have a feeling that 
they might impact any name truncation discussions, as well as local vs. 
global.

Talk to you all soon!

	Eve

Mavis Cournane wrote:
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com