In response to Mike Mortensen and Timothy M. Dean, I'll try to reiterate
that I'm not against validation features being available in applications
that use Xindice as a data store. I'm against those features being
embedded in Xindice itself. I guess where there seems to be some confusion
is what "embedded in Xindice" means exactly.
First, lets differentiate structural vs. content validation.
Structural Validation: validates that the XML markup of a document is
(a) well-formed, and optionally (if a schema is available and the
parser is set in validation mode), that
(b) the markup structure is valid according to the schema constraints.
Content Validation: validates that the element and attribute content
conforms to the constraints expressed in a schema (or perhaps written
into the application itself).
I certainly understand and agree with your points, and myself have experience
similar to yours. Content validation is appropriate and often critical to
database applications. Structural validation is a rather unique need in
XML databases, since a relational or object database can't be corrupted by
incoming data (unless there's something strange in the database design).
My point (which I'm guessing was not expressed very clearly) is that any
Xindice-based application *must* have an XML parser available, and Xindice
is distributed with Xerces 2, which provides support for DTDs and XML
Schema. If you need stronger content validation, Xerces provides that with
its XML Schema support.
At most stages in the process an XML processor is *required* to handle the
XML content moving in and out of Xindice. All one needs to do to provide
stronger validation support during these processes is to establish those
parsers in validation mode, and provide the schemas necessary to validate
the content. As I mentioned in my previous message, you can even "pipeline
validate", which is to validate the content travelling between components
by validating the SAX events themselves. O'Reilly will soon be publishing
a SAX book by David Brownell (initial author of Sun's XML parser) that
describes this type of functionality.
You don't need to include validation features in Xindice itself because
the packages required to support Xindice already provide those features,
and any application built upon Xindice *by necessity* must parse and
process XML content. All XML content going into Xindice must at minimum
be well-formed XML -- that's structural validation at its most basic. If
further structural or content validation is needed, set the parser
factories to produce validating parsers, and then provide the schemas.
To put these features into Xindice itself would be redundant and
unnecessary. Xerces is already doing it.
Now, one thing I can think might be quite valuable would be to create
some utility classes/methods that could be used generally within Xindice
to provide either DOM Document- or Node-level validation at any stage
within the process of managing content. I'd be happy to even contribute
to such an effort. If this is of general interest, writing up a set
of requirements would be a good start.
Murray
...........................................................................
Murray Altheim <mailto:murray.altheim@sun.com>
XML Technology Center, Java and XML Software
Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025
Corporations do not have human rights, despite the
altogether too-human opinions of the US Supreme Court.
