RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and Restricted Data Types

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2006-05-10 20:32 -0400, Fulton Wilcox wrote:
>It is an interesting question as to how to manage constraint propagation
>within and across UBL schemas. However, I think a more urgent question is
>what are the impacts on the end-to-end process and on the integrity of the
>data? I suggest that the schemas be left "unconstrained" and any constrains
>be left to the originator's source and transaction extraction processes.
>...
>As illustrated, there is no good, compelling case for capping string lengths
>or otherwise altering the "natural" data - e.g., in which "natural" means
>that the company name is the company name. Perhaps I am missing another
>"case" or have mis-stated one listed.
>
>Once filters are put in place, it becomes exceeding difficult to eliminate
>them, because of the "n-way" change management process needed. Even after
>the parochial interest in them disappears (e.g., through systems upgrades),
>nobody will have the time or energy to figure out whether a long-existing
>constraint is important to anyone, so it will persist, potentially decade
>after decade.
>
>Therefore, let the entities doing the trading enforce data disciplines
>internally and in their feeder processes to UBL rather than have UBL
>constrain its capabilities.

Amen!

That is more eloquent than my earlier brevity:

At 2006-05-04 18:37 -0400, I wrote:
>If you put it in the schema, you are constraining the 
>vocabulary.  The vocabulary should be considered sacrosanct and 
>untouchable.  Throughout programming it is considered good technical 
>practice to use layering (protocols, implementations, constraints, 
>operating system user interfaces, etc.) where one combines solving 
>different problems with different appropriate layered solutions 
>rather than creating (and having to change) one monolithic solution 
>that impacts on all users.
>
>Using Schematron one can layer on top of the schemas their own 
>restrictive rules (business or technical).  If you want to restrict 
>the length of a description, Joe, that's fine ... go ahead and do 
>it, just don't change the definition of UBL doing so, and the *only* 
>normative component of UBL is the schema expression.  Those files 
>are really sacrosanct and untouchable.
>
>And it doesn't make sense to impose one implementation's limits on 
>the whole user community of UBL.
>
>And it doesn't make sense to impose two trading partners' limits on 
>the whole user community of UBL.
>
>UBL is defined so that everyone can use it ... why do you insist on 
>trying to change it?  If you have your own restrictions then 
>implement your own restrictions without changing UBL as that changes 
>it for everyone.

. . . . . . . . . . . Ken

--
Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
Also for XSLT/XSL-FO training:    Minneapolis, MN 2006-07-31/08-04
Also for XML/XSLT/XSL-FO training:Birmingham,England 2006-05-22/25
Also for XSLT/XSL-FO training:    Copenhagen,Denmark 2006-05-08/11
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal