RE: Why Are Schemas Hard?

[Jeff Lowery <jlowery@scenicsoft.com>]

Paul Piatko responds:

> > > Len:
> > > > 1.  What about Schemas is hard?
> Jeff:
> >
> > To me, it boils down to whether they're conceptually hard 
> or syntactically

> At the risk of sounding like a broken record about this, I 
> find that it is
> too easy to declare local elements without really meaning to 
> (did you really
> intend for <bar> and <baz> to be locally scoped?).  One can 
> argue about the
> various merits/demerits of local scoping, but the concept 
> should be made
> clear to the schema author.  I'd almost be happy with a 
> <local-element>
> element.

Yes, that may be good enough reason to denote local elements somehow, either
through <complexType> elements or <local-element> declarations as you
suggest. I only intended to point out that it adds a lot of verbosity and
makes the schema tedious to write by hand and and noisy to read. Trade-off.
Fair to ask if that was the proper trade-off to make, however.

> <snip/>
> 
> > If Schemas are conceptually hard, that's a different 
> matter. certainly the
> > rules for namespaces, <all> model groups, and seemingly odd 
> inheritance
> > restrictions certainly are difficult to master. Here, tools 
> may help by
> > enforcing these rules through edit controls and choice 
> presentation, but
> > that's not sufficient for understanding by the schema author. To
> understand,
> > he needs not only to know the spec (which is no easy task), but the
> > decisions and compromises that were made in the writing of the
> > Recommendation.
> 
> Neglecting local elements for a moment, I didn't find the rules for
> namespaces overly difficult.  

Considering the number of threads, web sites, FAQs, and articles about the
subject, I think you're in the minority. Perhaps it's that the concepts are
easy but the rules of scoping are not; in any case, there's a lot of
electrons shooting down the wire that could be put to good use in lava lamps
but for explanations of namespace usage in XML Schema. 

> I think this
> is an area where the Part 0 tutorial could be enhanced.  

Or you could wait for a book on the subject :-)

> I 
> can't say that I
> totally understand model groups, substitution groups and all of the
> inheritance rules.
> 
> OTOH, I believe I can write simple schemas w/o ever using 
> these features.  

Yes, but how many of these features are you going to encounter as you
interact with other data systems? That's the real problem with complex
schema languages. No system is an island, and sooner or later you're going
to have to understand all what you're being given, not just what you
produced. Even with good tools, concepts can be hard to grasp, which is the
point. 


> I
> am a firm believer that simple tasks should be easy to do.  Sometimes
> complex tasks are hard to do and there is no getting around 
> it, so perhaps
> some of the complexities of XML Schema are necessary.  As 
> long as they don't
> get in the way of the simple tasks I'd be happy.

Object-orientation is another hard concept to grasp, expecially for people
who have been programming procedurally for many years. On the other hand,
once you get it, it is extremely empowering. Most problem domains map more
intuitively to classes and objects than they do to procedures. Do the
concepts of type restriction, substitution groups, namespaces, etc. in XML
Schema offer similar empowerment to the developer? I think yes, but I also
suspect that it could have been done 'cleaner'. Not a very constructive
criticism, but others on this list have pointed out numerous examples where
simpler would have been better.

Take it easy,

Jeff