[osis-core] Is this ready for OSIS 1.1?

[Troy A. Griffitts]

> Yes, there are multiple hierarchies and as pointed out in the schema, 
> verses should be segmented to accomodate those cases. (The <seg> element 
> is entirely different from segmentation of a verse. See the TEI 
> Guidelines for a fuller explanation.) Quotes can also be segmented and I 
> am sure there are a couple of pathological cases but I note that bibles 
> have already been encoded in markup so apparently there are solutions to 
> this problem. Segmentation is one of them.

Bible have not been limited to single hierarchy markup, in the past!


> There are no elegant solutions to the overlapping hierarchy problem and 
> I can't really see delaying any further because we can't offer such a 
> solution. All solutions require some compromise,

 > from the milestone
> approach that offered bloated semantics and no advantage over a single 
> milestone element but was useful for some software solutions

HA!  I take great offense at this!  You have never shown that our 
milestone suggestion was BLOATED, infact, it elliviates EXACTLY such 
semantics in a segmented approach!

You tell me which is bloated!

<verse>
<tag mStart="x" />
text
</verse>
<verse>
more text
<tag mStart="y" />
bla bla bla
</verse>
<verse>
stuff
<tag mEnd="x" />
</verse>
<verse>
<tag mEnd="y" />
<verse>

Try to encode that in less than 1 page (if at all possible) with 
segmentation and you tell me which syntax is bloated!!!

You have not shown any compromise in this approach OTHER than some XML 
software you use won't recognize the logical container relationship.


> to 
> segmentation which at least is useful to standard XML software.

good luck getting it to recognize ANY relationship between your segment 
legs.  So you still get almost no advantage, with the HUGE DISADVANTAGE 
that you CAN'T encode some cases AND MOST cases that you try will be 
extremely confusing and errorprone to the encoder.


Sorry for this.  I'm happy with the approach that we all agreed on, so 
let's continue without opening this can of worms again.  But please 
don't strawman any suggested solution or underplay the problem.


> I think there are more robust solutions that could be developed for OSIS 
> 2.0, but we are never going to have an OSIS 2.0 if we don't get a schema 
> and texts out for OSIS 1.1. The question for me is does the current 
> proposal limit us in ways that what we do subsequently will be harmed? I 
> don't think so but am anxious to hear other opinions on that topic.

I think Todd is correct, in that NOONE still proved they can encode ANY 
of my (or his) REAL problem passages with segmentation.  And I might 
add, MINE were not small spotted points, but ALL of the MINOR Prophets-- 
just for starters.

I agree we need to move forward.  I also agree with Todd that we were 
closer to a final release before we left Rome because we actually USED 
that spec to encode texts sucessfully.  We need to try this completely 
rewritten spec before we even consider releasing for general public 
consumption.

	-Troy.

> 
> Patrick
> 
> 
>>
>> Todd
>>
>