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
>