Re: Errors in MathML DTD

> Well, as has been mentioned, fetching it over the network is not optimal --
> especially since the Validator may well have been installed behind a
> firewall without access to the outside world at all -- so we do need to
> keep a complete local copy.

yes understood, I would not expect you to fetch it over the network
I had thought you may have had access to a local cvs checkout on the
local disk but as has been made clear that isn't the case in general.

> IIRC you generate the DTD using XSLT or some similar method, and this has
> in the past generated a DTD with a physical layout on disk which is
> significantly different from the previous version despite having only minor
> logical changes (e.g. at one point I think the directory structure actually
> changed in such a minor revision!).

The main dtd files are hand authored directly in dtd format.
The entity declaration files are generated by xslt but
I don't believe that the format or relative path from the
main DTD changes at all, other than some changes between mathml 1 and 2.

> Since we need to keep the DTD in CVS, this becomes a practical problem;
> both in terms of having to do a lot of shuffling around of files when the
> directory structure changes, and in terms of actually tracking what changes
> have occurred between versions.

Yes we use cvs as well and as you say renaming/moving files in cvs is
compartaively a pain compared to updating them which is easy.
But I don't believe this applies here. For at least the w3c versions of
the validator I assume you could, if you wished, just get direct
read-access to the cvs server where the files are sitting and check them
out of there.

> That would be very helpfull, as Nick has mentioned, and letting us know
> when changes occur in the DTD even more so. Experience seems to indicate
> that trying to track these updates "from the outside" does not work very
> well; or at least I have not been able to do a very good job at it.

Historically almost all changes to the DTD have been changes to the
entity definitions, to track unicode proposals and the final unicode 3.1
and 3.2 releases, of course for validation purposes the entity
definitions do not matter, changibg it from one private use area
character to a newly allocated unicode 3.2 slot will not change whether
or not any instance is valid. But I will drop a note to the validator
list whenever it changes (hopefully it won't change again now, but you
never know what comments may come in in the current "last call" review

> In a slightly longer perspective, we've been tossing around the idea of a
> "W3C DTD Collection" project to collect all the currently relevant DTDs in
> a single convenient place (including some documentation and a consistent
> directory structure etc.).

Makes sense to me. Apart from the directory/web site layout I have long
been pushing for a "grand unified entity definition" set that would
not be so closely tied to mathematics and would be consistent between
mathml and xhtml on the w3c side and also docbook and tei etc further
wide. Currently no two of those have compatible entity definitions
(see a long diatribe on this at


Received on Sunday, 20 April 2003 05:06:23 UTC