[
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)
|