[
Lists Home |
Date Index |
Thread Index
]
Dare Obasanjo wrote:
>The problem lies less with the technology are more with how poorly the spec is organized and the obtuse language in which it is written. This thread is just another example of the annoying tendency for related information being in completely separate parts of the spec with no explicit connection between them.
>
>
Any sufficiently monolithic technology is indistinguishable from spaghetti.
Once a large technology is made from sufficiently intertwined parts,
there is no way to order an exposition
of it such that strongly-connected ideas are always close together.
Spaghetti doesn't want to be free. (At least,
"no way" to order the exposition with HTML-style pages: maybe WXS needs
something more like
Nelson's transclusion, where you can pull in fragments (without losing
their context) and embed them
into running text, without the maintenance penalty of duplicated
sections.) Indeed, I think that
is a forgotten rationale for XML over SGML: dumbing down an intertwined
technology so that it
could have a spec straightforward-enough that people could conveniently
read it.
Schematron is much smaller and more obviously layered, and its spec is
pretty crappy. But
James Clark did not have to ask a single question to make his recent
implementation. (I don't
recall that the first two implementations by other people required any
questions either.) Why?
James may not be the worst programmer in the world. And maybe having a
reference implementation
helps, IETF fashion (though XSV and Xerces are Open Source and people
could refer to them.)
But the reason none of thsoe implementers of Schematron have needed to
ask many questions
(apart from the mess wth <key>) is that Schematron as a technology does
not try to do everything.
The WXS structures spec is a symptom, not the disease.
The Structures spec used to be ordered in a completely different way,
and the current order
and linking is an improvement. But because the WXS technology is not
layered (and because,
even where it could be layered, such as the component assembly rules,
the validation/traversing rules,
and the non-type integrity constraints, it all is stuffed into a single
spec), I cannot see
how it could be possible to organize most of the structures spec without
losing on the swings what
you gained on the roundabouts.
ISO specs are organized very differently to W3C specs. Much of the work
in an ISO specification
is done in the definitions section, where terms are defined and kept
alphabetically. This means
that the specification text proper can use jargon without having to
define it, which encourages
smaller, pithier paragraphs. Lots of noun phrases rather than
subordinate clauses. Verbal subroutines
rather than branches and gotos.
The tradeoff is that reading ISO specs involves a constant flipping
motion, from text to
definition and back (hence Goldfarb had the ribbons in his annotated
version). This can
be quite offputting for people who have not succumbed to the flipping
groove, because
they look at a paragraph and it is all jargon and they cannot scan
backwards to find the
definition of the jargon. But it encourages giving a name for
everything, rather than
clauses. And it allows readers to cut to the chase fairly fast, because
they don't need to
wade past sections defining terms. I suspect the ISO-esque arrangement
also encourages
the use of formalisms (I am finding that), because after your concepts
are all nicely
catalogued in the definition section, information that might complicate
a formalism
can be stuck as a note in the definitions, and readers know their
information should
be in one place or the other.
That might be another way to factor out information to reduce
complexity, but it
perhaps is locking the stable door while the horse is still bolted.
Cheers
Rick Jelliffe
|
