On 8/22/2011 8:13 AM, Doug Reside wrote:
[log in to unmask]" type="cite">
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]" type="cite">
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.
On 8/21/2011 9:06 PM, Patrick Durusau wrote:
[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 schema.

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 they can.

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 encodings).

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 planet, HTML.

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.

Best wishes,