RE: [ubl-dev] Custom order information

[Chin Chee-Kai <cheekai@softml.net>]

>>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/