RE: [ubl-dev] Code List spaces

["Crawford, Mark" <mark.crawford@sap.com>]

Hi Stephen,

My concern is that UBL is basing yet another decision on deviation from UN/CEFACT on anecdotal evidence.  Unless you can show specific examples of where the number of spaces in meaningful and differentiates one code from another in a particular code list, I see no reason for UBL to abandon the use of xsd:token for codes and identifiers.

Kind Regards,

Mark 



-----Original Message-----
From: Stephen Green [mailto:stephengreenubl@gmail.com] 
Sent: Wednesday, June 17, 2009 11:45 PM
To: Crawford, Mark
Cc: ubl-dev@lists.oasis-open.org; UNCEFACT-ATG@lists.unece.org
Subject: Re: [ubl-dev] Code List spaces

Mark

The use cases I referred back to were where codes are set by
users, such as accounting codes. I guess these could be
made Identifiers but that might not always be the case - there
may be occassions where for other reasons they have been
made codes. Either way, there are no *published* codelists.
The example I gave was accounting codes and costs centres,
etc but it may be more about the legacy system the code comes
from rather than which code it is. Take mainframe applications,
such as bespoke, legacy, in-house finance systems, where codes
may include several spaces which carry meaning and for which no
published codelist exists but where these codes form part of the
document sent; as with a code which the sender needs to receive
back in a response in order to process the response. The older
mainframe systems tend to include spaces in their codes I find
and the number of spaces may carry meaning. Even an order
number from a mainframe may include spaces which the legacy
system requires to be preserved - that's a identifier rather than
code of course but the identifiers need to have a suitable datatype
for this too. Of course the expectation that the other party can
preserve the spaces might be dwindling but I, IMO, the weakest
link should not be the business language like UBL.

Best

Steve

2009/6/18 Tim McGrath <tim.mcgrath@documentengineeringservices.com>:
> Just to let you know that rather than set up a separate thread on this issue
> we are planning to raise it as part of our response to the imminent CCTS 3p0
> DT Catalogue Public Review.
>
>
> Crawford, Mark wrote:
>>
>> Sent to the UBL Dev list as I can not post to UBL directly.
>>
>> In the minutes from 15 June UBL Pacific Call, the following appeared:
>>
>> SGTG (GKH): See
>>
>>       _http://lists.oasis-open.org/archives/ubl/200906/msg00011.html_
>>       _http://lists.oasis-open.org/archives/ubl/200906/msg00012.html_
>>
>>       GKH: The token data type allows only singleton spaces.  This
>>       means that legacy code values with multiple adjacent spaces
>>       will be corrupted by the token type if we adopt the current
>>       ATG approach.  See note from SG (second URL above).
>>       Normalized string as in UBL 1.0 and 2.0 removes TAB, CR, and
>>       LF, but leaves multiple spaces alone.
>>
>> UBL is requested to provide specific code list examples where multiple
>> spaces occur in the code and have special meaning that is called out.
>>  Please also note that token has been in effect for many years in the UDT
>> schema without any negative feedback.
>>
>> Kind Regards,
>>
>> */Mark/*
>> Mark Crawford
>> SAP Standards Architect
>> Standards Management and Strategy
>> Global Ecosystem and Partner Group
>> SAP
>> Office: 703 670-0920
>> Mobile: 703 485-5232
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>