On 4 Jan 2002 at 9:00, Tom Bradford wrote: > Personally, and I'm just reiterating things I've said in the past, I > hate W3C XML Schemas, and many others do as well. I don't want to > have to put ourselves in a position where we're forced to make a > choice on any one validation mechanism to the detriment of our users. > So if we can continue to push validation to the client application, > that's the track we should take... for a couple of important reasons: > (1) Performance... validation is slow, Bogging down the server to > perform it can only cause problems, and (2) Choice: If we standardize > on W3C Schemas, then we exlude support for other schema > specifications. I think that's unwise, especially with the major > backlash that XML Schemas has received.
These are very valid reasons, but I think it is very important for any database to be able to offer data integrity and consistency. To me, ensuring that a document is valid against some schema, is equivalent and just as essential as rdb's ability to enforce constraints. And I would go further (in keeping with inevitable document composablity / fragment aggregation needs) and insist that inter-document consistency checking is needed. The W3C Xml Schema may well not be the best tool for this job, and I also would be queasy about tying the server to some such standard at this point in time. In an ideal future, a mature xml database would support validation against any of the major schema languages. Clearly that would be over-ambitious at this point, but perhaps the server could be equipped with hooks for implementers to install the validation mechanisms of their choice. As to performance, this may be the bias of my projects and experience, but I think performance is most crucial in the accessing / query of documents, not the writing of documents where the validation would take place. In most systems, large slow- validating documents are not going to be added to the system with anything like the frequency that accesses will take place. Frequent writes are more likely in systems with smaller more data-centric document-records, whose validation shouldn't be as time consuming. Small, frequent updates to large documents is another issue which might require the development of validation methods that don't revalidate the entire document. Performance should be a concern but not such a large one to negate the need for server-side validation entirely. Eric
