Print

Print


I don't think anyone disagrees that this constitutes correct and 
appropriate practice. The TEI (we always say) is designed to be 
customized, and customization can mean extension as well as subsetting. 
Where there does seem to be disagreement is about the terminology. We 
use the words "clean", "unclean", "conformant" and the like with varying 
intentions and varying degrees of precision. That needs to be addressed.


On 13/04/17 19:35, Martin Holmes wrote:
> 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.)