Re: [xml-dev] XML spec and XSD

[Rick Jelliffe <rjelliffe@allette.com.au>]

Mukul Gandhi wrote:
> I don't think, there is anything wrong with the basic core/philosophy
> of XSD. I guess, some of users who don't like XSD generally, it's
> probably because of it's huge size, and steep learning curve.
>
>   
I do.

First, it does not encourage a schema-writer to make a user model, to 
know how to explain invalidity or versions/variants to humans. That 
information being missing from the chain, it entrenches the position of 
developers as gurus to whom the supplicant users must go to.   In other 
words, XSD actively *discourages* validation and human inspection. The 
PSVI certainly may have enough information for automated data exchange 
in fully debugged, in blind accept/reject gateways, or data-mapped 
systems; but I don't know that was actually a use case which was not 
already served adequately (by ODBC, CVS, CORBA, IDL, now JSON.)  In a 
decade where we supposedly appreciate Test-Driven Development more than 
ever before, we have a schema language that fights against this kind of 
use, in syntax, features, complexity and inexpressive autism. 

Second, it does not have enough hooks in it to allow traceability 
between the schema and business requirements.
Look at the question of why one element is supposed to be followed by 
another. There are several possible
reasons:

  1) it might be the instrinsic or typical order for renderings,
  2) by fixing an order, a schema-aware compressed form might save a bit 
(or is it half a bit?) - an entirely marginal reason to my way of 
thinking but I have heard it used,
  3) because derivation by extension is being used in XSD 1.0 and so 
suffixation was the only possibility,
  4) to mirror the order of some data which is transformed into this,
  5) err no reason, it just seems neater

XSD is not neutral about traceability: it is antagonistic to it.   Now I 
agree that XSD 1.1 has lots of additional things which help mechanical 
power (at the expense of a multiplication of concepts): the open schemas 
idea and so on are things I (and, in particular, Roger Costello) have 
long raised, so I am sure many people will benefit from the XSD 1.1 
changes (just as people benefit from lipstick on a pig?)  But still some 
of them are hacks, bits tacked on (like the cart in the Imaginarium of 
Dr Parnassus) without addressing what I think are the more fundamental 
issues such as disconnection from humans and disconnection from 
requirements. You would expect that kind of disconnect in a technology 
invented in the 1970s or 1980s, but not one for leading us into the 2010s.

So it is exactly in XSD's imagined core philosophy, detectable by how 
XSD has been used or implemented and where it thrived or failed, that I 
think the problem lies.  XSD is not a technology that encourages 
technocrats to empower the just-folks or non-technical management, in 
the way that HTML, XML and, I really hope, Schematron do. That puts it 
in the class of being things that are part of the problem rather than 
part of the solution.

Cheers
Rick Jelliffe


P.S. I don't know that this analogy will add to the clarity, so I have 
put it down here. Years ago there was a cartoon strip in the newspapers 
called Li'l Abner. It is rarely spoken of now, because of its depictions 
of US minorities, I gather. But there was a little animal called the 
Schmoo: in 1949 it was more popular than Mickey Mouse (see 
http://en.wikipedia.org/wiki/Shmoo For a pic see 
http://deniskitchen.com/Merchant2/merchant.mvc?Screen=PROD&Product_Code=BP_shmoopin 
).  It loves to be eaten (unlike the Magic Pudding, it gets used up.)  

The XSD standard is not a standard made by Schmoos. It centralizes the 
power of developers, rather than allowing developers to localize their 
role.