[EMAIL PROTECTED] wrote:
<snip/>
> 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.
Well, if the data that comes out is different from the data that came in
(think of aggregation!), you need validation in both ways to ensure
complete integrity.
At the same time, if aggregation is performed using 'internal symlinking
nodes' validation can be performed when entering the document (after
augmenting the infoset with the aggregated data).
The same can be said even for XQuery aggregation, if XQuery templates
are known to the DB: it could be possible to perform validation when
entering a document by looking at those queries that 'cross-cut' that
document, perform them and validate the resulting documents.
> 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.
Hmmm, not sure this is entirely possible. I'll have to think more about
it.
> Performance should be a concern but not such a large one to negate the
> need for server-side validation entirely.
Absolutely agreed, validation is a much have, but I'm still not sure
*where* (I mean, at what level) it should live.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
