Peter N. Lundblad wrote:
>
> NOt to seem ungreatful, but I'm not sure we want this duplication in the
> repository. It's not a big file, but it still needs to be maintained. If
> we change the schema in some way, we need to modify both files and keep
> them correct.
That's two separate points.
1. Maintenance. Part of the point of having those schema and/or DTD files is
to act as regression tests to validate our XML output. That's a benefit, not a
hindrance. At the moment such validation is done only in an ad-hoc way when
someone feels like it, which isn't good enough. It's time we added an
automatic regression test for it. This could look for one or two popular
validation tools such as "xmllint", and run it if available on the system, else
skip the test.
2. Duplication. DTDs are really very weak. I wouldn't have used them except
that schemas weren't standardised and tools for them weren't common when I
needed to learn one or the other a few years ago, so I never got around to
learning shemas. Now that schemas are standard and validating against them is
easy, they are definitely the better choice. That only leaves us with the
backward-compatibility concern: since we have been providing DTDs, it would be
polite to continue to provide them. If we provide schemas as well as the
existing DTDs, and if we have automatic regression tests that validate our
output against both of them, they will occasionally need to be updated to add
new features, but the additional burden of updating the corresponding DTD at
the same time as a schema is trivial since the DTDs are so simple.
The only remaining argument I can see against including schemas is that people
working on the XML output (e.g. me, sometimes) will have to learn to understand
schemas, or get help from someone who does, but I think that's quite a
reasonable requirement and for most changes they won't need a deep understanding.
I am only a novice in the XML world, but the impression I get is that DTDs are
considered old-hat.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 30 23:15:32 2005