#562 Change description of TEI Header and simplify content model of TEI

[Lou Burnard]

It seems time to rethink the definitions of the teiHeader element in
line with expanded applications of it as a generic metadata
container. At the same time, it would be useful to simplify the
content model of the <TEI> element itself.

This ticket proposes the following changes:

1. Change the description of <teiHeader> from "supplies the
   descriptive and declarative information making up an electronic title
   page for every TEI-conformant document." to "supplies descriptive and
   declarative metadata associated with a digital resource or set of
   resources". This change makes it easier to use the teiHeader to
   document an <fsdDecl> (as is currently proposed) and also to use it
   with the proposed new <standOff> element.

2. Change the description for the class model.resourceLike from
   "groups non-textual elements which may appear together with a header
   and a text to constitute a TEI document" to "groups separate elements
   which constitute the content of a digital resource, as opposed to its
   metadata."

3. Change the content model of <TEI> from

  <content>
    <group xmlns="http://relaxng.org/ns/structure/1.0">
      <ref name="teiHeader"/>
      <choice>
        <group>
          <oneOrMore>
            <ref name="model.resourceLike"/>
          </oneOrMore>
          <optional>
            <ref name="text"/>
          </optional>
        </group>
        <ref name="text"/>
      </choice>
    </group>
  </content>
~~~~~~
to

<content>
<group xmlns="http://relaxng.org/ns/structure/1.0">
<ref name="teiHeader"/>
<choice>
<oneOrMore>
<ref name="model.resourceLike"/>
</oneOrMore>
</choice>
</group>
</content>
~~~~~

and (of course) add to model.resourceLike

The only possible downside of this change is that if you have an ODD
in which model.resourceLike is deleted for some reason, you will now
thereby delete the <text> element. But deleting model classes is an
intrinsically dangerous procedure which should only be undertaken by
the fully aware.

[Martin Holmes]

I don't see any actual objection yet, but this is such a rudimentary change we should probably test it in a branch.

[Laurent Romary]

I vote for this immediately.

[Hugh A. Cayless]

I'm in favor of this (though it warrants discussion, obviously). I agree with Martin too, though that it needs testing, so I'm going to suggest we use this as a way to experiment with testing Git branches.