Re: [xml-dev] Should an XML vocabulary be a Swiss Army Knife or a dedica

[Frank Manola <fmanola@acm.org>]

On Feb 16, 2009, at 4:39 PM, Costello, Roger L. wrote:

>
> Hi Folks,
>
> A few weeks ago we discussed what's involved in creating an XML  
> vocabulary. One of the key points that I gained from that discussion  
> is:
>
>    Create an XML vocabulary to satisfy a
>    business process; otherwise, what's the point.
>
> Excellent.
>
> But what about two business processes that are the same at a high  
> level, but vary in the details; should there be one XML vocabulary  
> or two?

When you think in terms of "creating" XML vocabularies for these  
business process using either approach, I hope you're imagining that a  
lot of this "creating" will in fact be "stealing", i.e., that you're  
not planning to reinvent vocabulary for things like customer names and  
addresses, invoices, and all sorts of stuff that every business in the  
world needs to use (or at least not without thinking about it a  
bit).   These companies may use different business processes, but you  
want to drill down to look at the data that is involved;  a lot of  
it's going to be the same kind of stuff.

>
>
>
> EXAMPLE: LOCAL MOVING COMPANY & FEDEX
>
> At a high level both a local moving company and Fedex are the same -  
> they both move merchandise from point A to point B; they both  
> provide a way to track the status of the merchandise.
>
> At the detail level they have significant differences - the local  
> moving company can move the contents of an entire home whereas Fedex  
> primarily moves smaller items; the local moving company uses big  
> trucks to move the merchandise whereas Fedex uses airplanes; the  
> local moving company operates within a 50 mile radius whereas Fedex  
> operates worldwide.
>
> Here are two approaches to developing an XML vocabulary for the  
> local moving company and Fedex:
>
>
> APPROACH #1: Create Separate XML Vocabularies
>
> This approach takes the attitude that these are really two business  
> processes, so create two XML vocabularies - one for the local moving  
> company and one for Fedex.
>
> Advantage: it's simpler to generate the XML vocabularies. The two  
> companies won't be arguing about the XML vocabulary.
>
> Disadvantage: it will be more difficult for the local moving company  
> and Fedex to interoperate. Suppose that the local moving company  
> subcontracts with Fedex to do certain jobs; since the XML  
> vocabularies are disjoint it will be difficult to interoperate.
>
> This approach is analogous to creating dedicated appliances.
>
>
> APPROACH #2: Create One XML Vocabulary with Specialized Sections
>
> This approach takes the attitude that it's really just one business  
> process containing specialized sections.
>
> Advantage: it will be easier for the local moving company and Fedex  
> to interoperate since they share the same high level framework.
>
> Disadvantage: the XML vocabulary is more complex. The two companies  
> will argue about the XML vocabulary.

Keep in mind though that while they're arguing about the XML  
vocabulary, they will not be interoperating either (at least not using  
XML).  This is a tradeoff that seems to stall a lot of projects.

>
>
> This approach is analogous to creating a Swiss Army Knife.
>
>
> RECOMMENDATION?
>
> Which approach do you recommend? Perhaps there's another approach  
> that you recommend?
>
>
> /Roger
>