[tei-council] on conformance document

[Sebastian Rahtz]

Syd Bauman wrote:
>                     TEI conformance is not about making interchange a
>                     trivial activity. TEI conformance is about making
>                     what you've done explicit.
>
>   
is this a quote? or a manifesto summary?

I wonder if there are 3 ways to judge a project which claims
to be doing the TEI:

 a) is it conformant, in the loosest sense, ie does it use the TEI
 as is, or with the proper extension mechanism

 b) is it interchangeable, ie does it use the TEI in ways which
 make it technically possible to exchange documents with
 others and use common tools

 c) is it semantically conformant, ie does it use the TEI tags in
 the way they were intended
> For this reason, I think
> it's very important that we not define conformance such that it
> actively discourages the customizations people need to make in order
> to use the TEI to describe what they find interesting and esoteric
> about their documents.
but there are good and bad ways of doing that.
>  This is *particularly* true in light of our
> claims that the TEI can and should be customized, and that it can and
> should be used for just about everything. We can't encourage
> experimentation on the one hand, and then use terminology that
> severely deprecates the results.
>   
I think you overstate the case; the terminology
is to let you classify what you have done, not
limit it
> E.g., for what may be the vast majority of the world's TEI encoded
> documents, those created by large-scale projects like digital
> libraries, the packaging (i.e., how the thumbnails & JPEGs are
> associated with the TEI file) is going to affect overall
> interchangeability more than the encoding itself.
sorry, I don't get this at all. Packaging is mechanical,
and easy to work around.
>  Even when the
> encoding is an issue, in many cases the problems will arise *within*
> the confines of vanilla TEI. E.g., issues like slightly different
> values for type= attributes, differing application semantics (you
> apply <persName> to all personal names, I apply it only to those names
> I've bothered keying)
well, the last one applies to all research, it's too vague
a problem.
>  and differing methodologies (<note> at anchor
> point vs. <note> points to anchor point).
>   
that can be resolved  in a mechanical normalisation, surely?
>  The list of "levels" Sebastian provides in
> http://www.tei-c.org.uk/wiki/index.php/Conformance may well be a good
> starting place for a discussion of these ease-of-interchange issues.
> But it is not a good starting place for a discussion of _conformance_.
>   
you may well be right. but in that case I think you are
making "conformance" such a loose term that it loses
any power.
> A TEI encoding that is closer to vanilla (e.g., a strict subset of
> tei_all, a 1 on Sebastian's scale) is not ex facie "better" TEI than a
> TEI encoding that is more drastically customized. 
well, that depends on the customization. in some
cases I'd argue that it _is_ better
> Yes, it may be
> easier to process with software designed for vanilla TEI, but it is
> not better if the salient features are not properly encoded. Tag abuse
> is *far* worse than customization, as is not being able to encode that
> which is of interest.
>   
I am not sure I agree. Can you give some (imaginary) concrete examples
in which someone does tag abuse because they are scared of customization?
>
> While the details are up for discussion, I think it is really really
> important that the definition of P5 TEI conformance be in the same
> vein as the P3 & P4 definition: a broad, inclusive, yes/no distinction
> that revolves around the need to make explicit the differences between
> the current document and vanilla TEI. That is, conformance should not
> be primarily about ease of interchange.
>   
we _could_ take that line, yes. but I think it would
do the world a disservice to simply wimp out
of stability for the TEI and treat it just as a language for
writing schemas, and have the only common
denominator being an element called <teiHeader>
with no guarenteed content.



-- 
Sebastian Rahtz      

Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

OSS Watch: JISC Open Source Advisory Service
http://www.oss-watch.ac.uk