RE: [ubl-dev] Code List spaces

["David RR Webber \(XML\)" <david@drrw.info>]

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
 >