[
Lists Home |
Date Index |
Thread Index
]
From: "Sean McGrath" <sean.mcgrath@propylon.com>
> I''ve learned from bitter experience that doing XML processing monolithically
> for efficiency reasons is almost always a bad idea.
Processes that are needless coupled are monolithic. The visitor pattern uncouples
the visiting from the processing; it creates an interleaved layer rather than relying on
separate processes in series.
> I find again and again that if you design and implement
> loosely coupled XML systems - ignoring efficiency concerns - efficiency has
> a way of sorting itself out without adversely impacting the design.
Efficiency comes from choosing the right algorithm above all. For my concern,
which is desktop XML systems, efficiency is very important. Not all XML systems
are loosely-coupled remote processes. A person with one computer with
one CPU clicks "validate" and wants an answer as soon as possible;
indeed, they want to have it already checked in the background or continuously
updated.
> Any schema language, query language or any other XML technology that
> justifies the complexity that is concomitant with monolithic design on
> efficiency grounds should be treated skeptically.
It is just
for each document d
for-each node n in d
for-each registered-method r of n
do n.r()
rather than (worst case)
for each method m
for document d
for each node n in d
if n.m exists, do n.m()
You well be right that parallel and p2p processing can has excellent performance.
But these can only be aided by specs which can be efficiently implemented
for streams, DOMs and grids of spawning functions. Integrated and modular
schema languages does not mean monolithic.
Cheers
Rick Jelliffe
|
