[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-ndrsc] UBL NDR SC Minutes PM 28 April 2003
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]