OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Local Vs Global Vocabularies

[ Lists Home | Date Index | Thread Index ]

Thanks Joe.  Good conversation as always.

That's the way to design the language.  The implementation may 
be a bit different.  The trick here is to discern precisely 
in what applications the global language should be used 
and when the local optimized language should be used.  Again, 
it is difficult to change a tire on a moving car in an 
intersection.  The vendor faces the problem that the local 
user has both a culture and a legacy to cope with and so 
does the vendor.  A global industry that does 
not interoperate or share a vocabulary at this time won't 
do it quickly even with incentives, and may not ever (See CALS). 
The systems sold to them have to be efficient locally today.  
That is the usual "rock and a hard place" of the market.

So the approaches I would consider normal are roughly these:

1.  Acknowledge the value of shared vocabularies (the baby 
isn't ugly [1]).  Communities are denoted by the vocabularies they 
share.  Sharing increases over time as opportune (convergence).

2.  Apply the shared vocabulary to the right parts of the 
system today.  This can increase over time, but it won't change 
on command but by demand.

a) Transform into and out of the global vocabulary (up or down) 
for communication services between internal and external agencies. 
Thus, couple loosely.

b) Use the Data dictionary that defines the global vocabulary as 
a source of bulk-loaded data for things such as code lists.

c) Where required, use the global vocabulary for archiving where 
the archive has a longer lifecycle than the daily report (for 
short lifecycles, image archiving is typically better).

This doesn't address the problem of indexing.  Indexing is why
one usually prefers a highly optimized local vocabulary and  
a shrinkwrap system that can be lightly extended.  Data fields 
can be added to tables by the customer but not code beyond that 
inherited from the GUI control.  So they can search and report on 
these fields, validate them based on base types, but using them 
in extensive cross table relationship validation requiring code 
is not done without additional development costs.  

If high performance based on these optimizations is to be obtained, 
it is likely one does not want to implement the global vocabulary 
as the data dictionary for the local system.  One treats it the way 
the Romans used Aramaic:  learned but spoken as necessary given 
two speakers who recognize the need for it on encounter.

[1]  The customer and marketing staff barely understand 
formal technical terms, so explaining why they can't have an 
implementation of the global language AND all of their local 
requests and still meet the performance requirements is a non-starter.
It is painful and they move on to someone who buys them a beer 
and talks sports.  The 'elevator pitch' mentality pervades 
the marketplace.


From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]

"Bullard, Claude L (Len)" wrote:
> Possibly but I don't think so.  I get a message from
> that address about twice a week.  Because of the title,
> this mail will get one too.  It just doesn't appreciate
> Monty Python. :-)
> "Spam Spam Spam Spam"
> Anywho... better topic.  When designing vocabularies for
> very large communities, how do youse guys/y'all/anyone
> approach the dilemma of scale vs localization?  

With a well-thought-out and well-publicized extension methodology that
provides clear guidance for the local usage of a vocabulary as to how it
should extend the core vocabulary, and under what circumstances. Also
how extensions should be fed back to the governance body (there should
be one!) for consideration for incorporation into the core vocabulary.

UBL has a nice Working Draft [1] for "Guidelines for the Customization
of UBL Schemas" that one might find interesting and useful.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS