texinfo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DTD version confusion


From: Karl Berry
Subject: Re: DTD version confusion
Date: Mon, 6 Apr 2015 00:04:46 GMT

Continuing on this list from a month ago on bug-texinfo ...

> Yes, TEXINFO_DTD_VERSION [in configure.ac] should have been set to 5.2.

In rereading the comments from configure.ac (my draft version below, not
yet committed), I see that our idea was to update TEXINFO_DTD_VERSION
there as soon as texinfo.dtd is nontrivially modified in development.
Ok.  And, further, to set it to the version of the next official
release, in the present case 6.0, rather than changing it with each
pretest.

So, my question is: isn't it problematic when the xml files produced by
the development/pretest version refer to a nonexistent dtd?  It seems
like a resulting .xml file, if actually tried to be used (by pretesters
or other contributors), would be invalid since the dtd is not present in
the expected place.

This is why I previously updated the DTD version for the pretests (and
put the dtd out there on the web), and then again for the real release.

Nowadays, I'm thinking we could use TEXINFO_DTD_VERSION=5.2+dev for
development and pretests, and use the svn repo for the url in the DOCTYPE:
<!DOCTYPE texinfo PUBLIC "-//GNU//DTD TexinfoML V5.2+dev//EN" 
"http://svn.savannah.gnu.org/viewvc/*checkout*/trunk/util/texinfo.dtd?root=texinfo";>

(Or, if it matters, use a www.gnu.org url and update it with every
commit, instead of the svn repo url; that's a minor detail.)

Then set TEXINFO_DTD_VERSION to the real release when it is time, I
realize that would mean updating the test results for the actual
release, which is a drag, but ... creating invalid xml files also seems
bad.  If they really are invalid.  Hence my question.

To reiterate one other thing, all this is only relevant if there are
real changes to the DTD.  Until there is, nothing need be done and the
TEXINFO_DTD_VERSION can stay at the last official release.  As discussed ...

k

# TexinfoXML DTD (./util/texinfo.dtd) version: manually set this
# to the next version number rather than $PACKAGE_VERSION, as soon as the
# DTD is modified.  Several reasons:
# 1. to avoid using a DTD from the Internet that wouldn't be in sync;
# 2. to avoid unnnecessary changes in XML output file headers, in
#    test results for instance.  Otherwise after a release the 
#    devel version and the pretest versions would be used;
# 3. it may be kept as is in case there were no change in the DTD
#    between releases.  This is uncommon, but possible.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]