Re: advantages of TEI

And I agree wholeheartedly with your statement about the designated 
generic output format being a responsibility of individual projects, and 
will be happy to reread your paper (thanks).

I would even venture further:
* (dangerous) For some projects, the promise providing export to at 
least one TEI-blessed formats (even if it ends up somewhat lossy), 
should be a pre-condition for financing.

* (not dangerous) An online validator for those special generic formats 
(in their vanilla versions) would be great to have.

Best,

   P.

On 02/11/16 18:11, Martin Holmes wrote:
> 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
>>
>>