RE: [xml-dev] A Systematic Approach to using Simple XML Vocabularies to Implement Large (Complex) Systems

["Chiusano Joseph" <chiusano_joseph@bah.com>]

> -----Original Message-----
> From: Roger L. Costello [mailto:costello@mitre.org] 
> Sent: Tuesday, December 14, 2004 4:17 PM
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] A Systematic Approach to using Simple XML 
> Vocabularies to Implement Large (Complex) Systems
> 
> Note: This is a continuation of the thread: 
> 
>    XML Vocabularies for Large Systems - 3 Philosophically 
> Different Approaches  
> 
> I have changed the title to reflect the narrowed focus.
> 
> GOAL
> 
> My goal is for us (the xml-dev group) to collectively define 
> a systematic approach to using simple XML vocabularies to 
> implement large (complex) systems.

Are you trying to define a methodology, or a series of choices? It looks
to me like the latter. If it's the former, who would the audience
(users) of the methodology be?

> Yesterday Len and Peter outlined two strategies.  I would 
> like to flesh out their ideas.
> 
> TWO SIMPLE VOCABULARIES
> 
> Let's consider a concrete example.  Suppose that the 
> following two simple vocabularies have been created:
> 
> 1. Postal Address Vocabulary:
> 
>    <PostalAddress>, <Addressee>, <Street>, <City>, <State>, <Zipcode>
> 
> 2. Book Vocabulary:
> 
>    <Book>, <Title>, <Author>, <Date>, <ISBN>, <Publisher>
> 
> CHALLENGE
> 
> Imagine that a large system requires an Invoice XML 
> vocabulary for a Book purchase.  How can the above simple XML 
> vocabularies be used to implement this Invoice vocabulary?

I would assert that the example below does not really demonstrate an
Invoice vocabulary, because it does not have invoice-like elements such
as "PaymentDueDate", but rather it contains combination of vocabularies:
an address vocabulary, and a book vocabulary.

> Here is an example of an Invoice:
> 
> <Invoice>
>     <PostalAddress id="RLC">
>         <Addressee>Roger L. Costello</Addressee>
>         <Street>38 Boylston St.</Street>
>         <City>Boston</City>
>         <State>MA</State>
>         <Zipcode>01320</Zipcode>
>     </PostalAddress>
>     <Book id="Bach">
>         <Title>Illusions</Title>
>         <Author>Richard Bach</Author>
>         <Date>1977</Date>
>         <ISBN>0-440-34319-4</ISBN>
>         <Publisher>Dell Publishing Co.</Publisher>
>     </Book>
> </Invoice>
> 
> THE LEN BULLARD APPROACH
> 
> The approach that Len suggested was to use a "metadata 
> framework" which ties together the simple vocabularies.  Let 
> me try to make concrete Len's suggested approach using the 
> above Invoice example.
> 
> First, use the simple vocabularies to provide the basic information:
> 
> <PostalAddress id="RLC">
>     <Addressee>Roger L. Costello</Addressee>
>     <Street>38 Boylston St.</Street>
>     <City>Boston</City>
>     <State>MA</State>
>     <Zipcode>01320</Zipcode>
> </PostalAddress>
> 
> <Book id="Bach">
>     <Title>Illusions</Title>
>     <Author>Richard Bach</Author>
>     <Date>1977</Date>
>     <ISBN>0-440-34319-4</ISBN>
>     <Publisher>Dell Publishing Co.</Publisher> </Book>  
> 
> Second, create a "metadata framework" which brings cohesion 
> to the simple
> vocabularies:
> 
> <Invoice>
>    <PurchasedBy href="RLC"/>
>    <PurchasedItem type="book" href="Bach"/> </Invoice>
> 
> Len noted that Topic Maps might be used as the metadata framework.

Or RDF?

> Len, have I characterized your ideas correctly?  

What advantages does one gain using this second approach? What were the
shortcomings of the first approach that gave rise to this second
approach? And is this really about "using simple XML vocabularies to
implement large (complex) systems"? Or is it about how information is
represented within XML documents by which information is transferred
within/outside of the system? It seems to be to be the latter.
 
> THE PETER HUNSBERGER APPROACH
> 
> In the above Invoice example tags that are specific to postal 
> addresses and books were used.  A disadvantage is that many 
> domain-specific simple vocabularies must be created.

I would say "entity-specific" rather than "domain-specific", because
(IMO) an address is not domain-specific unless it refers to a specific
world region, and a book is not domain-specific unless there is
something beyond the tags above that needs to be included in the
metadata for a book (nothing specific comes to mind now, however).
 
> Peter's approach is to provide a "generic set of tags", 
> coupled with a rich set of ways to relate the generic tags.
> 
> Below I have attempted to define the Invoice using generic 
> tags coupled with "relationship tags".  Obviously I don't 
> know what I am doing.  Peter, would you fix this please?
> 
> <Collection id="RLC">
>     <Object>Roger L. Costello</Object>
>     <Object>38 Boylston St.</Object>
>     <Object>Boston</Object>
>     <Object>MA</Object>
>     <Object>01320</Object>
> </Collection>
> 
> <Collection id="Bach">
>     <Object>Illusions</Object>
>     <Object>Richard Bach</Object>
>     <Object>1977</Object>
>     <Object>0-440-34319-4</Object>
>     <Object>Dell Publishing Co.</Object> </Collection>
> 
> <Collection>
>    <Object href="RLC"/>
>    <Relation>Purchased By</Relation>
>    <Object href="Bach">
> </Collection>

Other than the association in the last content model above, is this
really much better than flat files? Everything is either a collection or
an object, which - IMO - is a step above having no metadata, but not a
large one.

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

> What do you (xml-dev'ers) think about all this?  Can you 
> think of other approaches?  /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>
> 
>