[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: RE: Proposal: a building block approach to XML design

• From: David Lee <dlee@calldei.com>
• To: Andrew Welch <andrew.j.welch@gmail.com>, "Costello, Roger L."<costello@m...>
• Date: Thu, 19 Jul 2012 12:41:06 +0000

I suggest that in practice what has been discovered is that except for very primitive building blocks
like String ,List , Dictionary etc that people have not been able to come up with highly reusable data objects.
Each use case tends to have very different needs and trying to standardize on one is very hard.
Things as simple as Person or Address - even Time is hard 

The other approach is to make a huge complex "one size fits all" object for a particular class of use.
For example HTMLL , DocBook , HL7 ... many of these have been created.
The advantage of these however is not lego at all.  Its that you have let someone else do all the hard work to create a complex machine
and are willing to work a little extra to let your problem  fit into their solution in order to be able to use common tools.
Well one might say HTML is like lego in that there is a well-defined set of interchangeable objects with known properties ... 
I dont see that very often though ... its not easy.


There are a few exceptions of "add in" type metadata objects such as Dublin Core that have had some success.

But my perspective is that how people dont make "real" things out of lego except maybe works of art to prove its possible,
people are not making real data structures out of reusable complex structures.

Perhaps in time it could be done.   In the physical world this slowly happened as people started standardizing on 
things like screw sizes, chipsets, dimensional lumber ..  But it has taken a long long time for this to happen.
Maybe it can happen in software ? 



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


> -----Original Message-----
> From: Andrew Welch [mailto:andrew.j.welch@gmail.com]
> Sent: Thursday, July 19, 2012 8:26 AM
> To: Costello, Roger L.
> Cc: xml-dev@lists.xml.org
> Subject: Re:  RE: Proposal: a building block approach to XML design
> 
> > It occurs to me that this applies to data design as well -- identify the data
> idioms common in the application area.
> >
> > Another name for "data idioms" is building blocks.
> 
> Maybe what you are looking for are the various RDF vocabularies out
> there.  Given the task of creating some new markup you could combine
> the various existing vocabularies - people, places, employment
> details, addresses, cvs (resumes) etc.
> 
> Each RDF vocabulary could be one of your reusable building blocks.
> 
> Hopefully someone with RDF knowledge will chime in, because I have none.
> 
> 
> 
> --
> Andrew Welch
> http://andrewjwelch.com
> 
> _________________________________________________________________
> ______
> 
> 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
> 

• Follow-Ups:
  • Re: RE: Proposal: a building block approach to XML design
    • From: Stephen D Green <stephengreenubl@gmail.com>
  • RE: RE: Proposal: a building block approach to XML design
    • From: "Len Bullard" <Len.Bullard@ses-i.com>
  • Re: RE: Proposal: a building block approach to XML design
    • From: John Cowan <cowan@mercury.ccil.org>

• References:
  • RE: Proposal: a building block approach to XML design
    • From: "Costello, Roger L." <costello@mitre.org>
  • RE: Proposal: a building block approach to XML design
    • From: "Costello, Roger L." <costello@mitre.org>
  • Re: RE: Proposal: a building block approach to XML design
    • From: Andrew Welch <andrew.j.welch@gmail.com>