[osis-core] Eliminate quote and blockQuote as elements and put back quote milestones.

[Steve DeRose]

At 12:32 PM -0700 06/14/02, Troy A. Griffitts wrote:
>>Just as a sanity check, can you follow up on my suggestion that 
>>unless element content is required that I can write the quote 
>>element either as:
>>
>><q id="myfirstquote">Comments about some projects</q>
>>
>>or
>>
>><q id="myfirstquote"/>comments about some projects<q id="endfirstquote"/>
>
>Wow, great idea.  How bout, instead of using ID in both, that we use 
>something that is a little more easily 'coded to', like mStart and 
>mEnd:
>
><q mStart="myfirstquote"/>comments about some projects<q mEnd="myfirstquote"/>

If we do something like this, I think we should definitely make it 
very explicit (a) which is start and which is end. Would we want to 
make this an available option for *all* element types?

That would allow optimizing every case for the minimum markup, which 
is kind of nice; but it also opens the door to enormous variability 
and non-interoperability -- for example if one system decides to 
always use empties, and another never to use empties. That seems 
dangerous to me, and I don't know that we have enough market 
penetration to be able to get implementors to consistently support 
both everywhere.

>
>
>This allows us to:
>
>	a) keep the same value text for the matching attribute 
>without having to strip a 'end' from the head of it to find the 
>match.

That is definitely a good thing.

>
>	b) easily allows us to check for mStart or mEnd to determine 
>what we are (neither: container with content; mStart: milestone 
>start; mEnd milestone end).  We won't have to look into the value of 
>ID to determine this.

We might possibly also want something like 'mResume' to point ahead 
to where the next part of a discontiguous unit begins.

>
>
>We could have an attributeGroup of: milestoneABLE (silly name) which 
>contains mStart and mEnd, and let all elements we wish to have this 
>ability, get these attributes.
>
>	Keep up the great work.  It's nice to see activity again!
>
>		-Troy.

I am getting to like this idea. On the other hand, it's really 
powerful and I'm a little worried about adding it to core this late 
(mostly I'm scared there might be some problem we won't spot in 
time). I think my inclination is to stick with the segment status 
quo, and either to put off a neater solution like mstart/mend to the 
next release or module, or to support it just for q, or to write it 
up as a separate paper 'for experimentation' (kind of like XML did 
with namespaces, not that that example turned out well....)

-- 

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