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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XSD question

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

Rick Jelliffe


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

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