[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Code List spaces
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]