UBL NDR SC Minutes September 10 2003

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

Dear all
please find attached the Minutes of today's call.

-----------------------------------------

Agenda
1. Roll call and welcome from the chair (Mavis)
Tony Coates
Paul Thorpe
Mike Grimley
Gunther Stuhec
Dan Vint
Stephen Green
Jessica Glace
Lisa Seaburg
Mavis Cournane
Marion Royal
Bill Burcham
Eduardo Gutentag
Quorum achieved.

Regrets
Arofan Gregory
Sue Probert

AWOL
Mark Crawford
2. Review schedule

*** This week - Week 7 (9/10) Cleaned up version of rules with new numbers
assigned to
groups with some narrative before Mark leaves for TC154.  - Deferred
Week 6 (9/17) Full narrative draft of document to NDRSC.
Week 5 (9/24) Start review with NDR Doc.
Week 4 (10/1) Start review with LCSC of NDR Doc.
Week 3 (10/8) NDR Doc review by SC
Week 2 (10/15) NDR Doc review by SC
Week 1 (10/22) NDR Doc review by SC
Week 0 (10/29) Release on Friday


3 Discussion of LCSC issues with Containership. See Tim McGrath's option
paper attached.
LCSC are asking us to rescind the containership rule and push it for 2.0 of
UBL instead. They say the solution causes more problems than it is worth.
LS: The only issue I find with this is that they had gone trhough and
started to find containers and were creating containers. I am hoping they
are not going to take those all away.
SG: All of that stays. We can create containers in the same way we have been
doing all along. All the containers will be ABIEs.
MHC: We have two choices - put something in place that might not be the
right solution, or not put in anything at all right now.
DV: I am glad to see the not-automatically generated stuff.
LS: We can still push back on LCSC on the library if we find things that
really need to be ABIEs.
GS: The only real issue is over the containership rules for list items. I
agree with Tim that this is a difficulty.
SG: The naming of these is a problem so is whether they should be unique or
not. Reusability is a problem. The whole concept is problematic.
DV: Let's not do it automatically, but let's use these rules for creating
these in the final spreadsheet.
SG: Then you would need to amend the rule which we probably don't have time
to do.
GS: If you go to page 20 of Tim's document, I think one of the big problem
is that you are defining alot of artificial hierarchies in the document that
will not make it very usable.
BB: I move we rescind the rule
PT: Seconded
MHC: This has been carried however Lisa Seaburg has some reservations, she
feels that something is missing but we will have to wait for push back and
further input.

4. Review cleaned up version of the rules document and added narrative that
will be supplied by then from Mark.

This had not yet been provided. Deferred and will be emailed to the list as
soon as possible.
5. AOB
SG - posed the following 2 questions for further discussion.

1) After the LCSC call yesterday, I do notice that there are 3 or 4 codes in
the CCT schema. I do agree that these should ideally be removed from here
and added as codes to the ABIEs. This would simplify the codelist
integration we are doing at the moment. Would NDR comment.
2) Why do we have currencyID and codeListVersionID as sole attributes for
cct:AmountType? Has there been a removal from here of a code attribute? If
so is it not now confusing to have an ID here - anyone without access to the
documentation would ask: is the currencyID for the code name? or the code
value? or should it be currencyCode?

SG: WE are looking at the codes now. We are deciding which codes require
which code list. Most of the time this can be handled in the model. We are
setting up a new column for Key in the model. The problem is the Core
Components have codes that require code lists. How do we reference these? I
have got to do the first attempt at creating this list of code lists and
update the model accordingly. I am not sure what should happen with the CCT
codes. The feeling yesterday in LCSC is that we have a last chance to review
the CCTs. Tim thought that some of it looked inconsistent. I would pick out
that Amount as being one of the inconsistencies. IT gives the impression
that an ID is used for the amount and it should be a code. Tims issue is
should we be using these attributes here, can they go in the model.
GS: If you read my paper about that. I recommend it makes no sense to use
attributes for it. THis addresses your issue.

MHC: GS can you step us through this?
GS: Does everyone understand what a supplementary component will be.
Every CCT based on a content component (element value) will have one or more
supplementary components. These are additional information components to the
CCT. The supplementary component for AMount is CurrencyID. These are
expressed using attributes.
The paper explains why this was done.
SG: OUr issue is to how we are implementing code lists. Some of this
supplementary components could be put in the ABIEs.
GS: Look at my Code list namespace paper. It makes sense to use
list-specific supplementary components for defining a code list.
Some code specific supplementary components like CodeName, these are
specific supplementary components for each code.
SG: These should be moved to the model schemas from the CCT schemas.
GS: We are not currently using anything in the namespaces now. Information
is in attributes. It is more efficient if we use this information for the
URN itself.
EG: The URN on page 5 of your codelist namespace document, it says that you
recommend to use a namespace URN etc. Is that always exactly the same URN or
does it change according to what it is.
GS: It changes according to what it is.
EG: Does this modify Eve's paper.
GS: It cleans up Eve's paper.
SG: Is it ok according to the CCT spec.
GS: IT is completely based on it.
EG: Going back to the example 2.2 language code represented as
language%20code.
GS: ISO uses spaces
SG: We decided to use the DerivedCodeType for everything, that way we don't
need to make the name of the type unique. We want to generate schemas, and
we would have a new naming problem so we decided to use the same Type name
but the namespace and its prefix would be different.
GS: I can't understand this. That is a problem. IF you decide something like
that it impacts the XML schema and the NDR SC is responsible for it.
It violates existing rules.
SG: We are not violating any rules. It was decided that we have to adapt the
model to include the name of our code list. The model has to be finished by
Friday. We know NDR will have to review our work. We are implementing the
code list group proposal who are usingthe NDR code list paper. We are taking
this on trust.
MHC: GS will need to investigate and inform the Code List group if they are
in violation or is it that NDR have not yet got a rule.
GS: They are not exactly violating NDR exactly but perhaps CCTS.
MHC: Can you check about CCTS compliance?
GS: If we are using the Code List Catalog, that we put the names of the URNs
in to this.
GS: I propose - ALL code list specific supplementary components into the URN
of the namespace into the attributes.
MHC: Agreed unanimously with quorum.
MHC: Stephen can you please find out when NDR will get the Code list
document from the Code List Group.
LS: I will be on the call tomorrow and will find out.
MHC: We will need to add this to the schedule

------------------
Mavis Cournane
Cognitran Limited