On 11-08-25 01:38 PM, Julia Flanders wrote:
> ...and, we should add, there's a good reason in this case why<head>
> following<p> is not legal: in TEI, the presence of a<head> signals
> the start of a new division.
> This is relevant to Laura's point about TEI structures sometimes
> conveying a kind of wisdom--the structural requirements can serve in
> some cases as a kind of control on semantics as well. So if I look at
> a document and I think I see
> the TEI wants to educate me to see that in TEI terms as
> and this is reasonable, I think.
I don't actually think so. If I'm encoding the document, I'm encoding MY
theory of the text, not the TEI's theory of it, and if I think my text
consists of a <div> that has a <head>, a brief paragraph with some kind
of motif or whatever, and then another <head>, I think I should be able
to do that.
But as your comments below illustrate, we all have particular bugbears
along these lines, all different; the overriding question for me is why
the TEI should be so resistant to loosening up such restrictions, more
or less as soon as anyone demonstrates a need for them. We can't
continually be telling people that the TEI understands the structure of
their document better than they do (or expressly forbids their
particular theory of its structure); that seems heavy-handed and
shortsighted to me.
On the other hand, allowing all tags everywhere would be a kind of
anarchy, I suppose, and Sebastian's job maintaining the stylesheets
would be impossible.
> But where the TEI prohibits me from
> putting a figure in an odd place because no one anticipated that any
> book would ever have a figure in such a place (or whatever), then
> that's a restraint I'd rather be without. The WWP early on had trouble
> with the content model of<note> because it couldn't contain the kinds
> of things that apparently early modern women wanted to put into notes.
> From the standpoint of interchange, though, I could imagine the
> following as a good situation:
> 1. People/projects for whom structure matters enough to take it
> seriously use the schema to constrain their document structures
> 2. Groups of people/projects who need to interchange data and use
> common tools agree on structural constraints; if these are eccentric,
> they use a customization to do so, and if they're really eccentric,
> that customization won't be conformant.
> 3. People/projects for whom structure doesn't matter, or who have
> other structural considerations in play, can still use the vocabulary
> meaningfully to say "I have one of those things you call an<epigraph>"
> Some people writing tools to process TEI might want to take advantage
> of structural predictability ("Only process<author> inside
> <titleStmt>") and for them, conformance would matter.
> Others (e.g. groups of consenting adults in item 2 above) might need
> to develop tools that take advantage of structural predictability of a
> sort not anticipated/covered by the TEI, and they could still use the
> customization mechanism to provide useful constraint in support of
> their own tools, and their data would still use the same recognizable
> vocabulary for non-structure-based interchange. (And the use of the
> customization mechanism would make the specifics of their deviance
> visible and to some extent processable.)
> Still other tool-writers might only need consistent vocabularies to
> accomplish their goals: for instance, tools that are interested in
> searching for/processing named entities--they don't care whether my
> <persName>s are in an<lg> that is nested inside a<div> or not. For
> them, all of this data (conformant or not) is perfectly intelligible
> from an interchange perspective.
> I think it's really useful to break down "interchange" into a more
> specific set of tasks and requirements and to think carefully about
> what conditions are really needed to bring it about. I also think that
> in many cases the real enemy of interchange isn't the design of the
> system (i.e. the TEI schema) but the implementation (i.e. the level of
> consistency achieved by any given project in its encoding) and I think
> it would be very helpful to:
> --improve and extend the tools we offer people for creating
> --place greater emphasis on using customization as a way of avoiding
> inconsistency and enforcing local encoding decisions
> --provide tools for the detection of inconsistency (e.g. Schematron-
> for-novices). It's easy to say "oh, you can test for that with
> schematron" but that may be quite difficult at the moment for someone
> starting a small project with limited access to technical support.
> Simple GUI schematron editor for TEI, anyone?
> Best, Julia
> On Aug 25, 2011, at 3:32 PM, Sebastian Rahtz wrote:
>> On 25 Aug 2011, at 20:23, Doug Reside wrote:
>>> Using the tei_drama.dtd schema, Eclipse complained it wasn't valid.
>>> Perhaps I should have used another flavor?
>> I think you need to show us your XML file. Multiple<head>s at the
>> top of the<div>
>> are entirely normal. tei_drama is a very simple customization which
>> selects some modules.
>> would not be legal.
>> Sebastian Rahtz
>> Head of Information and Support Group, Oxford University Computing
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>> Sólo le pido a Dios
>> que el futuro no me sea indiferente
University of Victoria Humanities Computing and Media Centre
([log in to unmask])