RE: Alternatives to XML Schemas

[Michael Brennan <Michael_Brennan@Allegis.com>]

Validation is a major use case for schemas; I didn't mean to suggest
otherwise. I only meant to say that there are many other uses for schema;
validation is only one, and one which is very narrow in its scope of
utility.

My biggest interest in schemas is to support data-binding, code generation,
and as a sort of rigorous documentation/interface definition language (in
comdination with WSDL) that can be provided to partners. I write interfaces
for application integration based on exhanging XML over HTTP. One thing I
don't intend to do is have those interfaces do real-time validation with a
schema. Nor do I have any interest in a post-validation Infoset. The
interface extracts information from the document instance as it is being
received over the wire (via SAX events) and maps it to "native" data
structures in the application. I want to leverage XML Schema as a way of
describing to partners what we expect in terms of XML document format. I may
use it to also capture some of the relevant metadata used internally for
data-binding and code generation. It's quite possible, though, that we will
use proprietary schema formats for that that are richer (and more tailored
to our particular application), and have mechanisms to mechanically derive
the XML Schema from that. I'm experimenting with a couple of approaches with
this, right now.

In terms of validation, no schema will be able to adequately capture all of
the business rules real-world applications need to apply for validation.
Some of these rules cannot even be based simply on the content of a single
document instance, but need to take into account factors external to the
document instance, such as business rules in an application, relational
database integrity constraints, or rules in a larger workflow that may
involve the exchange of multiple document instances (at a minimum, taking
into account the correlation of a response document to a request document).
So adding the runtime overhead and performance hit of loading a schema for
validation that is going to fall short anyway doesn't provide a great deal
of value. I'll just let the application code catch validation errors. I
would, however, like to capture the relevant rules in a schema as much as
possible, incorporating those rules into application code at code
generation/compile time. That way, these same rules can be exchanged via a
schema with partners (at least those that are expressible via a schema).

Internally, we've been using some proprietary schema formats for a couple of
years. I don't see that changing. XML Schema falls short of many of our
needs. I don't see that as a problem, though. We don't exchange these
schemas with the outside world so standards compliance is not an issue. We
look toward XML Schema to support the interchange of data with
partners/customers. We don't look for it to fulfill every need we will ever
have for a schema format (such as mapping to internal object models or
relational DBs).

> -----Original Message-----
> From: Eddie Robertsson [mailto:eddie@allette.com.au]
> Sent: Tuesday, March 06, 2001 10:01 PM
> To: Michael Brennan
> Cc: xml-dev@lists.xml.org
> Subject: Re: Alternatives to XML Schemas
> 
> 
> 
> 
> Michael Brennan wrote:
> 
> > Unfortunately, there are many implementors who will heed 
> your advice. I have
> > so far identified only a few implementations of XML Schema. 
> Each is focused
> > on one very narrow use case (typically validation) and each 
> supports only a
> > subset of the spec. Will this situation get better or 
> worse? I hope it gets
> > better, but I'm not sure.
> 
> So, are you saying that validation is just a very narrow use 
> case of XML Schema?
> I was under the impression that this was the major use case 
> for them. I
> understand that you can do other things but I wouldn't say 
> that validation is a
> very narrow use case. However, I'd love to hear more 
> information about what
> other use cases you have in mind.
> 
> Cheers,
> /Eddie
>