Re: Why Are Schemas Hard?

[Peter Piatko <piatko@research.telcordia.com>]

----- Original Message -----
From: "Jeff Lowery" <jlowery@scenicsoft.com>
To: "'Peter Piatko'" <piatko@research.telcordia.com>; "'Michael Brennan'"
<Michael_Brennan@allegis.com>; "'Bullard, Claude L (Len)'"
<clbullar@ingr.com>; "'Nicolas LEHUEN'" <nicolas.lehuen@ubicco.com>
Cc: "'xml-dev'" <xml-dev@lists.xml.org>
Sent: Friday, August 24, 2001 1:53 PM
Subject: RE: Why Are Schemas Hard?


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

I don't think the use of <complexType> clearly denotes what's a local
element and what's not.  Simply put, I think there will be lots of schemas
with lots of locally scoped elements where there wasn't much thought put
into whether those elements should be local or not.  Fans of local elements
might suggest that this is a "good" feature of XML---sort of in the same way
that programming languages tend to guide you into using local variables.
But I don't think that the case for local elements has been so strongly
made, so I'd prefer if their declarations stood out so that the author is
conscious of his/her decision.

I've been writing my admittedly toy schemas in Emacs, and as wonderful as
Emacs is as an editor, the task often drives me insane.  So I think maybe
that yes, I agree with you that the language is a bit verbose. ;-)  But XML
is nothing if not verbose anyway ...

> > <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 there are two issues:

1) Understanding what namespaces are and their use.
2) How to deal with namespaces in XML Schema.

IMHO, once you get past (1) then (2) isn't so hard (with the caveat that all
elements are global).  Of course, now I am suspicious that my understanding
of (2) is all wrong.  :-)

There is the ancillary issue of how to divide your elements/definitions/etc.
into which namespaces.  Maybe that's the more difficult problem.

> > 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 am not sure if my bookshelf could stand the weight of the tome.  :-)

>
> > 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 thought about this *after* sending the mail out and I'll have to agree
with you here.  One "feature" of XML Schema is that their are many ways to
do essentially the same thing.  A little too many for my taste really ...

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

Object-orientation arose to deal with complexity.  On the other hand I can
write procedural code  (or "procedural-like" code) in an OO language if I
want to---sometimes a useful thing to do for a simple problem ...

Ah, anyway, I don't want to overly defend my rather broad philosophical
statement.  ;-)  I am guessing that the XML Schema WG simply tried to tackle
too many problems at once.  Time will tell which features of the language
will see real use.  In the meantime, I will have to guess.

> Take it easy,

You too.

> Jeff

Thanks,

Peter