-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Murray Altheim Sent: Tuesday, January 15, 2002 4:36 PM To: xindice-users@xml.apache.org Cc: [EMAIL PROTECTED] Subject: Re: Future of Xindice
Tom Bradford wrote: [...] > There are a few of things that need to be addressed in future revisions > of Xindice. I'll run through them very quickly, and then I'd like to > hear people's feedback. > [...] > Schema support > ----------------------- > We need to support schemas in an abstracted fashion. If we can > architect a content model API that would allow the system to validate > and operate against a content model without needing to know that the > content model is based on XML Schemas or Relax NG, that would be ideal. Why in Xindice? There are several places where validation can occur: 1. upon storing in the database; 2. following an XUpdate; and 3. upon retrieving content from the database. In all three cases, the DOM nodes to be validated are already available to the developer outside of Xindice and can be validated using existing validation tools and techniques. Not that I'm going to fight the issue, but I'm rather against including support for schema validation within the Xindice, as this is an application- level issue (as I've described in previous messages). There are many different types of schema validation, and different validation needs, eg., different levels of strictness or different content validation at various places within a processing regimen. Validation is a complicated issue that doesn't have a one-size-fits-all type of solution. There are a plethora of validation options out there and I don't see that one API could serve the variety of schema languages, structure and content validation needs that would be within a reasonable scope of effort. You'd be tackling the same issues that the W3C Schema WG tackled, with the "data heads" and "document heads" needs on the table. Perhaps I'm just being daft, but I've never followed the reasoning on why anyone would *need* to include further validation functionality *within* XIndice. It only seems to add redundant complexity to the package. Those who know my history in the markup field know I'm a big advocate of validation, but this is one place I wouldn't support its inclusion, code-wise. If anyone is unclear as to how to provide Java-based XML validation within their application, I'd be happy to suggest several books and available software packages. In passing I should mention that Sun has released binaries and source code for a Multi-Schema XML Validator, which we demoed at XML One. This tool can work on the command line, can be integrated into applications, and can even act as a SAX pipe validator. http://www.sun.com/software/xml/developers/multischema/ It supports RELAX NG, RELAX Namespace, RELAX Core, TREX, XML DTDs, and a subset of XML Schema Part 1. Of course, DTD and XML Schema validation is built into Xerces 2, which is already part of the Xindice distribution. On this point I disagree. I think it not only appropriate to validate in XIndice, but critical. The reasons for so doing is the same for why there exist triggers, foreign-key constraints, check constraints, and the like. If validation occurs close to the data store (i.e., within the application storing the data) then all applications using the data store can rely upon the validity of the data once stored. Experience is too great a teacher for us not to conclude that there will be multiple applications accessing the same collection. While, if we are the author of one application, and have taken the appropriate care and properly validated the documents as we work with them, we can have confidence in our application; we'll never be sure that the other applications sharing our data will do likewise. I have become weary of dealing with too many 2-bit Visual Basic applications sharing data in a Microsoft Access database. Anyone who has had to deal with integrating and up scaling applications of this nature will understand. I much prefer working with "real" databases which can enforce the referential integrity (in the data store). To fail to include validation in Xindice is to condemn it to irrelevance. Developers of the 2-bit applications will love it because it will allow them to put their data in another "dumb" data store. The relevant difference this time is that Xindice would store XML as opposed to Access storing relational data. Developers of enterprise applications would shun it because can't offer these guarantees critical to substantial applications.
