[
Lists Home |
Date Index |
Thread Index
]
That's fine as long as you have a plan to cope with
unknowns (what you don't know) and unknown unknowns
(what you don't know you don't know). That plan may
be anything from start over to fail. "Fear is the
mindkiller" as Herbert wrote. Still, if you stick
to a small problem everyone has and solve that, you
have a least made a lot of people more productive.
If you try to solve everybody's problems with one
solution, you are likely to have mostly dissatisfaction.
But until you can think through precisely what the
problem is, this advice won't get you far. XML
could be simplified because SGML was already done.
Building a simple thing first to solve a ubiquitous
problem is quite difficult. You have to be very
precise about the problem.
XML is what it is (1.0) because that
can solve one problem shared by many people: a
syntax for transporting data objects better than
delimited ASCII. Once past that, the numbers of
problems solved effectively appear to diminish proportional
to the number attempted by any one application. This
is one reason to get nervous about those who want
to consider the syntax merely a serialization of the
InfoSet-spec'd properties. It looks reasonable but
notice the problem definition just changed.
Try this. Make a list of all of the XML applications
and XML systems you use. Next to that, put a short
but precise description of the problem to which it
is applied. The first problem is working out what
is an XML application vs an XML system. Note how
often you are depending on concepts such as the
InfoSet vs how often it is just syntax and known
names and value spaces. When is it useful to
have a schema? We think we understand all that
and some do, but that was the kind of thinking that
went into simplifying SGML.
I wanted to get rid of parameter entities, myself.
Some said they couldn't maintain complex DTDs without
them. I said, maybe complex DTDs are the problem
that preserves the problem.
Point of view....
len
From: Rex Brooks [mailto:rexb@starbourne.com]
Is there something inherently wrong with just proceeding to start
small in scope and do what you can do well as you can as long as it
allows for further development and doesn't box you into a corner or
add so much computational overhead that it becomes unuseable?
|
