Fw: [ubl-ndrsc] UBL NDR SC Minutes September 10 2003

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

This shows the decision made on the 10th of Sept, I have deleted alot of the
un-needed text.  Down at the end, we agreed unaminmous with quorum to these
rules.  But we still somehow missed getting them into our checklist.

Lisa and Gunther

----- Original Message ----- 
From: "Mavis Cournane" <mavis.cournane@cognitran.com>
To: "UBL NDR" <ubl-ndrsc@lists.oasis-open.org>
Sent: Wednesday, September 10, 2003 12:07 PM
Subject: [ubl-ndrsc] UBL NDR SC Minutes September 10 2003


>
> 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
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php.
>


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