UBL TC Face to Face

When:  Apr 29, 2003
Associated with  UBL Naming and Design Rules SC
Description:

==========
Agenda:

==========
Minutes: 1. UBL Context Methodology Overview 2. Code Lists 3. Namespace versioning (deferred) 4. Embedded documentation (deferred) Present: Eduardo Gutentag, Sue Probert, Mike Grimley, Gunther Stuhec, Mike Adcock, Garret Minakawa, Sunho Kim, Sung Hyuk Kim, Arofan Gregory, Hisano Sugamata, Mark Crawford, Matt Gertner, Lisa Seaburg, Mavis Cournane 1. UBL Context Methodology Overview - Eduardo Gutentag EG: We are on the fourth iteration of the guidelines and we received lots of very good feedback. Dan Vint you are not telling me how to do it and you are telling me not to use redefine which is being used in Acord. Dan explained the Acord process which uses an adaptor schema. See the NDR list for further details. Dans Proposal is as follows: You have the UBL schema and you can include it into another file where you can redefine elements using XSD extensions and restrictions. This extension is as per the CM guidelines. For all intents and purposes this is a method whereby you can implement the guidelines. From that point of view this is very attractive as it proposes a management method as well. When you redefine you are not parallel defining you are actually redefining and the only thing you can use is the new redefined element. There is one issue that many people will see as a problem. I am personally not sure it is but it is the fact that you are redefining the element but you are not changing its namespace. MA: An observation is that we have a payment system in the UK running for 35years. THis has been redefined several times. Redefinition is too easy and documentation does not exist for it. This is the same circumstances. THis is redefined and you have no way of identifying in the record which definition it is. EG: The difference in this case is that documentation is mandated for redefinition. MA: This is redefining the technical solution to a business requirement and I thought we were having business requirements on top of the technical solution. EG: The business requirement in this particular case is the context. MG: Conceptually I don't like it, as an XML geek it seems wrong and it could get messy. On a pragmatic level I don't see how these problems are going to manifest themselves. When and if we ever automate CM application this problem goes away. EG: I think that the redefine is easier to automate. Having a schema where you have the Address element defined 5 times and having it in 5 separate namespaces, being able to use any of those 5 and not being sure of which you should use, that is messy. The more I think about it the more I like Dan's solution, however, I am conscious of the fact that people will take issue with the fact that the redefined element does not have a separate namespace. We might add some attribute to the root to try and solve this. MG: I would be inclined to favour the redefined personally. MC: THe risks associated with redefine from "Definitive XML Schema" - Duplicate attributes. EG- It would not parse anyway. - Adding element declarations to the content model that render it non-deterministic EG/MG I don't understand that. MG: Have Acord released this to the wider world. EG: I don't know - Acord is a controlled environment. And our situation would not be a controlled one. The only way to do this legally from the UBL point of view (i.e. an XSD extension) is to document it and to document the context. The reason I wanted to talk about it now is so that people think about it. WE won't decide it now but maybe on Thurs. MG: The more I think about it the queasier I am about the whole redefine thing. It would not be a big deal to provide people with a tool for doing it. EG: Somebody has to write, test, and maintain the tool. Our tools and techniques committee is only one person. I don't see who can do it on time. MG: Let me think about what it would take. I am not volunteering. EG: THis is why we are talking about just guidelines at this point. MG: I think it is conceptually wrong and it is impure from an object oriented perspective. You could run in to trouble if you were generating java classes from derived schemas. Tools that do stuff with schemas is not going to know what to do with this. I am against it. EG: The part I like about it is the element of manageability that it gives you which the other approach doesn't. Perhaps we can come up with another way of doing it that has include/import types of things that gives you manageability without the overhead of redefine. EG: We should think about whether having Global types but not global elements would solve some of the problems of the chaos created by having to go up the chain every time you change an element. MG: I don't see why. EG: I am not sure. 2. Code lists - Lisa Seaburg LS: I have put the document up on the site. See the NDR portal and v03 of the paper. This goes through the way UBL is to be used using codelists. Starting at section 2: GS: I have a problem with the example , if we use this in our example everyone will use it and it is not the real one. LS: Let's go through Eve's comments. [ELM1] EG: I think it is right that it is doomed from the start. GS: How do you differentiate code lists in the instance. EG: YOu have to look at the schema. GS: You will not see any supplementary component in the instance. If you have a choice between 2 or more codelists for the same code e.g. Country Code. You can't see that in the instance. MHC: Yes, you have to go to the schema, unless you put the name in to the tagname which doesn't follow our naming conventions. GS: You have 3 codelist and each list there will be an enumeration. There is an attribute to store each version of the code list. Each version has the same name e.g CountryCode v1, CountryCode v2 etc. How can you use of these versions within your business document and within your XML instance. Right now Eve has a structure Is it efficient to put all the characteristics of the code list in the tag name. No it is not efficient and it is not processable. In our environment there are 40,000 different code lists which means you have to define 40,000 different tag names. EG: This element name CountryCode is a UBL element and it has things fixed. That means because the information is fixed it has to have a different name than anyother element that has things fixed. This is a problem. The fact that is fixed screws you up. The only way to fix this is to go back to LCSC and tell them that fixing it is a problem. GS; This is a design decision. EG: Where is this XS:element name="ISO33166". GS: This is not UBL , it is part of Eve's suggestion. LS: We have 2 codelists from UN/ECE that follow this pretty closely. EG: I don't know what the right answer is. It may be that it is appropriate to have different element names. One of the advantages of having it fixed is that the instance become smaller as there are all kinds of things you don't need to specify. In the element name reading without the schema in front of you, you have a good idea of where it is coming from. GS: We might not need any attributes. We would like to design serious business documents, which means implementors/customers have to handle 40,000 different versions/characteristics of code lists. LS: Our first choice is for us to use these codelists but not use them. GS: We are using the NDR rules for our own definitions. It is not very easy if you have 40,000 different tag names and interfaces. AG: This is not a problem for many people. EG: I think the problem arises because there are 2 kind of codelist - one is a stable one like ISO, relatively stable and versioning is not important, the other type is very unstable with multiple versions. The first category should be done fixed and this should be reflected in the code, the default for the unstable one should be defaulted and tag should be generic. They are two different things. GS: I would like to think of having one generic solution that would work for both. EG: I think we should ask Eve what she thinks about it when she calls tomorrow. LS: We made a voted choice in the minutes. We ended up voting for the multiple namespaced types. GS: We have 45 different code lists defined in the business documents. Maybe 15 of these are based on standards and the others are proprietary. SP: UN/EIFACT code lists are already in use. The ones that are working well will be used. Context is another issue. SP: How do we tackle that in a certain context a subset of a codelist is required. How does this happen automatically. AG: This does not happen automatically. EG: The vertical involved specifies which codes are being used which is a subset of the whole thing. The subsets will have to adhere to the NDR Code list rules. The main problem is tag names given the multiplicity of codes how do you avoid proliferation of tagnames. EG: You either have to have 40,000 element name tags or namespaces. You can deal with it in different manners e.g have one element code with attributes that tell you about the code, agency etc. Your application will either know what to do with that or not. In that particular case you can't have default or fixed attributes in the schema itself. GS: My SAP colleagues would like to use NDR definitions but we have to handle our customers varying requirements. We have to find the most efficient way to do this. EG: This example we have in the codelist document, is it an example from the UBL namespace. GS: It is just an example defined by Eve. LS: We have made decisions, do we have to open it all up again. Can we make some smaller changes and compromise. EG: This might be fixed with a tweak. LS: Gunther, read Eve's document and think about it. GS: I will do this tonight and I would like to see how this can be solved within Eve's rules. If I find any solutions tonight I would like to show this tomorrow. ----------------- Mavis Cournane Co-chair UBL NDR SC Cognitran Ltd

==========
Attendance:

Achieved quorum: false
Counts toward voter eligibility: true

Individual Attendance
  • Members: 9 of 1 (900%)
  • Voting Members: 0 of 0 (0%) (used for quorum calculation)
Company Attendance
  • Companies: 7 of 1 (700%)
  • Voting Companies: 0 of 0 (0%)

Quorum rule: 51% of voting members