xml-dev - RE: Schema concepts

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

> > 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.
>
> I disagree here. Schema validation can only go so far. Linear
> thinking drives
> us to diminishing returns. I think what we need to complete the validation
> is to involve the application logic (or some clearly defined
> portion of it).

I think you misunderstand me. Certain low-level business rules (such as
cardinality and type) belong in the schema because they're usually valid for
all applications that use the data described by the schema. As you go
higher-level business rules, I think you get some variance either in scope
or procedure from one institution to another, or change over time. So people
have started to move those rules to a layer between the database and the
application. I'm happy with XML-Schema restricting itself to cardinality,
type and structure validation.

>
> Yes, we want to keep most of the validation logic out of the
> application. But we
> also need some hooks in the mapping process that can supplement schema
> validation.
>
> > 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.
>
> Woops! You started this with mapping schemas to application-specific class
> structures. But now it almost sounds like you are talking about compiling
> a schema, which a lot of folks are doing. That's a much easier
> problem, though
> I personally don't think it buys you as much.

Again, I'm probably wasn't clear enough, above. Yes, I know of at least one
product that will take and XML-Schema right now and produce Java interface
definitions. It doesn't handle all the latest Schema constructs (and maybe
it never will), and it only solves half the problem I'm dealing with now,
which is trying to write low-level schema-conformant wrapper classes (I
wrote my own validator based on an earlier version of the Schema spec. It
only handles attributes, elements, cardinality, datatype, refines and
enumerations-- and you know what? That's about all I'll ever really need).
Writing wrapper classes is painful, because all validation occurs at runtime
so if you make a mistake you won't know about it when you compile. So I need
a product that will generate these classes I'm writing now. I'm not going to
write it, especially for the Schema spec as it stands now. But I do need it.

I'll still have to write higher level application-specific classes that use
the schema-generated ones, but that's one more level of indirection between
the database and the application, so (I'm hoping) schema changes won't be
quite as painful to accomodate.


>
> > 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.
>
> I think there is an approach that will work here. Start small and
> keep it flexible.
> I've already got something, Quick, which seems pretty stable.
> I've gotten reports
> back from a few companies who seem to be happily building product with it.
> Yes, I did get one bug report (for which I have a fix).

I'll look at your product, and I agree with your approach. It'll be the tool
makers, such as yourself, that will give the spec a good shake-down. If the
concerns I've expressed turn out to be much ado about nothing, I'll buy
everybody on the committee a beer. (Umm... how may people are on that
committee, anyway?)


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