[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Code List spaces
Mark, Legacy support is a double edged sword. There are clearly legacy practices that should not be persisted and actively discouraged. One could make the case that xsd:token is a clearer standard for codes than allowing random significant spaces as part of code list values. Paradoxically XSD schema itself is also a legacy technology that permit some pretty disasterous syntax mechanisms when interoperability and clarity is desired. The NIEM NDR for example publishes 180+ rules of DO NOT DOs when it come to XSD mechanisms. I'd suggest that code lists with multiple spaces may well also fall into this category - things I like to call "silly human tricks" - but not something we would want to encourage in definately in standards. Thanks, DW -------- Original Message -------- Subject: RE: [ubl-dev] Code List spaces From: "Crawford, Mark" <mark.crawford@sap.com> Date: Thu, June 18, 2009 10:54 am To: "Tim McGrath" <tim.mcgrath@documentengineeringservices.com> Cc: <ubl-dev@lists.oasis-open.org>, <UNCEFACT-ATG@LISTS.UNECE.ORG> 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]