Altova Mailing List Archives


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

From: Bob Hutchison <bob.hutchison@---------.-->
To: "<xml-dev@-----.---.---> <xml-dev@-----.---.--->" <xml-dev@-----.---.--->
Date: 12/20/2004 5:18:00 PM
On Dec 14, 2004, at 4:16 PM, Roger L. Costello wrote:

> 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.

I don't understand the goal... Implement what in a large complex system?

>
> 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>

Well, what's wrong with using that? or, at least, staying as close to 
it as possible? From the user's, analyst's and application programmer's 
points of view this is pretty comprehensible.

I'd like to show you how we'd do this at my company -- we implement 
complex systems, some would say large, though I understand both terms 
are relative. This is just to emphasise some of the possibilities that 
I haven't seen discussed in this thread yet (Len's model is almost the 
same but I've not noticed anyone discussing it). It also may illustrate 
why I'm asking what the purpose of this exercise is.

I'd probably write it like:

<Invoice pid="invoice 001" xmlns="http://example.com/invoice">
     <PostalAddress pid="RLC" xmlns="http://example.com/postal">
         <Addressee>Roger L. Costello</Addressee>
         <Street>38 Boylston St.</Street>
         <City>Boston</City>
         <State>MA</State>
         <Zipcode>01320</Zipcode>
     </PostalAddress>
     <Book pid="Bach" xmlns="http://example.com/book">
         <Title>Illusions</Title>
         <Author>Richard Bach</Author>
         <Date>1977</Date>
         <ISBN>0-440-34319-4</ISBN>
         <Publisher>Dell Publishing Co.</Publisher>
     </Book>
</Invoice>

This just adds a few namespace specifications. It also changes 'id' to 
'pid' which is in accordance with my company's normal practice. The 'p' 
in 'pid' stands for 'persistent'.

This is, in our system, exactly the same thing as writing:

<PostalAddress pid="RLC" xmlns="http://example.com/postal">
     <Addressee>Roger L. Costello</Addressee>
     <Street>38 Boylston St.</Street>
     <City>Boston</City>
     <State>MA</State>
     <Zipcode>01320</Zipcode>
</PostalAddress>

<Book pid="Bach" xmlns="http://example.com/book">
     <Title>Illusions</Title>
     <Author>Richard Bach</Author>
     <Date>1977</Date>
     <ISBN>0-440-34319-4</ISBN>
     <Publisher>Dell Publishing Co.</Publisher>
</Book>

<Invoice pid="invoice 001" xmlns="http://example.com/invoice">
    <PostalAddress pid="RLC" xmlns="http://example.com/postal"/>
    <Book pid="Bach" xmlns="http://example.com/book"/>
</Invoice>

With the possibility of using the same postal address and book any 
place we want.

We generally show humans the first form (and talk about the first form, 
though usually ignoring the namespaces) and show computers the second 
form.

We could just as well have used URLs for the pid (which would probably 
have been something like: <http://example.com/postal/RLC>).

We also could have used 'href' rather than 'pid' which would make this 
practically identical to what Len proposed (but 'href' is a bit too 
popular in existing XML vocabularies and we get conflicts -- yes, I 
know, we could have used namespaces on attributes, and we may do so 
sometime in the future, but there are difficulties with this that I 
won't go into here).

Note that this example says *nothing* about how the XML is stored. I 
can tell you that, so far, the advantages of storing the pieces in 
coherent chunks of XML are overwhelming. I find it interesting that the 
various "semantic net" like models that this thread seems to be 
discussing in detail only come up in discussions at my company when we 
talk about how to store the data -- nobody wants to actually *use* it 
like that.

----

I should also say that we have a tool that scans XML definitions like 
the one above and builds from it a Java framework (for lack of a better 
word) that supports the manipulation of those XML definitions. For 
three years I've been using this tool, or one of several ancestors 
since about 1998 (whenever it was that I first got my hands on David 
Megginson's Java SAX parser).

Cheers,
Bob


----
Bob Hutchison          -- blogs at <http://www.recursive.ca/hutch/>
Recursive Design Inc.  -- <http://www.recursive.ca/>

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.