[osis-core] empty tag / milestone proposal

[Steve DeRose]

Like Harry, I'm torn over this (and want to go to bed).

At least the number of choices is small. It seems like we're down to

a) use segments

b) use milestones

c) allow both

Troy and Harry have described the tradeoffs really well, IMHO.

The usual TEI approach in such case was to allow both. This has 
advantages similar to those of many Vatican II pronouncements: 
everybody feels they got what they wanted; and disadvantages likewise 
similar: nobody really ended up compatible.

I think we need to either prohibit or explicitly allow the use of 
empty forms. Although Patrick is right that you can always dump in 
empty elements for the start and end, the semantics implied by that 
syntax are not what we want.

    <q mStart=""/>some quoted text<q mEnd=""/>

means 3 siblings, 2 being empty quotations. That's reeally not the 
same meaning as

    <q>some quoted text</q>

(Eudora's spellchecker kindly underscores the tags for me, thus 
making those q's look an awful lot like g's).

As someone pointed out, it's not the same DOM tree, and 
structure-aware tools such as CSS and XSLT don't have any way to deal 
with it (that one worries me considerably, since people commonly 
judge by appearances, and our appearances would be handicapped in 
most systems).

Thus, although people could encode quotes with pairs of empties, 
their data would fail to "work" in typical software.

Mainly for that reason, I think I'm inclined to a solution such as:

a) permit only segmentation in core, but document clearly how it gets 
messy (explosively messy) as the amount of overlap increases.

b) create a specific module for heavy annotation, that adds the 
mStart/mEnd construct for a lot of element types, that defines the 
semantics intended, and that discusses the issues involved. Make 
support of this module a separate conformance level, and require that 
systems specify whether they support it or not.

To paraphrase Zoot: Oooh, it's not a very good solution, is it? But 
we are nice, and will see to your every markup need.

-- 

Steve DeRose -- http://www.stg.brown.edu/~sjd
Chair, Bible Technologies Group -- http://www.bibletechnologies.net
Email: sderose@speakeasy.net
Backup email: sderose@mac.com, sjd@stg.brown.edu