OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: FW: [ubl-ndrsc] Minutes NDRSC 4 February 2004

Many apologies to Eduardo and any others who couldn't see the comments below
which had been marked in red I have now put ~ brackets around my comments
which you will find in items 2, 3, 4 and 6.


>  -----Original Message-----
> From: 	Sue Probert [mailto:sue.probert@dial.pipex.com] 
> Sent:	06 February 2004 22:27
> To:	Mavis Cournane; ubl-ndrsc@lists.oasis-open.org
> Subject:	RE: [ubl-ndrsc] Minutes NDRSC 4 February 2004
> 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
> 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.
> 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 th ~ e 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_workg
> roup.php.

<<attachment: winmail.dat>>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]