[tei-council] NH

[Lou Burnard]

Syd Bauman wrote:
> 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?
>
>   

This is not conformant because it breaks the abstract model. A <seg> is 
supposed to have some content.

If you rewrote it with milestones it would be OK though.

(I am still wondering why you prefer "segment boundary" as a name to 
"milestone" which is what we have always called these things till now 
and still do call them elsewhere in the Guidelines)


> 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.
>
>   
Same argument applies.  An empty <p/> means something different in TEI 
proper.