RE: [ubl-dev] Code List spaces

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

Stephen,

I forgot to mention that in CCTS3/DTC3/NDR3 we actually support your requirement in the sense that Code. Details Content Component Business Value Domain can be expressed as string, normalized string, or token at the CC, BIE, and BDT type definition level. This is accomplished through the floating primitive concept we are introducing.  However, we believe that token is the proper primitive for the majority of the use cases and have set it as the default.  If you are interested, I would recommend reading the latest DT Catalogue for a more complete explanation of our new approach to defining value domains for the DT content and supplementary components.

Kind Regards, 


Mark 



-----Original Message-----
From: Stephen Green [mailto:stephengreenubl@gmail.com] 
Sent: Thursday, June 18, 2009 8:44 AM
To: Crawford, Mark
Cc: Tim McGrath; ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] Code List spaces

I can't include CEFACT on this posting as I'm not on the list
but I'd just like to make the use case I'm putting forward a
little more concrete (removing anything which could be called
anecdotal).

A code can be made up of characters whose position in the code
has meaning.

This practice has been used in systems which, like EDI, use
fixed width files as 'messages' or 'documents' to pass information
where the meaning of a character is partly determined by the
character itself and partly by its position in relation to the other
characters. A space therefore is no exception since it is both
a character like the other characters and it can have a position
to other characters.

A code from such a system would need to follow a similar
approach since all of its characters have position in relation
to other characters and that position coveys a meaning.

This kind of practice might be considered legacy but it still
goes on today (not really an anecdotal comment so much
as a self-evident fact - that EDI and related systems are very
much in use and do not all use CSV or XML exclusively so they
will still likely include position-related meaning in codes).

A space in such a code can mean 'nothing goes here in this
position'.

An asterix in the same position can have a different meaning to
a space, e.g. it can be a widlcard to say 'anything can go here'
as distinct from 'nothing goes here'.

A zero character in such a code will have a meaning distinct
from a space since a zero is often used in codes to denote
a meanignful value (I don't think that is anecdotal).

So in all I would say we need non-anecdotal evidence that the
above kinds of codes will never need to be used as codes in
any of the UBL or CEFACT Code datatype BBIEs before we
can assume that the use of token is safe for codes. The same
goes for Identifiers.

If this is incorrect I would be interested to be corrected (with
non-anecdotal evidence to back it up).

I rest my case.

Best

Steve

Stephen D Green


2009/6/18 Crawford, Mark <mark.crawford@sap.com>:
> Tim,
>
> I welcome the comment.  The point I am trying to make is that make sure
> the comment provides real world examples and not just anecdotal
> evidence.
>
> Kind Regards,
>
>
> Mark
>
>
>
> -----Original Message-----
> From: Tim McGrath [mailto:tim.mcgrath@documentengineeringservices.com]
> Sent: Wednesday, June 17, 2009 5:18 PM
> To: Crawford, Mark
> Cc: ubl-dev@lists.oasis-open.org; UNCEFACT-ATG@LISTS.UNECE.ORG
> Subject: Re: [ubl-dev] Code List spaces
>
> 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
>
>