[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
> Uche Ogbuji wrote:
> >This sounds like the rallying cry of the Knights of Tag Soup.
> >
> >Validation is mostly an obstacle to evolution if designed using the wrong
> >tools in careless hands.
>
> That's a great turn of phrase! Still, I guess I think of myself as at
> least the jester in the Court of the Knights of Tag Soup, so maybe I
> should ask Uche or someone else to educate me on the point.
>
> Uche's point was a response to a response to something I wrote:
>
> > 2 - Namespaces - work best for mixing instances of well-defined
> > vocabularies/schemas together, they don't work so well to support
> > evolution or un-typed XML. Schema evolution using namespaces is
> > a Known to Be Hard, TAG-level problem.
>
> I'm under the impression that managing schema evolution
> is a Hard Problem;
As with the Halting Problem, managing schema evolution is
only a Hard Problem in theory; in practice it's generally
quite tractable.
The hard problem is: "write a program that will compare two
versions of a schema and determine if all documents valid
under version 1 will remain valid under version 2."
This isn't halting-problem hard, but it's not trivial either.
In practice, the question "is version 2 of *this DTD*
backwards compatible with version 1 (in the sense above)"
is usually straightforward to answer, especially if both
versions of the DTD are designed with that question in mind.
Validation is far from being an obstacle to evolution; in
fact, it's an essential ingredient. The "works in Netscape"
test only tells you if your data will work with the current
versions of the programs you happen to test it with.
Validation against a schema tells you that your data will
work with *any* program that can process documents conforming
to that schema; and, if the schema is evolved correctly, with
any *future* versions of those programs.
(Alas, the "works in Netscape" test is still necessary
for web pages; validation alone isn't sufficient in the face
of browsers that don't implement the standards correctly
themselves.)
> 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.
I don't know about WXS, but plenty of best practices have
been devised for DTDs, most of which are equally applicable to
RELAX NG and other reasonable schema languages.
[ ... ]
> Finally, how DOES one make XML technology choices that are not fragile in the
> face of human nature? So much of traditional SGML/XML technology seems
> predicated on the assumptions underlying the "waterfall model" of software
> development.
Not really; the waterfall model doesn't work any better
for SGML than it does with anything else.
SGML is very well-suited to iterative application design,
where the markup, DTD, and processes evolve in parallel.
The DTD is the cornerstone of this approach: it specifies
the contract between the data and the processes. Keep
all three in sync and you can maintain a working system at
each iteration during initial development. At upgrade time --
when deployed processes and existing data will be out of
sync for a while -- the DTD is an important tool in
assessing the impact of the change.
--Joe English
jenglish@flightlab.com
|
