Print

Print


I'm one of the people who's inclined to resist the idea that extensions 
of the TEI should be described as conformant. My main reason is this:

The TEI becomes more useful for more people and projects as it gains new 
features and refines the ones it has. If your project has a need for a 
new feature, this is the process that I think should take place:

1. Read the Guidelines carefully to make sure that what you want to do 
really isn't supported (and check with TEI-L).

2. Implement it as a temporary extension in another namespace in your 
project.

3. Put in a feature request to the TEI, giving your temporary extension 
ODD fragment as an example.

4. Participate in the discussion that eventually leads to a collective 
decision for an implementation.

5. Change your project ODD and data to use the standard implementation 
and become fully conformant.

I don't think there's anything wrong with extending the TEI at all, but 
I think if it's encouraged as an all-around Good Thing, the result will 
be a multitude of projects with divergent idiosyncratic extensions which 
inhibit interchange, while the TEI standard fails to evolve to handle 
the new needs.

For the record, I've done variations of #1-#5 above several times; it 
takes a while, but it typically works well, and everybody benefits.

Cheers,
Martin

On 2017-04-13 10:38 AM, Syd Bauman wrote:
> I vaguely remember that REXX book ('twas the one with a playing card
> on the front, no?), but I also don't recall how it differentiated
> text that was intended for one track from the other.
>
> But more importantly, it is *very* important that a conforming use
> of TEI be allowed to add attributes and elements to the vocabulary.
>
> My take on reality is that a lot of people out there in the world
> would prefer to avoid doing so. I'm not sure if that's because they
> find using ODD too hard (and if so is that because our documentation
> is not good enough), or don't want to deal with multiple namespaces,
> or think no one will like them (particularly their funding body) if
> they add something to their schema. But rest assured, it is a normal
> and accepted practice.
>
> (Of the half-a-dozen or so main TEI customizations we use at the WWP,
> three have added elements or attributes.)
>
>
>> Tw similar examples from the 20th century: when the programming
>> language REXX was introduced for IBM mainframes, at least one of
>> the manuals (probably the User’s Guide) explicitly marked two
>> reading paths, one for the first reading covering key concepts and
>> avoiding some details, the other (a superset of the first, if I
>> remember correctly) including discussions of details and less
>> crucial topics. I no longer recall how the two were distinguished
>> (arrows and instructions to skip to section n.m? or type size? or
>> …?).
>>
>> And the TeX and LaTeX books explicitly mark some material with a
>> ‘dangerous curve’ icon to signal that it may safely be skipped for
>> introductory purposes.
>>
>> Like Martin (Holmes), I see that this could be captured with divs
>> and a strong stomach for a very broad interpretation of div. Like
>> Martin (Mueller), I think I’d rather use an attribute on p (or two
>> distinctive element types); it doesn’t feel at all div-like to me.
>>
>> My instinct would be to say this is a good example of why it’s
>> important that conforming uses of TEI be allowed to add attributes
>> and elements to the vocabulary, but I have the impression that not
>> everyone agrees that extending the Guidelines should be a normal
>> and accepted part of using TEI. (TEI P3 was itself a conforming
>> instance of TEI P3, which extended and modified the vocabulary
>> slightly as a way of underscoring the point that extensions and
>> modifications are not shameful or undesirable. At least, that was
>> what at least one of the editors thought and said.)