[ubl-ndrsc] MINUTES: Face to Face AM 6 Feb 2003

[Lisa-Aeon <lseaburg@aeon-llc.com>]

These minutes came out of the AM session of the NDR SC work sessions.  Topics covered were: Versioning and Namespaces, NDR Release.

 

Also attached is the Rules for Versioning Document that we worked on while on the call.  This document will be cut and pasted into the right section in the NDR document.

 

Rollcall
Arofan Gregory
Lisa Seaburg
Mavis Cournane
Fabrice Desre
Gunther Stuhec
Paul Thorpe
Gareth Minikawa
Bill Burcham
Mark Keitel (observer, Anthem Inc)
Jim Wilson (CIDX)
Dan Vint

 

Document Topic 1: Versioning and Namespace
In release 0.70 we have adopted URN format as recommended in the NDR document. See Bills example in message 19 from February.
A: We came up with URN syntax with core version as part of everybody's URN. In the non common areas have a major.minor for the core and then have a major.minor for the functional area. It is nice to have that information all in the URN. Arofan submitted this paper to NDR a long time ago.
B: We would need to adapt this to UBL as we have multiple cores.
A: Are we going to version those separately.
B: We have Core Component Types (CCT) and Common Aggregates (CA). Now we have a Core Component Types namespace and a CA type namespace under our names.
A: We could adopt a tripartite scheme if we have 2 levels of core. We could change the CA without changing the leaf element representation.
CCT is at the center, followed by CA, and then all the document level.
A: For example a CCT is a string and I only allow it to contain numeric data. At a later stage this is a problem and  I change all strings to being numeric to alphanumeric this is a significant change as all documents with string are  impacted.  If I have a CA like Address and I don't need City and I want to deprecate it, if I get rid of the Address it does not necessarily change all documents only those using address.
If I make a change to order, for example I  don't have headers any more this change only effects order documents . therefore I have 3 levels.

 

In CBL we represent those each with a separate version number in the URN so you could see the dependencies between the levels
A; Can I directly access the construct in a namespace that is imported in to something that I import.
B: Doesn't Know
B: Counter proposal for something simple and safe. Simply to have a major number and a minor number for the namespace and we have rules when we have to bump the numbers. If I depend on another namespace and that changes then my namespace changes. In 070 we have 1.0:0.70 we would have 0:7 with 0 being major and 7 being minor. The rules around that:
You have CA namespace our reusable ABIEs, and the CCT namespace our simple leaf stuff. We have a rule that says anytime I have a UBL namespace depending on another UBL namespace, if the one you depend on changes then your version number needs to change too. Refine this. Does my major number or my minor number have to change?

 

A: The whole purpose of bipartite in a registry is essentially what you are doing is tracking that set of dependencies. If I have a CAT and I always get my leaf types that way, every time I version the CAT everything that depends on it has to version. You end up with a set of subfolders inside CAT 1.0 folder. The minute I change the top node everything else has to change. This proposal helps capture the dependencies in the URN.
B : I propose we just make sure the URI changes when it needs to rather than capture the dependencies in the URN. We can always write something that processes the schema.

 

A: IF we go Bills way, rules around major and minor  are complicated. If I have a CAT and I do a minor version of that because those changes are backwards compatible any dependent changes in namespaces of changes in the core are backwards compatible. Minor version change in core are minor version change in dependencies.
B: rather than say core, adopt a different term as we have many cores. Use primary and dependent.
A: The common leaf time namespace is source and the common aggregate type is dependent on it. When you look at the doctypes namespace i.e. order, invoice, the CAT is the source and the doctype namespaces are dependent. It produces chain reactions.
B: behind provisionally, when you change the version either major or minor on a namespace you must at least bump the minor on all the dependents and all their dependents.
j: Jessica:  *I disagree. I suppose I may be missing something regarding the polymorphic processing. But I think this will become overly burdensome to maintain in a namespace and would prefer to see it maintained as a dual function of a root version attribute and the schema version attribute.*

 

A: They key issue for not having versions in namespace. I have lineitem and I am missing a field quality. So I make that change backwards compatible and add something optional at the end. I have 2 different constructs one with it and one without it. If I don't have a different namespace I can't call the new construct.

 

B: We took a decision in Context Methodology  captured on the mailing list. Once you publish a vocabulary and assign a namespace URI to that thing, that thing can never change. You can't do the xsd:redefine. Once UBL publishes a  namespace that definition does not change period.
The idea is if any of the definitions change then the namespace URI must also change.

 

A: When the URN changes to reflect a change in the namespace this change will be reflected in version number either major or minor in the namespace URI.
A: A minor version is must be expressible as an extension or refinement in xsd syntax.

 

