xml-dev - RE: Schema concepts

["Jeff Lowery" <jlowery@scenicsoft.com>]

> Well, a **processor** must have methods for the elements it's processing.
> But another processor (or stylesheet) might have very different ones.
> Example: using a rdbms I create a new view joining three tables.  I can do
> this on the fly, even the view can be temporary.  This action was not a
> method of any one table, nor of the view instance (even though I
> can imagine
> a class called a viewFactory that would create the view) nor even of the
> schema.

I've spent most my career writing code mapping relational schemas (and,
lately, XML-Schemas) to application-specific class structures and let me
tell ya-- it ain't a lot of fun. True, it's a living, but I really stand to
make more money shipping product rather than writing it. For database
applications, there are scads of tools out there that help, but it seems
none of them work quite right or quite well enough. I think that's due in
part to the chasm that separates relational schemas from hierarchical ones.
Both SQL and OOP languages have strong theoretical foundations, they're both
'complete', and you can make them work together... just not very easily.

Not to mention that if you talk 'database' to most programmers, you tend to
get glazed looks. The two worlds have different mindsets and ways of
thinking about data. So now comes along this new hierarchical data
structure, called XML, which more easily maps to OOP classes than relational
tables do. All we need is some schema to enforce data integrity, and all
this data flying around from app to app has some chance of being correct.

Is XML-Schema that schema? Yes, it's complete, and it's been developed by
some very bright people with strong formal background.  They're proud of
what they've written, and they should be: it's a technically impressive
piece of work. But it's not simply OOP-like: it has two hierarchies (one for
types, one for data elements), two types of derivation, semantic linkage via
'equivClass', something called ContentModel (why?), user-defined datatypes,
and some doodad called a 'facet' (which I can grok for all of about five
minutes at a stretch). There's various sundry other structures, but I'd have
to spend 15 minutes skimming through the current spec to remember what they
all are.

Now, somebody is going to try to make a tool that maps XML-Schemas to class
definitions of my favorite OOP language of the moment. How easy is it going
to be for them? How much of the complexity I don't use or want or care about
can they hide away from me? Will the mapping be so complex and so garbled
that all tools from all vendors will essentially be useful for not much more
that prototypes of real applications? AND HOW MUCH WILL THEY COST??

I'm the first to admit I'm not a true tech-head; there are plenty of people
who are who will make a lot of money achieving gurudom in the field of
XML-Schemas. I wish them well. What I want is something that will help me
get some already-late application out the door using technology that has a
chance of being relevant five years from now. If that technology gets in the
way of that goal because it's so complex I have to spend half my time
reading about it (obfuscated XML-Schema contests anyone?), then I'm not
being as productive as I could be.

Don't get me wrong-- I'm not angry, I'm not hysterical. It's just that I've
seen a lot of projects fail because they worried too much about being
optimally efficient or fully featured or technically sexy and not enough
about simply getting the product out in the simplest way possible. Such, I
fear, is XML-Schema.



***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************