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

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

We all agree at least tacitly on names for most common objects, at least
within a local cultural context.  Machine processing requires more
explicit agreement and generally in much more detail (no hand-waving
allowed).  Would it be fair to say, where two businesses share the same
names for the same objects and processes in the business domain, they
would likely benefit from shared XML vocabularies as a basis for
automated interoperability?  If not, the return probably isn't worth the
investment.

Mark, do your conceptual data models cross business domains, or are they
specific to a domain?

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


-----Original Message-----
From: Crawford, Mark [mailto:mark.crawford@sap.com] 
Sent: Tuesday, February 17, 2009 3:38 PM
To: xml-dev@lists.xml.org
Subject: RE: [xml-dev] Should an XML vocabulary be a Swiss Army Knife or
a dedicated appliance?

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@mitre.org] 
Sent: Tuesday, February 17, 2009 8:12 AM
To: 'xml-dev@lists.xml.org'
Subject: RE: [xml-dev] 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@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php