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:]
>>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.
>
>
>>
>>
>>
>>
>
>
>
