RE: [ubl-dev] Custom order information

[Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>]

Let me suggest that the XML schema should be the last choice for
customization.

Trading partners internally almost without exception internally use
non-standard, idiosyncratic processes, data practices and application logic.
This statement is true even if, for example, the trading partners both use
some given ERP such as SAP, because trading partners A, B, C .etc. have
different worldviews, histories, and real and perceived needs. It is even
more of an impediment if the trading partners are in different geographies,
industries, etc.

The hope held out by UBL and other standards is that standard transactions
can serve as an "inflight" common ground that we all can recognize and,
largely, comprehend. The eBusiness world is an "in-between" environment,
with the transaction being "outside" both trading partner's environment.
Therefore, a "standard" transaction is out of synch with what any trading
partner would regard as "my enterprise's way."

Given that nobody natively "speaks" UBL, the process creating a UBL
transaction needs to perform some mapping, interpretation, etc. in order to
to transform enterprise-specific content into a UBL-defined transaction.
Similarly, the recipient needs to do some mapping, interpretation, etc. to
get the received content into the recipient's own environment. Whether the
required construction and deconstruction processes are simple or complex,
they are needed to create an intermediate transaction that is neither
"yours," nor "mine," but for purposes of bridging differing worldviews are
"ours."

Therefore, what to me would seem to be the preferable option would be to
focus any customization effort into the steps required to construct or to
deconstruct the standard UBL transaction. For example, use the
construction/deconstruction processes to put suitable null values in the
unneeded data fields, put customized content into the various freeform data
fields, etc. Confine "customization" to pre-processors, so that when it is
time to replace one construction and deconstruction process with another, it
will be clear exactly where to go and what to fix.

One negative consequence of embedding "customization" into the document
itself is that, by definition, updates to the customization agreement must
be made concurrently by both trading parties. On the other hand, if all the
customization is in the preprocessor, each partner can make changes without
disturbing the document schema and namespaces. Loose coupling is better over
the long term than tight coupling.

Too often, I have seen situations in which people have not been sufficiently
demanding of others and of themselves to stay within standard. Indeed, once
it becomes a mindset that a "standard" document is merely a "draft," people
sometimes have customized to achieve some end that in fact the standard
provided for, but the people doing the customization didn't look hard enough
or did not think outside the box of how "we do it."  There are also
situations in which people want to add "payload" data to a document which
the people designing the standard document did not include, because that
category of data simply didn't belong in the transaction. 

You may know of some unavoidable need or some enormous benefit that demands
tinkering with the UBL schemata, names spaces, etc, but I suggest that that
should be a last resort. 




	
Regards,


	
Fulton Wilcox
	
Colts Neck Solutions LLC





-----Original Message-----
From: Chin Chee-Kai [mailto:cheekai@softml.net] 
Sent: Tuesday, January 03, 2006 9:53 PM
To: Franck de Bruijn
Cc: ubl-dev@lists.oasis-open.org
Subject: RE: [ubl-dev] Custom order information

>>For a new project we are going to use UBL to establish an ordering
interface
>>between two parties. These parties have agreed on what information is to
be
>>supplied in the order XML and also what not to supply.
>>
>>What's now the best approach?
>>* customize the UBL schemas where:
>>  - superfluous optional fields are removed
>>  - some optional field are made mandatory
>>* use the standard UBL schemas and execute extra validation rules upon
>>receipt of the order XML?

Base on purely the context you provided here, I'd think you'll be 
better off using the customization method.  Reasons supporting are:

- Both parties are known & fixed
- Fields for transaction are known & fixed
- Contract (or unofficial agreement) between the parties are
  not extended to other parties (which may add more fields)
  (this is an assumption)
- Redundant fields won't carry extra load on system/database,
  especially if there are many of these.
- Redundant fields don't introduce unrecognised error conditions,
  which adds to complexity of error processing
- Made-mandatory fields will correctly flag an error in customized
  schema if customized data instances lack them, instead of allowing
  them to filter further into the system before such errors are found.


The use-as-is method, like you mentioned, would require extra 
application-layer validation rules.  If the customization is not
"extensive", ie mostly similar to standard UBL schemas, it might be
worthwhile to just use this method.  What is "extensive" is more a
subjective question whose answer might depend on resources, level
of familiarity with the schemas, time available to implement,
parties' mutual willingness to use either method, management
input (such as whether it is important to future-proof, 
standards-aligned, etc), and so on.

One of the stronger values that the use-as-is method brings is more
in terms of allowing the user-party to easily accept future unknown
transaction parties.  This is assisted by the fact that all details
of documentation are already available to those yet unknown parties,
so there's less chance of requiring lengthy discussions on usage of
each field, especially doing this with each such future party.

This situation, however, doesn't help in your case because you do
need an extra application layer to make sure the data makes sense
to your processing.  It'll be like investing heavily into a multi-
purpose multi-terrain vehicle, only to use it 100% on the smooth
main highways.. it'll be better off spending the same amount of
money investing into a fuel-economical vehicle that excels at 
wheeling on highway.



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/



---------------------------------------------------------------------
This publicly archived list supports open discussion on implementing the UBL
OASIS Standard. To minimize spam in the
archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately, using email: list-[un]subscribe@lists.oasis-open.org
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee homepage: http://www.oasis-open.org/committees/ubl/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/