[osis-core] unbalanced <q> elements

[Todd Tillinghast]

Chris,

> I'm marking up the TEV and could use some advice.
> 
> We've got <q/> for marking balanced quotations.  And we've got
> <milestone type="cQuote"/> for marking continuation quotes.
> 
> 1) If I'm marking quotation levels, how should I indicate this on
> continuation quote milestones?  Should they be linked with their <q/>
> parent elements (perhaps with a new cID attribute, similar to the sID
&
> eID attributes)?

I can appreciate the academic case where a continuation quote mark
occurs within a nested quote, but is this a case you have actually run
into or are you just trying to be explicitly clear in what you are
encoding?

I would rather see <milestone type="cQuote.1"/> and <milestone
type="cQuote.2"/> than add an attribute to <milestone> that is tailored
specifically to continuation quote marks.

We could also specify that one of the following:
1) <milestone type="cQuote"/> ONLY applies to the outer most quote OR
2) <milestone type="cQuote"/> applies to the level="1" quote OR
3) <milestone type="cQuote"/> applies to the <q> container that it is
the most immediate child of.
Would any or all of these solve the problem you are facing?

> 
> 2) If I have unbalanced quotes that are not continuation quotes, how
> should I mark them?  Perhaps with a <q/> that has an sID or eID but
> without a matching <q/> with the same value?  Specifically, I have
some
> close quotation marks inside of notes that lack matching open
quotation
> marks.
> 

This exact issue is one that I ran into before and we did not get
resolved in the OSIS meeting last summer.

We have said that it is invalid for an element with and sID to not have
a matching eID and visa versa.  

Your suggestion seems to be the most natural.  Possibly we could allow
<q sID=""/> where the empty value indicates that there will be not
matching eID and vica versa.

Alternatively we could add <milestone type="unbalancedLeftQuote"/> and
<milestone type="unbalancedRightQuote"/> (with better attribute names of
course).

We should try to come up with a solution the upcoming meeting.  

> --Chris
> 
Todd