Minutes NDRSC 4 February 2004

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

Dear all
below are the minutes for this week's audio.

Regards
Mavis

--------------------
1. Roll call

Mavis Cournane (will attend F2F)
Michael Grimley (will attend F2F)
Stephen Green  (will not  attend F2F)
Eduardo Gutentag (will attend F2F)
Jim Wilson (will not attend F2F)
Marion Royal (will attend F2F)
Sue Probert (will attend F2F)
Lisa Seaburg (will attend F2F)
Paul Thorpe (will attend F2F)

Regrets
Anne Hendry
Mark Crawford

AWOL
Gunther Stuhec

2. Subcommittee Reports
LCSC report
Issue that came up that Stephen raised Representation Term schema. This is an 
agenda item.
LC are pretty close to finishing the model.

Code Lists
The requirements document is coming together nicely. But does it reflect what 
is required for 1.0 UBL.
There are a number of actions outstanding on the requirement document.
There is a gulf between what LCSC needs for production, what NDR expects the 
methodology to be.
We have to go ahead with the Code List production model of what we have now in 
LCSC. There is no time to wait
on this.

TTSC
Michael Dill and TTSC have been very active.

The first range of schemas have been produced from Edifix. There are no 
limitations that are going to be dealt with.For now
they have been done from the beta spreadsheet.

3. Datatype request from LCSC.

LS: Is NDR the correct place to request a new datatype.
SG: This is finding out what a new datatype will consist of. Tim's opinion is 
that we should ask NDR to create
the datatype for us. I have done a mock up of one. This datatype would live in 
the unqualified datatypes schema?
SG: I don't know.
SP: We agreed not to put any new datatypes in to NDR. One of the way we deal 
with it is to have a new
schema.
SG: It is not based on DateTime so we can't use it.
It is based on string all I have done is create a pattern.
LS: THat is incorrect. Your best way is to datetime datatype and restrict it.
SP: WE can create that in the normal way as a restricted datatype of DateTime.
EG: Why do we need a datatype that changes the order of the factors. Isn't that 
stylesheet issue.
SG: It is to get rid of the requirements of Date.
SP: We want a specific type of DateTime.
SG: The real problem is that we can't include the Day and Date won't work 
without it.
LS: THat is where restriction comes in.
SP: WE have already done it, Time datatype is restricted. 
We have 3 datatypes already, the generic DateTime, 2 restricted ones, one to 
become Date on its own, and the other Time on its own. WE just
need another one called YearMonth.
SG: How do we do it with schema?
SP: With a primitive.
SG: In order to restrict DateTime, you need a mechanism to restrict the 
basetype for DateTime.

SG: The time one is actually using xsd:Time. THere is already an xsd you can 
use.
I don't know a way of restricting xsd:Date.
EG: What is the problem with using GYearMonth. 
SG:Neither of those are a schema restriction of the core component datetime. 
EG: They are schema restrictions.
EG: We need to find out how it was done.
LS: I am looking at the schema now. I am looking at the RT schema. It has 
datetype and timetype. They have xsd:Date and xsd:Time. 
We want to base it on GYearMonth.
LS: Let's do this through email.
We don't really want to use a string.
SG:It is for credit card expiry date, more a string than a date.
SG: We might need to take this to ISC for workarounds.
LS: WE can't just kludge things.

Action: LS to talk to Garret and Gunther by Monday.


4. Representation Term schema is a related topic.
SP: The error that might be in this is much more serious and could be very 
detrimental to the finished product.
The RT schema appears to inherit from the CCT schema. We are not sure exactly. 
It looks like the IdentifierDatatype picks up successfully from the
Identifier Type in CCT, but for the Code one it is not bringing it. 
RT xsd that is going to be the unquailified datatype xsd.
LS: We need to get some help from Garret.
SG: If we can't get this resolved in this schema. We could use the UBL 
Datatypes schema.
SP: It looks like it might be able to put it right in the RT schema.
SG: Can we edit this without Gunther. It is not meant to have RT as a prefix, 
not have the same namespace. Can it be done in time for 1.0
SP: Yes it can. Gunther and Garret definitely know how to do it.
Edifix need to do this too.
MHC: We should let it alone until Monday, for definite Monday action.
ACTION: Sue to report to the chairs SC on Monday if this can be resolved. If 
not Sue will ask for an emergency chairs call.

SG: We always had a lack of supplementary components in Amount. WE have only 
ever had versionId and currencyID. SO there is now way of saying
which code list you are using.
SP: WE won't do this for 1.0
SG: WHy can't we restrict Amount and not have them in there.
SP: WHy bother? They are optional. We can't be CCTS compliant if we take out 
CurrencyCode.
SG: WE should at least make notes for the documentation about these type of 
things. Because we have relied on these, and they are not reliable, it might
be an idea to create BBIEs for Measure and Quantity. It would allow us to use 
the Code List mechanism for that.
SP: Does it really matter for 1.0
SG: People are going to be creating lots of documents based on 1.0
SP: WE document this.
MHC: Can't we document it in a release note.
SG: WE can only give advice but that might be not to use UBL.
SP: OUr schema has it in the documentation of the Amount RT.
SG: It is not good enough. The schema is not where the data is going to be.
SP: I have never known anyone to use the parameters in Edifact.
MHC: Action to mail Jon and ask for this to be a multi-sc session.

5. Type=Xsd:Token is missing from the RT schema in Amounts, Quantity etc.
EG: That is part of the library task.
SP: Gunther did this as part of his TTSC work.
Action: MHC to mail Anne about this.

SG: There is no ambiguity as to how negative amounts are validated by xsd 
schema - can we confirm this.
E.g Can somebody use a comma as a decimal place?
I think Anne found the answers in the specs. Anne thinks from the XML schema 
spec there is no way to use anything than a dot for a decimal unless you
specify another language or locality.
LS: I thought we could use negatives without any problem.
SG: There are 2 separate issues, decimal and negative.
EG: It is universally accepted that number preceded by a dash is negative and 
that is restricted out in xsd.
SG: Can you use a succeeding dash?
EG: That is a stylesheet issue.
SG: If they were mistakenly to have one, 
EG: this would be an error.
SG: COuld you use 10,25 validly.
JW/EG: Probably not. One way to get around it, is to have 2 values. One for the 
left of the point, the other to the right of the point.
SG: YOu could have a BBIe to specify the separator.
EG: That would be wrong thing to do.

6. Review on editorial work on latest version of NDR document and checklist
LS: I have no clue. This is a big issue.
NDR has to ask Mark this. He says the rules have not changed but the 
explanatory text has changed.
LS: I will distribute the checklist.
SP: Tim was clear that he need answers to these questions.
Action: Lisa to mail Mark.