[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Custom order information
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]