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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


Subject: Re: [ubl-ndrsc] Agenda for 27 August NDR SC Teleconference -item 3


Greetings

Just by way of introduction to item 3

> 3. Discussion of CCTs types (token versus string) and others.  This was
> something that came up in the LCSC call, that they felt belonged with NDR,
> Stephen Green will help get this discussion started.

At present all the UBL 'Identifiers' (in the business model sense) are based on Core Component types which are themselves based on xsd:token. 

When we added, at eGov request, the GUID to the models, I chose for it the Core Component type 'Text' since this was based on xsd:string and I wasn't sure about the use of xsd:token for something like a GUID. Discussions of this at the Montreal face-to-face revealed that there are actually uncertainties about the appropriateness of xsd:token for any identifier (such as an ID which is actually an Order Number or Invoice Number). It was found that xsd:token restricts a string to exclude, most importantly, white space. Now the feeling is that no such restriction is acceptable for an ID. For instance, a business may require that an order number have certain characters (perhaps representing some business meaning) at certain positions within it. This might involve some need to preserve white space if that data does not always have the same length. In general, white space may carry business meaning or information in any particular ID.

This raises the matter that the appropriateness of all the chosen Core Components should be reviewed concerning their base types.

All the best

Stephen Green



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