OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Top-down or bottom-up?

[ Lists Home | Date Index | Thread Index ]
  • From: Len Bullard <cbullard@hiwaay.net>
  • To: David Megginson <david@megginson.com>
  • Date: Wed, 16 Jun 1999 20:52:44 -0500

David Megginson wrote:
> 
> That's not what I mean -- creating a data model is tractable, but a
> data model is of questionable value if it's not based on a fairly
> accurate business model, use cases, etc.  I don't think that any of us
> can reasonably draw up a reliable business model that will cover the
> Web for the next five years, and even the use cases will be pretty
> shakey.  Without good models, bottom-up is our best bet.

Umm.. isn't that why we do markup and write DTDs?  They 
may not last forever, but like mudbricks that cleave, they make a
reasonable 
structure and, well, beat the heck out of fighting bears for caves.

We can always resort to "things change; why bother?" We bother 
because we get more done when we agree to what is to be done 
and the means and tools for doing it.  We make contracts. 
For some years now, some have referred to DTDs as contract-validated 
communications.  It works as long as parties agree, and agreements 
get renegotitated.  What some refer to as bottom up is responding 
to local requirements with local means.  Global requirements can 
also be met with local means but may not work for long.  Global 
requirements met with global means may not work any longer.

Say, ok good for people, not good enough for machines?  I disagree. 
It may not be good enough for certain chores, but good for enough 
chores gets enough done.
  
The fact is, you make a model, watch the output at every loop, 
and adjust.  If it means a new model, then the old model taught 
you what to look for to know when it wasn't working.  We can 
talk endlessly about the meta-models needed to keep that 
knowledge and so on, but eventually, we run out of time, 
mental stack space, whatever.  Exhaustion or no achievements. 
no roof?  Pooped out and broken but dry is better.

There is no best bet.  There is practice that works until it 
fails and what you design to cope with failure.  The problem 
of SGML, XML, and markup in general is the futile attempt of some 
to permanently capture process by static means.   It is always 
at best, a snapshot.  That is OK.  A snapshot is all you need to 
make comparisons.  Used like that, seen without the moral 
obligations to build edifices for the greater glory of some One,
markup works great.  Even an instamatic takes a good picture 
if the hand and eye are talented.  Take a block of marble  
and hack, and you get rock.  The art is in the eye.

If I learned nothing from CALS, SGML, HyTime, etc., I hope I 
learned that our tools are just tools to be wielded by hands. 
Every DTD written so far is being modified by human hands, 
or languishes somewhere in a thousand page tome.  Every mudbrick 
house needs patching or is buried in sand somewhere waiting for 
Ozymandias to return.  Still, better than the caves.

len



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS