RE: [ubl-lcsc] comments on 1.0 beta

["CRAWFORD, Mark" <MCRAWFORD@lmi.org>]

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

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160