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] XML Vocabularies for Large Systems - 3 Philosophically Dif

[ Lists Home | Date Index | Thread Index ]
  • To: "Roger L. Costello" <costello@mitre.org>, <xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] XML Vocabularies for Large Systems - 3 Philosophically Different Approaches
  • From: "Chiusano Joseph" <chiusano_joseph@bah.com>
  • Date: Sun, 12 Dec 2004 20:34:37 -0500
  • Thread-index: AcTghEw4Yn4yvzD4QTeOieA+HxiZmQAJz+Ig
  • Thread-topic: [xml-dev] XML Vocabularies for Large Systems - 3 Philosophically Different Approaches

[Stepping up on Strategist Soapbox]
I think this all comes down to business and technical requirements in a
given situation, and cannot be defined as a heuristic. In considering
the three proposed approaches (copy/pasting here for reference):

   a. Create multiple, simple XML vocabularies.
   b. Create a single, simple XML vocabulary that is used in multiple
ways.
   c. Create a single, large, complex XML vocabulary.

I can see potential cases for all 3 - it really depends on the needs of
the particular situation. 
[Stepping down from Strategist Soapbox]

I will assume here that a "system" can expand beyond an organization's
boundaries and include its trading partners - i.e. it need not be
confined to an organization internally (not in December 2004).  

Regarding the 3 approaches:

For (a): Consider a system that has multiple aspects, or sets of
functionality requirements, each of which operates according its own
simple XML vocabulary. For example, a loan-processing system may have an
XML vocabulary for the loan application, and another for its
interactions with credit bureaus. It may be required by a given credit
bureau to use the credit bureau's own XML vocabulary for interacting
with it - in which case the loan-processing system would need to
translate tags and contents as necessary. This is a case where there are
2 simple XML vocabularies. I realize that in this case, the same
organization did not create both vocabularies - but I'm sure there are
cases in which that may be necessary. 

In this case, the business and technical requirements called for
"bridging" the 2 XML vocabularies, because the loan-processing system
vendor could not dictate to the credit bureau that the credit bureau use
their XML vocabulary for information exchange.

For (b): Here we are dealing with vocabularies that are more general in
nature - that is, they perform a function that is not specific to any
business domain, and that is really "context-neutral". An example of
this would be if an organization decided (for whatever strange reason)
to create its own proprietary messaging format for a given system,
rather than using SOAP (for example). Consider further that a system has
the ability to extend the messaging format with "custom" tags as needed.
The set of tags used in the "base" messaging format would constitute an
XML vocabulary that is used in multiple ways.

In this case, the organization's business and technical requirements
drove them (for some strange reason) to create their own proprietary
messaging format.

For (c): Consider the same situation as (a), but where the same
vocabulary is used for the loan application and credit bureau
information. Perhaps both systems use the same overarching standard
vocabulary - i.e. one that covers both the loan application and the
credit bureau information. We will assume that this standard vocabulary
is "large" and "complex" (as per the approach description above), but
that is of course subjective.

In this case, the business and technical requirements called for using a
common vocabulary, because one was available and applicable. Or perhaps
it just so happened that the loan-processing system vendor and the
credit bureau happened to use the same standard vocabulary.

Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Strategy and Technology Consultants to the World
 

> -----Original Message-----
> From: Roger L. Costello [mailto:costello@mitre.org] 
> Sent: Sunday, December 12, 2004 2:54 PM
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] XML Vocabularies for Large Systems - 3 
> Philosophically Different Approaches
> 
> Hi Folks, 
>  
> I am interested in hearing about the nature of XML 
> vocabularies that are being created for large systems.  I am 
> particularly interested in hearing from people who have been 
> successful in using simple XML vocabularies to implement the 
> complexities of varied data in large systems.  
> 
> Allow me to explain further...
>  
> DEFINITION
>  
> XML Vocabulary: an XML vocabulary is the collection of tags 
> that is used to markup data.  For example, this data:
>  
>      Borders Bookstore, 20 Boylston Avenue, Boston, MA, 01320
>  
> may be marked-up using this XML vocabulary:
> 
>      <Addressee>, <Street>, <City>, <State>, <Zipcode>.  
>  
> This later constitutes an XML vocabulary for U.S. Mailing Addresses.
>  
> SYSTEMS OF INTEREST
>  
> My interest is in large systems, where the variety of data is 
> large, and in the nature of XML vocabularies for such systems.
>  
> ISSUE - NATURE OF XML VOCABULARIES FOR LARGE SYSTEMS
>  
> I identify three philosophically different approaches to the 
> creation of an XML vocabulary for a large system:
>  
>    a. Create multiple, simple XML vocabularies.
>    b. Create a single, simple XML vocabulary that is used in 
> multiple ways.
>    c. Create a single, large, complex XML vocabulary.
>  
> Let us examine each of these approaches:
>  
> a. Create multiple, simple XML vocabularies
>  
>    In daily life we encounter many analogues to this 
> approach.  For example,
>    the postal service has its own simple vocabulary - 
> addressee, street,
>    city, state, and zipcode; a restaurant has its own menu 
> vocabulary - 
>    appetizer, entree, dessert, and side dishes.  I am sure 
> that you can 
>    think of many other examples.  We live in a world filled with many 
>    simple vocabularies, and (for the most part) we are able 
> to move about 
>    and function adequately with this multiplicity of simple 
> vocabularies.
>  
>    Likewise, in creating an XML vocabulary for a large system 
> one approach
>    is to create multiple simple XML vocabularies.
>  
> b. Create a single, simple XML vocabulary that is used in 
> multiple ways
>  
>    Consider the XML vocabulary called RSS.  It is a simple 
> XML vocabulary.
>    Despite its simplicity it is very popular and powerful.  Likewise, 
>    Jabber is a very popular and powerful simple XML vocabulary.
>  
>    A second approach for the large system is to create a simple XML
>    vocabulary that is used in multiple ways.  For example, you may  
>    have an RSS feed that captures one aspect of the large system, 
>    a second RSS feed that captures a second aspect of the 
> large system, 
>    and so forth.  The combination of RSS documents is used to 
>    collectively capture all the data complexities in the large system.
>  
> c. Create a single, large, complex XML vocabulary
>  
>    All the complexities of the large system are implemented 
> by creating a
>    single, large, complex XML vocabulary.
>  
> QUESTIONS
> 
> Have you implemented a large system?  Have you created an XML 
> vocabulary for a large system?  Which of the above three 
> approaches did you take? I am particularly interested in 
> hearing from people who have used simple XML vocabularies 
> [approach (a) or (b)] to achieve all the data complexities in 
> a large system.  
>  
> /Roger
> 
> 
> 
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org 
> <http://www.xml.org>, an initiative of OASIS 
> <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
> 
> 




 

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

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