[tei-council] NH

[Syd Bauman]

The important part of this post is the namespace & conformance issue,
so I've placed it first.


> >> Why do we promote non-conformant markup? at least the examples
> >> could have been TEI with extra elements in a different
> >> namespace?
> > Indeed, depending on how CF reads, they probably should be
> good, so they can be validated as well

We need to poke at this non-conformant markup issue a bit. Since
segment-boundary elements could be automatically transformed into
valid (against tei_all) markup without loss of information, one could
argue that use of such elements is conformable or algorithmically
conformant, and thus TEI Conformant. My reading of CF says that this
is actually the case. And I think I'm OK with that.

However, I feel it is worth thinking about the counter-argument, that
although there is no loss of information, the valid TEI markup into
which one might transform segment-boundary elements violates the TEI
abstract model:

   <lg type="stanza">
     <l><seg type="s" subtype="start"/>E l'orma dell'acqua &#xE8; l'alba</l>
     <l>sulla riva.<seg type="s" subtype="end"/>
       <seg type="s" subtype="start"/>Si esauriva in me</l>
     <l>il supplizio della sabbia,</l>
     <l>a batticuore, spaziando la notte.<seg type="s" subtype="end"/></l>
   </lg>

This doesn't go against the letter of P5, but it certainly has the air
of tag abuse.

So are we more comfortable with the boundary elements in another
namespace, or are we OK with the above being strictly TEI Conformant?


As for HORSE, the whole point of the encoding methodology is that the
same element type is used both as a container and as empty boundary
markers. Thus whether we describe it as conformable (and thus TEI
Conformant) or that it uses a TEI Extension, the elements need to stay
in the TEI namespace.


> I think that's hair-splitting. Where else in the Guidelines do we
> discuss things in this way? The Guidelines as they stand are not a
> book about text encoding (for good or bad).

Perhaps it was hair-splitting, and I'm sorry you're agin the idea,
but if you have guidelines on text encoding they have to provide
guidance on how to handle overlap. Just as SG needs to explain a lot
of XML constructs in order for the user to understand other parts of
the guidelines, NH has to explain overlap. Thus, yes, it sounds more
like a college textbook or conference paper than most other parts of
the guidelines.


> so if we were unenthusiastic about it, why are we raising it again
> here?

We (mostly you) were unenthusiastic about changing the underlying ODD
model so that different element definitions could be expressed as
different RELAX NG depending on whether the user wanted to be able to
apply HORSE with a given element or not. No one ever suggested that it
should not be discussed in NH, and in fact the Overlap SIG was (and
is, I presume) strongly in favor.