...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. 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  
> just
> selects some modules.
> This:
> <div>
> <head>...</head>
> <p>...</p>
> <head>...</head>
> ..
> </div>
> would not be legal.
> --
> Sebastian Rahtz
> Head of Information and Support Group, Oxford University Computing  
> Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
> Sólo le pido a Dios
> que el futuro no me sea indiferente