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:]
> Sent: 06 February 2004 08:02
> To: UBL-NDRSC ()
> 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:
Web Technologies and Standards | Phone: +1 510 550 4616 x31442
Sun Microsystems Inc. |
W3C AC Rep / OASIS BoD
