RE: Proposal: a building block approach to XML design

[Michael Hopwood <michael@editeur.org>]

David,

Thanks for a nice, clean breakdown of the namespaces/contexts issue. It would actually be quite handy to hear this discussion dragged out for the report I'm currently writing.

I'm working on a data integration project across book publishing and library sectors.

We constantly hear the "lego" analogy because we are also looking at creating Linked (Open?) Data and it's apparently the way forward...?

The approaches of the two "worlds" do often break down into these 2 basic categories.

In the commercial world you've got the pragmatic approach of contextual ontologies (see http://www.doi.org/VMF/documents/VocabularyMappingFrameworkIntroductionV1.0%28091212%29.pdf and http://www.erpanet.org/events/2004/cork/presentations/040617PaskinPIConcepts.pdf for a way in to this huge topic). I'm sure other communities are doing similar. CIDOC-CRM (http://www.cidoc-crm.org/docs/ontological_approach.pdf) has much the same functions but from a different point of view.

On the other hand, there is the approach of more or less ignoring schema validation...

Cheers,

M

-----Original Message-----
From: David Lee [mailto:dlee@calldei.com] 
Sent: 18 July 2012 18:08
To: Costello, Roger L.; xml-dev@lists.xml.org
Subject: [xml-dev] RE: Proposal: a building block approach to XML design

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
> 



_______________________________________________________________________

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