RE: [ubl-ndrsc] Minutes NDRSC 4 February 2004

["Sue Probert" <sue.probert@dial.pipex.com>]

Hi Mavis

I would like to make some comments which I have documented below...

-----Original Message-----
From: Mavis Cournane [mailto:mavis.cournane@cognitran.com]
Sent: 06 February 2004 08:02
To: UBL-NDRSC (ubl-ndrsc@lists.oasis-open.org)
Subject: [ubl-ndrsc] Minutes NDRSC 4 February 2004




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 with regards to our 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 may be 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 because 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: NDR agreed not to put any UBL proposed new CCTs into the NDR RT schema.
Instead they will be submitted to the CCTS revision and TBG17. One of the
ways we could deal 
with this is to create a new qualified Datatype.
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 reuse the 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 the version of the currency code list.
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 needs approved NDR answers to these questions.
Action: Lisa to mail Mark.









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_workgro
up.php.

<<attachment: winmail.dat>>