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:]
> Sent: Wednesday, January 21, 2004 10:24 PM
> To: CRAWFORD, Mark
> Cc: ;
> 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.
>
>
>
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
