Print

Print


Hello,

On 8/22/2011 8:13 AM, Doug Reside wrote:
> 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.

> 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:
>
> 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,
Brett