On Sun, Mar 01, 2015 at 03:16:06PM +0100, Thien-Thi Nguyen wrote:
> Looks like Texinfo 5.0 shipped w/ texinfo.dtd 5.0 -- that's
> fine. Even Texinfo 5.1, / DTD 5.0 is acceptable as the DTD did
> not have any substantial (non-comment) changes. The problem,
> then, arises for Texinfo 5.2 / DTD 5.0, as DTD 5.2 shows some
> substantial changes:
>
> Here is the relevant excerpt from configure.ac which assigns the
> variable that holds the eventual DTD version number:
>
> # version for the dtd. It is manually set to the next version number
> # rather than $PACKAGE_VERSION as soon as the DTD is modified. There
> # are 3 reasons for that:
> # 1. to avoid using a DTD from 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 highly improbable, but who knows.
> # TEXINFO_DTD_VERSION=$PACKAGE_VERSION
> TEXINFO_DTD_VERSION=5.0
> AC_SUBST([TEXINFO_DTD_VERSION])
>
> Obviously 3. has been proven invalid; there were indeed changes.
But was true for 5.0 - 5.1 and more generally for releases without
changes in the Texinfo language.
> For 2., probably we can fix the testing infrastructure to paper
> over that kind of difference.
That's doable, but I ma not sure this is would be a good thing.
> Perhaps we can even reify such
> fixes by publishing official changes to tp/maintain/catalog.xml
> and relying on the inherent redirection "technology" (i don't
> know for sure; i dread digging too deep into all things XML).
I didn't understand that part...
> For 1., well, that's the exact situation we are in now: makeinfo
> 5.2 produces XML that calls for DTD 5.0. I don't know (yet --
> still poking around) if that is acceptable, but it certainly is
> confusing, especially after noting that DTD 5.2, ignored as it
> is, is anyway online in its canonical location (www.gnu.org).
It is not acceptable, as the new elements of the language will lead to
invalid XML.
> So, for next release, i think there needs to be first, a more
> rational (or realistic) policy on how ‘TEXINFO_DTD_VERSION’ is
> to be updated, and second, that policy should be applied and the
> change (in policy and deed) noted in NEWS as a bugfix.
I agree that something needs to change. I think this should be in the
release process that the decision to change TEXINFO_DTD_VERSION or not
is done.
I propose a patch for Makefile.am to add a target that compares the DTD
found on www.gnu.org with TEXINFO_DTD_VERSION and the dtd in util.
> Personally, i think synching it w/ ‘PACKAGE_VERSION’ is TRT, but
> i am new to Texinfo hacking so maybe i'm missing something.
I am personnally not in agreement with that. Texinfo DTD is tied to
the Texinfo language, not to the texinfo software. Of course in most
cases, changes in texinfo software is a change in Texinfo language, but
it is not systematic.
--
Pat
Index: Makefile.am
===================================================================
--- Makefile.am (révision 6166)
+++ Makefile.am (copie de travail)
@@ -83,6 +83,11 @@
long-checks:
cd tp/tests && $(MAKE) long-checks
+check-dtd-changes:
+ $(MKDIR_P) tp/maintain
+ (cd tp/maintain && wget -N
http://www.gnu.org/software/texinfo/dtd/$(TEXINFO_DTD_VERSION)/texinfo.dtd)
+ -diff $(DIFF_U_OPTION) tp/maintain/texinfo.dtd
$(srcdir)/util/texinfo.dtd
+
# From coreutils.
# Verify that all source files using _() are listed in po/POTFILES.in.
# Run this before making pretests, as well as official releases, so that
