RE: Proposal: a building block approach to XML design

[David Lee <dlee@calldei.com>]

I am not quite sure of the problem here.
If Books, Watches, and Bicycles are in different namespaces you can construct a new document containing all 3.
If none of these were written with extension in mind you can only create documents that contain or inherit from them.
But if they were built with extension in mind then there could be places in each schema that allowed children from other schemas.
This is sometimes but not always desirable.  It could well be desirable for the designer of Books to NOT allow you to put a  bicycle inside it.
If you dont like that constraint you are free to create  a new book schema (with the same namespace if you like) which allows bicycles in it.

Another approach if you totally ignore schema validation you can mix them up however you want.

----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org


> -----Original Message-----
> From: Costello, Roger L. [mailto:costello@mitre.org]
> Sent: Wednesday, July 18, 2012 1:00 PM
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] Proposal: a building block approach to XML design
> 
> Hi Folks,
> 
> Remember Legos? It consisted of a bunch of building blocks that could be
> assembled in any number of ways. There was virtually an infinite number of
> things could be created.
> 
> Let's create XML Schemas in an analogous fashion; that is, let's create a set of
> small components that can be assembled in any number of ways. Let's specify
> the rules for assembling the components.
> 
> EXAMPLE
> 
> Suppose my inventory consists of books, bicycles, and watches.
> 
> So I create an XML Schema for books, another for bicycles, and another for
> watches.
> 
> I deploy a web service that allows users to obtain book XML documents,
> bicycle XML documents, and watch XML documents.
> 
> However, I am not following the Lego pattern. I merely have a collection of
> pre-assembled components.
> 
> That's limited and limiting. No power. No diversity. No ability to generate
> dazzling complexity. Boring.
> 
> Conversely, if I had a set of building blocks (and assembly rules) then I could
> do this:
> 
>     Assemble a handle bar with a watch.
> 
> That can't be done with my current schemas. Why? One reason is that there
> are no assembly rules. Need assembly rules. Legos has assembly rules: you
> can stack one Lego block on top of another but you can't assemble them side-
> by-side.
> 
> Add another building block:
> 
>     Assemble a handle bar with a watch and add a book component.
> 
> That assembly is getting interesting. Perhaps now I can create XML documents
> of bicycles that have a watch and can hold a book. Ha! Such a bike design
> would be perfect for a health club.
> 
> What's required of this Lego approach to XML design?
> 
> (1) Need to identify an appropriate set of building blocks.
> 
> (2) Need to specify the rules for assembling the building blocks.
> 
> Let's create complexity-generating XML Schemas (and RELAX NG schemas);
> let's create simple rules that enables dazzling innovation.
> 
> Thoughts?
> 
> /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
>