Syd Bauman wrote:
> Hi Martin!
>> ... I would really like to see more encouragement for users to
>> stick to standard TEI schemas (along with tutorials and examples
>> showing them how to do it) in place of encouragement that they leap
>> into customization at the first sense that the standard tagsets
>> won't do exactly what they want.
> I agree wholeheartedly (so long as sticking to the standard TEI
> schema still permits them to accurately describe the features of
> their documents they want to encode). But that's not the point, here
> -- we're talking about whether or not documents that conform to a
> schema that has been appropriately extended (i.e., there is not
> already a TEI element that will do the job, ODD was correctly used,
> etc.) but do not conform to 'tei_all' can be called "conformant" or
> not. I believe quite adamantly that it is important that the answer
> be "yes". This does not mean I think there is no benefit to creating
> documents which conform to 'tei_all', just that said benefit is not
I guess we're arguing about terminology, then. So whatever the word
for "validates against tei_all", meaning that any customizations amount
to deletions or additional constraints, then that's the thing I'd like
> Note, BTW, that if the definition of conformance were to include
> validity against 'tei_all', then no document that uses elements from
> another namespace (including SVG, Mr. IMT :-) would be a conformant
> TEI document.
Not if tei_all were to explicitly import the <svg:svg> as a child of
<figure>, surely? Multiple-namespace documents are perfectly valid, and
I think they actually help when it comes to long-term portability; when
a future processor which knows about tei P5 processes a document with
svg elements, it can gracefully decline to process that element and its
children, or it can invoke another module or external system which
already understands SVG 1.1 to do it. Either way, it has less actual
work to do than it would if (for instance) P5 had its own vector graphic
modules of a complexity comparable to SVG.
>> ... I know there have been cases in the past where I've made
>> customizations I didn't need to make because I couldn't figure out
>> from the guidelines how to do what I was trying to do.
> Indeed, I know there have been such cases, too, and this is a very
> strong argument in favor of lots of things including more tutorials,
> better examples in the Guidelines, more workshops, etc. But it is not
> an argument (at all) for disallowing customization.
I certainly don't want to disallow customization. In fact, I think it's
an essential part of helping TEI evolve; expressing proposed new
elements or attributes as an ODD customization (e.g. my application
-- hint hint :-) is a great way of explaining and testing modifications,
and there are undoubtedly many situations where it's essential to
customize. Furthermore, the ability to constrain your schema -- make it
simpler, but still validate against tei_all -- is something that will
help lots of markup workers who struggle against complexity. I just
think that customization which results in documents that don't validate
against tei_all should be a last resort.
>> * I think interchangeability matters because the long-term survival
>> of our documents will depend, not on whether humans can figure out
>> from their ODD files how to use them, but whether automated
>> systems can use them. If the majority of TEI documents twenty years
>> from now use customized schemas that mean that they can't easily be
>> used by automated systems, then I fear TEI will end up obsolete.
> I completely disagree. It is a given that long term survival of
> automated systems is not going to happen -- or at least, that we
> should act is if any particular piece of software will be useless in
> some number of years. The documents that survive will be those that
> are well enough defined that a future geek can easily figure out how
> it should be processed, even though *everyone* uses LMNL, and no
> commercial company has supported XML, let alone TEI, for years.
My gut feeling is that people will rarely take the time to examine
individual schemas and figure out how to process them; more likely,
they'll examine well-defined and widely-used schemas (such as XHTML 1.1
or Docbook, and hopefully P5 tei_all) and write processors that can
handle documents that conform to those, and the rest will fall by the
wayside unless they're very important for some reason. Anyone writing an
automatic harvesting system to do a particular piece of research, build
a metadata database or something similar is unlikely to care about my
little collection of a couple of hundred documents enough to examine my
But this is futurology, based on the assumption that 640K of RAM is
enough for anyone...