B: Rather than trying to write legal things one can do in a minor version. let the XSD validation do it for us. Define a bunch of schemas, do a doc release on that thing, define some new namespace that import the major ns and by subclassing or by defining brand new types and elements you make a specialization of the major schema. Any major compliant document would be compliant in the minor. IF I process polymorhically in any minor version I have a valid instance of the major version.
A: IF you are always required to go back to the preceding minor version you have single linear version tree for your minors.
If we want a single linear flow then we have to import the preceding minor version. The rule that we now propose makes it possible. This is a departure from Matt's paper.

 

A: You have to import the preceding minor version and then extend from there.
B: If you specialize UBL you do so in your own namespace
The first major release of UBL will have at the end of ns URI :1:0.
A: every major version will have the major version number  :major_n:0 starting with 1. so the first minor release will have :majornumber:1
A: Do we need a rule about the name, i.e. Type lineitemtype and want to make minor change to it, the rule should be everything that is changing version to version be given the same name in the new namespace.
When minor version changes are being made then name of the version construct will not change unless the intent of that change is to change the name of that construct - proposed rule.
A: We have to define what is core and what is not core. What we have now is very big CAT and very small document specific namespaces.
This is an LCSC thing. Somebody needs to do an analysis. We have to put the rule for it in NDR. If you look at how things get reused having document type specific namespaces makes a lot of less sense.
B: Look at the tasks coming out of this
In Sec 5.2 we have the namespace table in NDR 21 line 654. We could go in and repair those namespace names now. We make an agreement
the common leaf types term stays. The 0.70 release is out of synch wit the NDR doc rules as it uses CCTs. Bill is sending email with 2 topics . Topic one is about analysis need of Common Aggregate Types. Topic 2 is to notify non-compliance with the NDR rule.
B: The table does not follow the namespace identification rules and nor do the schemas.
L: Rule 32 and Rule 33 is used by the LC. It will change everything they have done. We need group names for these things.
B: all order domain vocabulary be put in a single xml ns is a recommendation we want to make to LC. One domain per business process. Previously identified 2 such process categories order and invoice. Nowhere now to assign ReceiptAdvice and DesptachAdvice. Do I need 2 or 1 new domain. Can I fit them in order or invoice.
G: 2 options; 1 we define each domain for each business doc i.e. one domain for receipt advice and one for despatch. Or we define one common domain for one business process.
A: The technical driver is to take CAT out of that namespace and put them into the functional namespace.
A: Ask LC from business perspective where are the process lines drawn and then NDR should decide if we have a problem with that.
G: Ask what is the best for defining ns and domains. It depends on what LC thinks.
B: we don't have a recommendation on where we see ReceiptAdvice and DespatchAdvice goes. We know some moving around has to go.
R32 and R33 are wrong.
G: should we talk about the ns for codelists too? and the prefix of ns to.
A: agrees we may not have the control over this.
G: they need some rules for it.
L: the codelist module needs a ns
A: maybe ISO has its own rules
L: I don't think so.
F: A common definition of a prefix is useless.
G: I think it is useful. You will see the prefix in the XML instance. The recipient will get the instance and will see there is a prefixed code and needs to know from which codelist
F: the information is in the URI.
G: 70 different namespaces for 70 different codelists, need 70 different prefix.
L: Put codelist namespaces and prefixes on the agenda for our teleconferences during the week.

 

B: Find out if we need rules for formulating URNs for non-UBL library namespaces.  People doing customizations and includes people doing codelists.

 

A:Explore rules for formulating prefixes or namespaces (codelists, customizers, and library namespaces).
F: Disagrees with issue about prefixes.
G: In reusable types there are 82 different codelists. Within order document we are using 282 different codelists. The max can be 282 different ns.
You can use for every code a different codelists.
L: Are you counting duplicates?
G: Saying 282 is the worst case.
G: Lots of people have problems defining namespaces and prefixes. Don't know how to define unique prefixes for namespaces.

 

Document Topic 2: The NDR release
NDR release date is April 28th at the London meeting.
Freeze date April 2nd for the NDR internal team.
Goal to have it to Mark by March 1st is a good one.
Packaging of the NDR document. Proposals are  we use the Oasis XML format, Oasis Docbook, continue the way we are, do HTML like the LC.
A: If we put it out in HTML and Docbook. In every useful format we can . Arofan will help with Docbook to HTML transformation.
L: Put together packaging team.
D: W3C formats already have stylesheets.
Packaging team: Arofan, Jim (will do his best), Fabrice, Lisa, Mark, Mavis and Jon.
J: In a number of formats strike home to number of users.
M: Can Bill commit to helping with sections. Yes.

 

 

 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.441 / Virus Database: 247 - Release Date: 1/9/2003

Attachment: Lisa Seaburg.vcf
Description: text/vcard

Attachment: Rules for Versioning06feb03.doc
Description: MS-Word document