On Tue, 2012-12-11 at 19:39 +0000, Sebastian Rahtz wrote:
> It's maybe worth people knowing that these stylesheets are managed with a test suite
> of documents, and that the release/build process checks that the results do not come out
> differently. So when the generated HTML is different in any way, the build breaks
> and I have to check by hand.
If I understand you correctly, you and I are not talking about quite the
same thing. What you are talking about is protection against *unwanted
changes*. What I'm talking about is change that is *wanted*, because it
fixes a bug.
In some cases it happens that the old release worked fine for Alice.
That it worked well for Alice was due to a bug, but she did not know
that. Then Bob puts in a bug report. The code is fixed and released,
Alice reprocesses and now it no longer looks good.
Again, I can point to our most recent back and forth re teitohtml as a
case in point. I had a file that processed correctly but it no longer
does. I did make a mistake by not specifying that I capture all
quotation marks. Still, the old release did exactly what I wanted. The
new release however requires me to go back to my TEI and fix it so that
I get the right output. Not a big deal in this specific case, but in
other cases this can mean hours of work.
Or consider structural changes like the following. This is a diff from
the output of teitohtml as of the latest release to the output of
teitohtml as of a recent update of the svn trunk, same valid TEI input
in both cases:
< <div class="p">Blah <span class="quote_inline">bluh</span>.</div>
> <p>Blah <span class="quote">‘bluh’</span>.</p>
If I used to have a CSS selector match on quote_inline, then the next
release will break that. (I presume that the rationale now is that <span
class="quote"> is an inline quote and <blockquote> is a display quote.
So there is no need to have a "quote_inline" class.) What used to be
<div class="p"> is now <p>, which could also throw off CSS or perhaps
processing of the resulting HTML. (Although given that <div class="p">
should have already been treated like <p>, this is less likely to result
in a problem.)
Now, let us consider a document being edited over the span of weeks,
months, or years. TEI releases are going to happen during that span of
time. Bugs are going to be fixed, and the chance of something being
changed which will have a unexpected effect (unexpected from the point
of view of a user) on the output of teitoX is not unlikely.
All the discussion above centered on changes to the output. Changes to
the internal design of the XSL code are also problematic to those (like
me) who create new profiles adapted to their own needs. I recall the
structure of the LaTeX templates that are called at the beginning of
processing being changed at least once in a way that required me to
update my customizations. And I also recall some of the LaTeX
hyperlinking code gaining one additional parameter being passed around
by the chain of templates that do the hyperlinking processing.
> So while the scenario of "my document is all broke, aargh" will obviously
> occur sometimes, I hope its far from common.
It causes me headaches from time to time. I've decided that the proper
response is not to scream "OMG! Roll back the changes!" but to
proactively protect myself from surprises at inopportune moments. In my
case, this means freezing the TEI tree from time to time. To take
another example, if I were a publishing outfit using any of the teitoX
tools to publish documents that are considered for the most part frozen
at the time of publication, then upon publication of the document, I'd
store the document's source files together with a frozen TEI tree so
that if 2 years down the road there is a desire to produce a slightly
updated version (e.g. slightly edited to remove typos and things of the
sort), then I would not have to deal with the changes that happened to
the TEI code base in the intervening 2 years. I'd fix the typos,
reprocess the XML using the frozen tree, proofread, and call it a day.
If I did *not* do this, I would run into changes to the TEI code base
that would require me to fix my source files or my customizations.
> As Louis will testify, I do try and respond to bug reports very quickly,
> so don't feel shy about reporting a disaster.
I do testify to that, and I appreciate it.