Re: [xml-dev] Most XML vocabularies are too large and inevitablyhave lot

[Liam R E Quin <liam@w3.org>]

On Sat, 2011-12-17 at 19:50 +0000, Costello, Roger L. wrote:
[...]
> With just a few items and a few combination rules, an entire field was spawned.
> Because it is limited it has been possible to formally characterize Lambda Calculus.

There are formal characterizations of systems with more components, of
course.

> A few days ago Michael Kay made this startling statement regarding XML Schema
>       ... the more you read the XSD spec, the more holes you find.
> 
> And on the xmlschema-dev list Michael Kay recently stated this
>       ... the schema construction model is not defined very formally ...
> 
> Let's think about this:
> 
> 1. XML Schema is a comparatively small XML vocabulary. I haven't
> counted the number of elements and attributes but let me guess that
> the total is 100 (probably less).
> 
> 2. XML Schema is pretty rigorously specified.

Your quote from Mike Kay directly contradicts (2) and for good reason.

> Yet despite its smallness and fairly rigorous specification it still has "holes" in it.

A human system without holes has yet to be devised. The Completeness
Theorem suggests that you can't have a system without holes unless it
has bugs.

A vocabulary with three elements, one called "element", one called
"attribute" and one called "text", may get you a long way in some
useless formal sense, but the resulting system is _more_ complex and
harder to constrain and test than one with the elements you actually
need.


> ASSERTION: An XML vocabulary consisting of 100 items (or more) is too
> much. It can never be formally specified and it will forever have
> "holes."

This is a nonsense, does not follow from your (self-contradictory)
premises, and does not make sense.

[spurious math example delated]

> How will you possibly avoid "holes" in an XML vocabulary that has a
> complexity space that is in the trillions of trillions of trillions of
> permutations?

The lambda calculus has every bit as many permutations, and yet you say
that it is defined without holes.

> Let me toss out a number: an XML vocabulary should not contain more
> than a dozen primitive elements and a handful of combination rules.
> That should be enough to generate all the richness one could possibly
> ever need. And you just might be able to formally specify your XML
> vocabulary and ensure that it has no "holes."  
> 
> Clearly this is the only way to go for mission-critical applications.
> 
> Comments?

It's bullshit, sorry.

There's a lot to be said for having limited choices at any point - for
example, a vocabulary with 18,000 elements that can go at any point in
running text is obviously not likely to be manageable for human authors.
But this is <exactly/> <how/> <English/> <works/>! We cope because at
any point there are relatively few _likely_ pavilions... er, I mean, few
_likely_ choices to be made.

Without a formal definition of terms such as "holes" or "Michael
Kay" :-), it's hard to argue, but note that a "perfect" system that
doesn't meet evolving business needs may well be perfectly useless.

So for a "mission critical application" the primary criteria for success
may well not include "does it have holes".

But there's no magic bullet, no fixed number, no one "best pratice" for
every use.

Best,

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/