On 8/22/2011 8:13 AM, Doug Reside wrote:
[log in to unmask]"
Patrick Durusau wrote:
1a. Is the TEI about "interchange?"
Rather than setting users up for the disappointment of expecting to easily
benefit from the texts of others or to create texts that are going to be
snapped up by other scholars, let's be realistic about the difficulties of
interchange, under the best of circumstances and not make it a selling point
for the TEI.
I agree that the TEI is all but useless for interoperable *anything*
at the moment, and I likewise acknowledge that even relatively more
interoperable markup languages such as HTML still suffer greatly from
differing interpretations by software that either ignores the standard
(IE) or interprets it in slightly different ways (Firefox vs Chrome).
Thankfully IE is catching up and the increasing specificity of the
HTML5 specification at least makes it less likely that the other
browsers will persist in small distinctions.
[log in to unmask]"
On 8/21/2011 9:06 PM, Patrick Durusau wrote:
Still, if we give up the goal of interoperability as a central, even
primary, goal of the TEI, then I see no reason:
* to use it,
* for any institution to support it, or
* for any granting agency to recommend its use.
Without a goal of interoperability, I might as well create my own tags
that won't force me to spend a lot of time looking for the appropriate
tag for the textual feature I wish to identify.
[log in to unmask]" type="cite">
Let me use an example from some of my current work: ODF. Users are
unpleasantly surprised that texts can indeed be loaded in a
variety of applications (no names please!) and the displayed
results are different. Now, ODF folks will say, but the texts are
"interoperable," even if they display differently.
I also agree with these sentiments.
I would suggest two interrelated avenues to improve this:
1) Make the guidelines more prescriptive.
If people think that there is no real need to stick to a particular
manner of implementation, they will more likely force their own
meanings onto the tags. As in literature which may tolerate and even
welcome innovation, violating conventions too strongly, even where
still left understandable, is jarring; it IS a kind of violation of
"interoperability" (as in violating Paul Grice's maxims of discourse
too wildly) even if the differences are only related to differences
in expected formatting, and just as in language, people should feel
some community pressure to get things right.
I should clarify, however, that by being prescriptive, I do not mean
being overly rigid (or failing to be more flexible) as far as where
it may be reasonable to allow tags to be placed; I hope TEI will
remain at least as flexible as it is now in terms of the default
But if even one of the editors of the XML specification is arguing
for people not to invent new XML languages (http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages
), I think it has become clear that customization of schemas--for
anything except for ensuring a project does not get too ambitious or
to ensure it remains interoperable with tools meant to work only on
a subset of TEI--in other words for anything besides reducing the
available markup--is hardly a desirable goal. If people really want
to invent their own languages, no one is stopping them, but I
believe the guidelines ought to save people from themselves when
But such prescriptivism cannot happen in a vacuum, as the desire to
work properly in real-world tools should be the primary impetus for
encouraging interoperability (see #2).
2) Along the lines of #1, while preserving the admirable commitment
to separating structure/semantics from formatting, the guidelines
and/or reference pages could point to the TEI stylesheets to
indicate how each element will end up being structured and styled
within the default stylesheets.
If the Board might be willing to incorporate or adapt such work,
within maybe a month, I should have found enough time to complete
the other half of the work I am doing to describe Sebastian's XHTML
stylesheets in the vernacular so that less technical users of TEI
may be able to understand some of the likely interpretations which
will be made of their however semantic markup when converting to
HTML (and so that more can participate in offering feedback on what
default behavior is reasonable, including possibly simplifying by
replacing HTML with CSS where possible and enhancing, by adding more
(ideally round-trippable) optional HTML5 Microdata if not RDFa
I think this is particularly critical given that the stylesheets are
currently the most prominent tool for which interoperability shows
itself to be advantageous. That is not to mention the need for
awareness among editors of the various formatting hooks provided in
the stylesheets (e.g., how they may use particular uses of @rend to
ensure tags get formatted in a particular way without tempting
editors to manipulate the original markup).
Note that the stylesheets are (or ought to be) primarily building an
HTML structure, and a reasonable default CSS styling. And although
even the HTML may have its own default styling, as with TEI XML, CSS
can override default formatting and control a document's rendering,
so one need not be concerned that specifying a transformation into
HTML will cause a project to lose control over its formatting; on
the contrary, its control within HTML+CSS would allow any web
designer to be able to shape its appearance (ideally through CSS
alone, as one typically does not want designers to be able to
accidentally alter the structure or semantics of a
document)--without losing any semantics of the XML encoding.
And it would be producing TRUE interoperability, by working within
the syntax and structure (though not bound by the limited built-in
semantics) of the no doubt most used language specification on the
I may even go so far as to recommend that future guidelines
increasingly emphasize Microdata/RDFa usage within X/HTML, appealing
to a wider community of users, and relegating the XML to those who
wish to prepare the markup in a conveniently less verbose manner,
though I hope this latter idea, if rejected, will not detract from
the preceding ideas which are independent of this one.