[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-lcsc] comments on 1.0 beta
To reiterate part of Tim's second question: is this a change to ccts? SCs are working from ccts 2.01, 15 November 2003. Thanks, Anne CRAWFORD, Mark wrote: >Tim, > >cct:Datatype - based on ccts Representation terms with a base=xsd:datatype >ubl:Datatypes - qualified cct:Datatypes as appropriate >Mark > > > > >>-----Original Message----- >>From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] >>Sent: Wednesday, January 21, 2004 10:24 PM >>To: CRAWFORD, Mark >>Cc: ubl-lcsc@lists.oasis-open.org; ubl-isc@lists.oasis-open.org >>Subject: Re: [ubl-lcsc] comments on 1.0 beta >> >> >>does this mean that you now agree the hierarchy of data types >>should be... >> >>xsd:datatype >>ccts:datatype (what was once representation terms) >>and >>ubl:datatype >>? >> >>isn't this a change to the CCTS or will ATG2 just have a different >>schema module name (and confuse us even more) :-) >> >>CRAWFORD, Mark wrote: >> >> >> >>>Stephen wrote: >>> >>>Bill >>> >>>Here are some more matters perhaps warranting changes before >>> >>> >>beta goes to final. >> >> >>>1. Perhaps a candidate for a (CC) Datatype is the shorter >>> >>> >>ISO date format used by credit cards and the like i.e. yyyy-mm >> >> >>>At present the DataType for CardAccount.ExpiryDate and >>> >>> >>CardAccount.ValidFromDate is Date_DateTime.Type which hardly >>seems appropriate for what is certainly not a datetime and >>barely a date. Someone correct me if I'm wrong, but I don't >>think a short ISO date like 2004-11 (equivalent to 11/04 on a >>credit card say) would be valid as an xsd:date but then >>neither would 2004-11-00 so one would be forced to use >>2004-11-01 which might confuse some and leave the way open to >>error. Against this is the possibility that some types of >>card might not use the month and year only but the whole date >>(though I've never heard of such). >> >> >>>Marks Comment: It would seem to me this is an ongoing >>> >>> >>problem because of the way we have (or better yet have not) >>handled data types. Currently the NDR model calls for >>creation of DT and RT modules. The RT is an instantion of >>CCTS, and the DT is intended to be UBL derivations thereto. >>In ATG this week we have agreed that there is really no need >>for the RT schema module. What is required are two separate >>DT modules - one as instantiation of DTs from the approved >>RTs, and one with derived DTs which are restrictions to the >>primary DT schema. For the process identified by Stephen >>above, we would create a restricted Date.Type with a pattern >>to suit what we believed to be the most appropriate. In >>discussions with Michael Dill, he has expressed a willingness >>to accomodate such a change in our model through >>instantiation in the schemas. >> >> >>>Stephen wrote: >>> >>> >>>3. The Representation Term Schema has what appears to be an error: >>> >>> >>>The schema reads for Amount, Measure and Quantity like the following >>> >>> >>><xsd:simpleContent> >>><xsd:restriction base="cct:MeasureType"> >>><xsd:attribute name="unitCode" use="required"/> >>><xsd:attribute name="unitCodeListVersionID" use="prohibited"/> >>></xsd:restriction> >>></xsd:simpleContent> >>> >>> >>>This, apparently, should be >>> >>> >>><xsd:simpleContent> >>><xsd:restriction base="cct:MeasureType"> >>><xsd:attribute name="unitCode" type="xsd:token" use="required"/> >>><xsd:attribute name="unitCodeListVersionID" type="xsd:token" >>> >>> >>use="prohibited"/> >> >> >>></xsd:restriction> >>></xsd:simpleContent> >>> >>> >>>with type="xsd:token" inserted before 'use=...' >>> >>> >>>This was shown up by Sonic Software Corporation's Stylus >>> >>> >>Studio (version 4.6) but surprisingly not by XML Spy. Perhaps >>NDRSC would confirm whether this is a W3C XSD Schema error or >>just a software quirk. >> >> >>>Marks Comment: Concur with the requirement to use >>> >>> >>xsd:token. See NDR Section 5.1.3.4 examples. >> >> >>>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-lcsc/members/leave_workgroup.php. > > >> >> >> >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]