[
Lists Home |
Date Index |
Thread Index
]
Roger,
let's see:
- The first approach does not scale - it will get too complex when
you then want to reuse your invoice to build a yet larger model. Too
much indirection to resolve.
- The second approach does not impress me at all. It is weakly
typed, not schema validatable, and the tags are not
self-descriptive. Heaven help the support guy who has to pull that
document.
I would suggest the straightforward solution you have at the top: build
up a new complex type that introduces containment. Simple, well
documented, and fully schema validated. Plus, if you need more
information, you can subtype Book and PostalAddress within the context
of Invoice. Plus we've built very large schemas using that approach
(with some design guidelines and schema architecture established
beforehand).
Christian
> 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.
> 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?
> 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.
> Len, have I characterized your ideas correctly?
> 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.
> 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>
> 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>
|
