UBL NDR SC Minutes PM 29 April 2003

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

Dear all
please find attached a copy of this afternoon's minutes. The main items
discussed were
1. Overview of Context Methodology
2. Code lists.

We hope to bring one item in the Code list discussion up on the call
tomorrow 12-14:00 London time. If you are intending to participate on the
call it would be good if you mailed me privately to let me know.

Regards
Mavis
------------------------------------
Agenda items

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 <ISO3166CountryCode>, 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
<IdentificationCode>
   <CountryCode V1>
 </>
</>

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