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.
[log in to unmask]" type="cite">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.
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
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.)