[osis-core] empty tag / milestone proposal

[Troy A. Griffitts]

 > What if we provide segmentation in the core (and document the uglier
 > cases and how to at least do them), and then add Troy's 'most things can
 > be milestones when it helps' approach in 2.0? That would buy us time to
 > work out the details more leisurely, and give us some feedback on how
 > painful people find segmentation cases in actual practice.

I think this is a good approach.  As long as we have this as an open 
issue on the table and acknowledge a planned solution for 2.0

Adding the mStart mEnd milestoneAttribute group in 2.0 and giving 
certain element this property, in 2.0, will not break or change the way 
docs are marked up from 1.x.  And it will give us time to hear back real 
world accounts of need for this feature, if they exist


 > Troy, since you've been doing this conversion stuff, what's your best
 > guess on how many cases like the triple-embedding one you cited,
 > actually come up in Scripture? Are we talking a few, or a few hundred,
 > or...?

specifically for quotes, this happens most everywhere in the Prophets.

e.g. Ezekiel: God spoke to me and said: Ezekiel, say to may people: Thus 
saith the LORD: repent!

this crosses verses, paragraphs, chapters, etc.


My main concern was with the ability for future expansion.  I don't want 
to presume to know all the things that people may want to add.  With 
milestone-style tags, it doesn't matter, with segmentation, we have to 
worry about it.



> I think we need to either prohibit or explicitly allow the use of empty 
> forms.

Agreed.


the approach below seems practicle to me:

> 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.
>