RE: [xml-dev] Should an XML vocabulary be a Swiss Army Knife ora dedicat

["Cox, Bruce" <Bruce.Cox@USPTO.GOV>]

Market size and business size will have an impact on who is willing to
invest in creating and maintaining a vocabulary.  A world-wide moving
company or shipping company might consider it worth their while, but
"two guys and a truck" operating in a 300 mile radius might not.
Maintenance is critical to the success of any vocabulary.

In the case of industrial property offices, the solution we implemented
was to create a Swiss Army Knife approach for those parts of a patent
publication that vary widely from office to office (so-called "front
page" information), but created a single vocabulary for the description
of the invention.  Sometimes we regret that, but not usually.  There are
a large number of elements for the front page, called international
common elements, that can be supplemented by office-specific elements.
For the description, no office-specific elements are permitted, even
though it shares some elements with the front page.  Some (including the
USPTO) use processing instructions to customize the description when
necessary, but no one expects those to be used or understood by anyone
other than the office of origin.

Interoperability is uppermost in our minds when revising the markup, but
in point of fact, there have not been very many cases of heavy
processing of XML exchanged between offices that would clearly decide
whether we were right or wrong to take the approach described above.  At
least not yet.  Korea, Japan, and some other offices are in the process
of revising their internal systems to be largely if not entirely XML
based, so we may have some real test cases in the next five years or so.
The potential is huge, since essentially the same application might be
filed in many offices, some as small as five examiners, others as large
as 5,000 examiners.

Bruce B Cox
Manager, Standards Development Division
OCIO/SDMG/USPTO
571-272-9004


-----Original Message-----
From: Frank Manola [mailto:fmanola@acm.org] 
Sent: Monday, February 16, 2009 6:30 PM
To: Costello, Roger L.
Cc: 'xml-dev@lists.xml.org'
Subject: Re: [xml-dev] Should an XML vocabulary be a Swiss Army Knife or
a dedicated appliance?


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
>