[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Should an XML vocabulary be a Swiss Army Knife or a dedica
Roger, I think you are missing a the important scenario, and one which is the major contributor to interoperability costs: The two companies may or may not currenty interoperate, and may or may not interoperate in the future - however their customers and suppliers may not only interoperate with one or the other, but with other customers and suppliers as well. Rather than focusing on creating the XML vocabulary, you should focus on what makes a good interoperable data model. The XML expression of that data model should be a trivial exercize that can be done with tooling that has been designed to implement a set of commonly defined XML naming and schema design rules. In my experience, the data model is the key. What we are doing at SAP is defining a conceptual data model using semantic data standards, developing context specific logical data models from that conceptual model, and generating the XML expressions using XML NDR standards. Oracle is doing a similar approach - as are many standards development organizations. We are all aligning on the same standards for the data models and the XML expressions. In your basic scenario, both Fedex and the local moving company would create their contextualized data models from the common conceptual model. The logical data models are then easily transformed into an XML vocabulary using the NDRs. Kind Regards, Mark Mark Crawford SAP Standards Architect Standards Management and Strategy Global Ecosystem and Partner Group SAP -----Original Message----- From: Costello, Roger L. [mailto:costello@m...] Sent: Tuesday, February 17, 2009 8:12 AM To: 'xml-dev@l...' Subject: RE: Should an XML vocabulary be a Swiss Army Knife or a dedicated appliance? Hi Folks, Tommie Usdin did a great job focusing the problem statement: When should one accommodate variation in an XML vocabulary and when should one create separate XML vocabularies? He also made an illuminating comment that any proposed solution to the problem should target the usage of the XML vocabulary(s), not how easy it is to create the vocabulary(s): The differences in the costs to CREATE the vocabulary(s) should be (largely) irrelevant in an environment in which the vocabulary(s) are create once and used many many times. Let's approach the problem from that perspective (i.e. how does the XML vocabulary benefit the users). Let's return to the example of the local moving company & Fedex. Suppose that currently the two companies are paper-based; they desire to become digital-based and use XML to structure their data. Your job is to create an XML vocabulary. Should you create separate vocabularies, or should you create one vocabulary that supports variation? I see four possible scenarios: SCENARIO #1: INDEPENDENT/INDEPENDENT The two companies currently operate independent of each other (they don't do business with each other) and they will continue to operate independently in the future. SCENARIO #2: INDEPENDENT/INTEROPERATE The two companies currently operate independent of each other (they don't do business with each other) but they will interoperate in the future (the local moving company will subcontract with Fedex). SCENARIO #3: INTEROPERATE/INDEPENDENT The two companies currently interoperate (the local moving company subcontracts with Fedex) but in the future they will be independent (they won't do business with each other). SCENARIO #4: INTEROPERATE/INTEROPERATE The two companies currently interoperate (the local moving company subcontracts with Fedex) and in the future they will continue to interoperate. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ANALYSIS xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx How would you create your XML vocabulary(s) to benefit the users in these four scenarios? I'll take a stab at answering: SCENARIO #1: INDEPENDENT/INDEPENDENT Create separate XML vocabularies. The users won't benefit from one vocabulary with variations. SCENARIO #2: INDEPENDENT/INTEROPERATE Create separate XML vocabularies and perform XSLT transformations when interoperability is needed. SCENARIO #3: INTEROPERATE/INDEPENDENT Create separate XML vocabularies and perform XSLT transformations when interoperability is needed (the XSLT stuff will go away once the companies stop doing business with each other). SCENARIO #4: INTEROPERATE/INTEROPERATE I see two sub-scenarios: SUB-SCENARIO #1: LOTS OF INTEROPERABILITY The two companies interoperate a lot. SUB-SCENARIO #2: LITTLE/LOCALIZED INTEROPERABILITY The two companies interoperate just a little. Here's how I think the XML vocabularies should be created for these two sub-scenarios: SUB-SCENARIO #1: LOTS OF INTEROPERABILITY Create one XML vocabulary with variation. SUB-SCENARIO #2: LITTLE/LOCALIZED INTEROPERABILITY Create separate XML vocabularies and perform XSLT transformations when interoperability is needed. RECAP My analysis reveals these recommendations: 1. Always create separate XML vocabularies except for the situation where both companies already interoperate a lot and will continue to interoperate a lot in the future. 2. Use XSLT to transform separate XML vocabularies where interoperability is needed. Do you agree with this analysis and these recommendations? /Roger _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@l... subscribe: xml-dev-subscribe@l... List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|