Top-down or bottom-up?

[Len Bullard]

David Megginson wrote:
> 
> Just so, but imagine if we had all waited to start writing DTDs until
> ISO approved a master document architecture that would govern all DTDs
> in the SGML and XML document space (kudos to HyTime for trying,
> though).

When I first saw DTDs (ISO 8879 draft), I thought that was what 
it was:  a means for creating master document architectures, that 
is, a means to express what was legal in a family of documents. 
It is hard this far into the post-HyTime era, to remember why 
that was so earth-shattering, but I was elated to finally see 
a standard that would solve so many of the document process/processing 
problems of the time when the closest thing we had to it 
was Digital Standard Runoff.  So, there was no waiting; there was 
a long learning curve in which the warts of it began to appear.  
Oddly, the warts weren't all in the notorious CS short-comings 
of the parse model; they were:

1.  The Cost of the software to support it
2.  The WYSIWYG Wars
3.  The difficulty of explaining to the writers of 
the era why anyone would want this.  "This SGML stuff 
will be the death of us."  Then two years later, "This 
SGML stuff is working."  Then ten years later; "This 
SGML stuff saved our bacon, cost-wise."

My point is, I agree, one can't wait.  One makes the 
assessment of the available tools, does a round, looks 
at the results, and adjusts.  From my perspective, HTML 
has been the GreatSitAround.  We repeated a large part of 
history watching everyone adopt a design we had already 
discarded. However, that is also part of the cycling.  
Just like when newbies hit a list, having a much larger 
community inevitably meant we went back up the learning 
curve;  from blues to jazz to blues to rock to blues again.

> This is the point that I (and others) have been making in this
> discussion: a top-down approach (start with the master architecture)
> can work for something like a new parts-management system for
> ACME.com; a bottom-up approach (start with the components, such as
> individual specs and DTDs) is pretty much required in an open and
> fast-changing system like the Web.

I tend to agree, but it isn't changing *that* fast anymore.  
There are lots of reasons, but mainly, I think the vendor-wash out 
has finally settled the designs down.  There are problems in the 
details but they are similar to and sometimes the same problems 
of say, SQL, "% or *", " or '; escape or crash.  

The argument about "does namespace point to schema" is indicative.  
Of course it can.  One needs no permission to do that.  Should that 
be formal?  Heck no, because as you and Tim point out, there can 
be many things that need pointing to, and of course, we come 
back to the venerable "what is a resource" debate.  Well, what 
does one need it to be?  A registry is a registry whether it 
is a local or global database, a table of URLs, a table of names, 
and so on.
 
> As Paul Prescod has pointed out, however, in both cases the process is
> really iterative: in a bottom-up approach, it's often useful to stop
> and throw together a straw-man architecture to see if what we've done
> so far makes sense together; in a top-down approach, it's often useful
> to stop and throw together some proof-of-concept components, to see if
> there will be any obvious implementation problems.  The difference
> comes simply from which of the two is formalized.

True and there is both sense (good design) and nonsense (politics of 
who's zoomin' who) in that.  Still, I think the markup community overall 
understands its particular problems and will do well to take a measure 
of the work to figure out what is needed for the next decade.  I thought 
that was what XML was about and that is why I supported it.  The
politics 
of it has always disturbed me, but nevertheless, the work is necessary 
and is getting good results.  I did not think I would ever see graphics 
coded in markup, but it is happening.   Now we do another five years of 
finding out if syntax unification pays the predicted dividends and 
what more is needed.  The Information Set work, HyTime, Groves, all 
of that have to be looked at in the critical light of the XML payoff.  
Is it there?

len



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)