On Wed, 2013-04-03 at 16:09 +0200, Benjamin Wolff Bohl wrote:
> Can you give me a hint?
> Does anyone deal with such things?
I have not deal with the exact same problem but with similar issues. My
inclination is to add an additional tag to a "standard" TEI schema to
encode what I need. This way I can customize it as much as I want to map
to the semantics of what I'm trying to encode. If I need to have pure
TEI, like for instance if I want to use the stylesheets, I create an
XSLT transformation that normalizes my tagging to what the stylesheets
expect. And ultimately if down the road, once I'm reasonably certain
I've seen all use cases, I find that my new element perfectly maps to an
already existing TEI element, I can always eliminate the element I
Having a new tag may save some input work. The string <my:ptr
tgt="blah"/> is shorter than <ptr type="mytype" ref="uri::my:blah"/>.
(Relatively minor benefit, I know.) More importantly, it reduces the
possibility of entry error. Speaking from experience, I know that if I
were not forced by the authoring environment, I'd forget to enter
type="mytype" or the "uri::" or the "my:" bits in ref. (By "experience",
I mean experience having to retroactively fix my mistakes and the
mistakes of others.) For authoring purposes, I find there are less
errors if I use a new, different tag for the special case than having to
require that everyone remember that this special case must be encoded
specially using a tag that is otherwise not special.
Obviously, the approach I'm talking about there does not work in all
contexts. If, for instance, you have to work with an authoring system
that *only* understands the TEI tags and nothing else, then you can't do