[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 adedicat

  • From: "Costello, Roger L." <costello@m...>
  • To: "'xml-dev@l...'" <xml-dev@l...>
  • Date: Tue, 17 Feb 2009 08:11:33 -0500

RE:  Should an XML vocabulary be a Swiss Army Knife or adedicat

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


[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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.