Lists Home |
Date Index |
From: "Mike Champion" <email@example.com>
> I'm under the impression that managing schema evolution
> is a Hard Problem; lots of the complexity
> of WXS is there to make the problem more manageable by employing
> notions of partial re-use that come from the OO world, but it's
> not clear to me that best practices have emerged for using it.
Hard Problems are often merely inadequately analysed problems.
For example, why should we expect that "Schema evolution" can be
be solved by a single mechanism?
There are many ways that a schema may evolve, and different mechanisms
may be suitable for each way. For example, change over time,
change between locales, change between processes in pipelines,
change depending on what the user is interested in, minor changes/major
Schematron's <phase> element provides an inline mechanism to
allow single source schemas which cope with gross schema changes,
for example, and someone suggested a <stage> element for use with
WXS with similar properties. This copes with many of the issues
mentioned, but it does not cope with minor changes and it becomes
complex when trying to use it to solve multiple issues at the same
time (i.e., <phase> is good for progressive validation and for
localized validation, but to use it for both at the same time results
in too many phases.)
Namespaces do not provide a way to manage evolution. Until there is
a way to name, version, sign, seal and deliver schemas for particular documents,
rather than (or, as well as) providing hints, WXS & DSDL cannot cope
with change outside proprietary management tools.