Re: <p type="I_wish">

Le 09/10/2016 à 01:36, Martin Holmes a écrit :
> and it has the slight advantage that while the documentation of your @type value, if it exists, will typically be in your schema, the documentation @ana points at may be in the header of your file. 
> You can also use multiple pointers in @ana, allowing a more flexible and layered approach than is possible with @type and @subtype.
>
> This argument obviously applies to a lot of situations in which @type and @subtype are used, but I tend more and more to the opinion that we should be using more pointers like this and fewer 
> enumerated (and often sparsely-documented) @type values.
Let's say @type attribute (and @subtype) is an encoding tool to use when your typology is not completely settled (project infrastructure with lots of people, lots of years; or preliminary encoding 
requiring low infrastructure pressure - and getting low services in return) and you want to get the benefit of a flexible (and fragile) tool;
Let's say @ana is a tool to use when your system is more organized and you want to get the benefit of some more formal tools (pointers).
Then any TEI element having @type should get @ana (which should already be the case) and any element having @ana should get @type (like p).
With this, the encoder could choose to start its encoding at the @type level or directly at the @ana one.
The relation between the @type and @ana attributes would be somewhat analogous to the one between the bibl and biblStruct elements (a 'model.typeLike' class analogous to the 'model.biblLike' class on 
a more abstract level).
With such an encoding infrastructure we could design tools to help people synthesize their @type encoding practice and automatically suggest @ana encoding strategies.

Cheers,
Serge

-- 
Dr. Serge Heiden, [email protected], http://textometrie.ens-lyon.fr
ENS de Lyon - IHRIM UMR5317
15, parvis René Descartes 69342 Lyon BP7000 Cedex, tél. +33(0)622003883