[osis-core] empty tag / milestone proposal

[Harry Plantinga]

Hey, here's an idea that will eliminate a large percentage of
the hierarchy overlap problems that have been identified so far.
Don't use <q>, just use ".

Just kidding.  The real proposal is to not treat <q> as a container.
(Does one ever really need it to be a container?)  Use <qstart>
and <qend>.  Or use <q mStart=""/> <q mEnd=""/> but don't require
processing software to treat that as a container.  Just use it
to put in the appropriate " symbols.

-whp

> -----Original Message-----
> From: owner-osis-core@bibletechnologieswg.org
> [mailto:owner-osis-core@bibletechnologieswg.org]On Behalf Of Steve
> DeRose
> Sent: Wednesday, June 19, 2002 10:06 PM
> To: osis-core@bibletechnologieswg.org
> Subject: RE: [osis-core] empty tag / milestone proposal
> 
> 
> 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
>