Respectfully, I do not think there is a problem here. Or if there is,
it is a natural, normal and predictable problem that has no solution.
But it can be managed, and indeed you appear to managing it well.
Understand that I write with no authority at all. I haven't been
assigned to any committees or councils. My position is only my
accustomed role as "TEI gadfly".
As I see it, your point can be restated as a problem of specification
and validation. As you know, this is a vexed area; indeed, the TEI
Guidelines stipulate that it is not even always possible to determine
whether a given XML instance is "TEI conformable" (meaning, as I
understand it, that a TEI-conformant ODD for it is mathematically
possible even if none has been written). The problem stems from your
implicit acceptance that specifications assumed by the current version
of the public stylesheets are in some way normative -- that if your
data doesn't work correctly with them, it is somehow the data that is
in error. Problems are never due to the new processing (on the
contrary, "bugs" have been "fixed"); and processing always reflects
deliberate policy decisions on the part of the TEI, rather than simply
an evolution in the interpretation of TEI by its diligent authors.
This may be a defensible position (at least intellectually) but I'm
not sure it's one the TEI takes. On the contrary, at least some of us
have assumed for a long time that you can have conformant and correct
TEI documents that don't work perfectly nicely in the public
stylesheets at all, and their conformance is ensured and validated by
other means. Among other things, this means that TEI projects are not
bound to the treadmill you describe, whereon every improvement to the
public stylesheets potentially destabilizes your work.
It does have to be admitted, however, that such a view does bear on
perennial questions regarding the interoperability of TEI systems and
interchange of TEI documents, as it implies that such interoperability
is not the primary goal, or in some cases even an important one, of
all this work in aligning our practices with one another. My own view
on this is that interoperability and interchange are not simply
either/or -- that one can have (and be rewarded by) a significant
degree of what could be called "soft interoperability" even when data
interchange is not perfect (what has been called "blind interchange")
-- and even that such an 80% amounts to civil society, when 100% would
be an intolerable (and unsustainable) tyranny. But apparently such a
view is too nuanced to gain much currency, even while most of us work
in ways that more or less assume it.
Nevertheless I submit that your own discomfort might be relieved a
little by knowing that (1) it is not at all universally accepted that
all conformant TEI data must always work well or even at all with the
public stylesheets, and (2) that if you decide to use them, your
policy of periodic "freezes" at stable points seems (to me at least)
to be prudent and exactly right.
On Wed, Dec 12, 2012 at 10:51 AM, Louis-Dominique Dubeau
<[log in to unmask]> wrote:
> 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.
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables