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

[Eduardo Gutentag <Eduardo.Gutentag@Sun.COM>]

Sue,

whatever comments you may have added to the text below, I am unable
to find them as separate from the original text. Could you highlight
them in some manner?

Thanks!

Sue Probert wrote:
> 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.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 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.

-- 
Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
Web Technologies and Standards |         Phone:  +1 510 550 4616 x31442
Sun Microsystems Inc.          |
W3C AC Rep / OASIS BoD