Re: advantages of TEI

I agree wholeheartedly with James here, but I also think that it would 
be extremely beneficial if projects provided their XML not only in the 
project's own format but also converted to a range of different, more 
generic TEI schemas, as I described at DH 2015:

<http://dh2015.org/abstracts/xml/HOLMES_Martin_Whatever_Happened_to_Interchange_//HOLMES_Martin_Whatever_Happened_to_Interchange_.html>

and as we do at the Map of Early Modern London project:

<http://mapoflondon.uvic.ca/map.htm>

where if you click on "See XML", you'll find five versions you can 
download. If you have a publication engine that handles (say) TEI Lite, 
you should be able to grab a TEI Lite version of a project's XML and 
push it into your publication engine. I believe it's preferable for all 
sorts of reasons for the originating project to provide such 
conversions, rather than forcing the end user to write them.

Cheers,
Martin

On 2016-11-02 09:49 AM, James Cummings wrote:
> Hi Eduard and Serge,
>
> One of the approaches I think more generalistic TEI software development
> should take is specification of input formats and provide generalised
> conversions from tei_all to the subset that the software does something
> useful with. (Ok, this is perhapsless relevant for things like TXM,
> general editors, or database frameworks.)  But if we imagine a new tool
> to display, visualize, or process TEI there is no reason it should
> necessarily cope with the whole of the TEI. It can use the TEI ODD
> customisation language to specify a meta-schema that it can handle. (And
> as Magdalena was noting including processing model information in that
> so it could act as a sort of configuration file for that processing.)
> If your software won't do anything with <w> elements and just ignore
> their existence then don't include them in the schema and let people get
> errors/warnings about them.  If you have a fixed list of @type
> attributes your software expects on <name>, then document that in TEI
> ODD. And then through schema errors or schematron warnings a user can
> test if their source documents are processable by that bit of software.
> Even better if there is then a tei_all to MySpecialSoftware conversion
> script which throws away all the stuff this piece of software is going
> to ignore or fail on.  I know the next question will be why are we
> encoding it if we then throw it away -- and clearly the answer is we may
> throw it away for _this_ bit of processing or visualization or whatnot,
> but that doesn't mean it isn't crucial for other bits of analysis and
> research.  So your TEI Zero, for example, I can validate against its
> schema and if I don't get any warnings then I know that your software
> won't have a problem with it. If I do, I can judge if they are errors,
> or warnings like  -- "Your <name type="thingy"> will be treated as <name
> type="other"> in our software" -- then I can make an informed decision
> about how the software will work with my texts or whether I should
> convert them to match your values. I realise, of course, some people
> already do this, but it may be worth reiterating as it seems a lot more
> practical than people trying to develop software that will cope with any
> of the TEI vocabulary (never mind new things a project adds...).
>
> -James
>
>
> On 02/11/16 14:14, Serge Heiden wrote:
>> Hi Eduard,
>>
>> Le 02/11/2016 à 12:46, Eduard Drenth a écrit :
>>> TEI offers flexibility and freedom (i.g. <span type="lemma"
>>> target="w1 w2"> instead of <lemma target="w1 w2">) that complicates
>>> tool development. How big of a problem is this?
>> From an IT perspective, working with TEI encoded texts is like
>> catching chameleons hopping in XML trees.
>> If you work with people feeding chameleons, you can negotiate some
>> synchronized convergence of colors.
>> Not necessarily the colors of the chameleons themselves (aka local
>> encoding guidelines) but at least how
>> you are supposed to see them.
>> We develop a text analysis and publishing platform called TXM
>> (http://textometrie.ens-lyon.fr/?lang=en)
>> with which we regularly use this strategy through XSLT adapters to
>> help colleagues analyze and publish their TEI texts.
>> Often because projects tend to encode their texts before choosing a
>> final analysis and publishing platform.
>> However, it is not easy to choose a TEI aware analysis and publishing
>> platform (established software or adaptable framework) because it is
>> not easy to specify what analyzing and reading mean.
>> A kind of "chicken or egg" dilemma, with chameleons...
>> See this tutorial for TXM TEI import strategy introduction and
>> examples (sorry for French):
>> https://groupes.renater.fr/wiki/txm-users/public/tutoriels_import_xml-tei
>>
>> Another strategy is to negotiate convergence to a manageable subset of
>> TEI like TEI lite, tite, simple, zero...
>> (we are designing the latter for TXM work).
>>
>> Best,
>> Serge
>>
>> --
>> Dr. Serge Heiden,[email protected],http://textometrie.ens-lyon.fr
>> ENS de Lyon/CNRS - IHRIM UMR5317
>> 15, parvis René Descartes 69342 Lyon BP7000 Cedex, tél. +33(0)622003883
>
>