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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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


Subject: RE: [ubl-lcsc] comments on 1.0 beta


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


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