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

[Anne Hendry <anne.hendry@sun.com>]

Hi Mavis,

Just a clarification on:

>There is a gulf between what LCSC needs for production, what NDR expects the methodology to be.

My clarification:

It's not so much that there's a gulf in the methodology, but just that lcsc needs the model bit now, and clsc is just finalizing the requirements and still needs more time to finish the model.  It was my understanding that there has been work done on the clsc model, but that it's just not ready to hand off yet (still needs to be written up and then reviewed).  I don't think there's a huge gulf in methodologies (approaches), though, and we're working to make sure of that - clsc will be distributing the requirements by next week and will work with lcsc to do the best we can to make sure what is released doesn't preclude the model that clsc currently envisions.

-A


Mavis Cournane wrote:

>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.
>
>
>
>
>
>
>
>
>
>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.
>
>  
>