[osis-core] empty tag / milestone proposal

[Patrick Durusau]

Harry,

Harry Plantinga wrote:

>
>So here's a general proposal.
>
>We offer the current DTD. The semantics are that in OSIS-level-1
>conformant processing software, empty tags are empty tags. In
>OSIS-level-2 conformant processing software, milestones and empty
><verse> <q> etc tags can be container start and end tags.
>
OK, so I need to add mStart and mEnd attributes back into the schema, 
for which elements?

<q>, <verse>, .... ?

And do we document the semantics for OSIS-level-1 in the documentation 
or attempt to put it in syntax?

OR:

Not sure why I can use <milestone type="q" /> in the current syntax and 
then if I want to treat linked milestones as containers (in other words, 
not depend upon default order in the text) for OSIS-level-2 processing, 
that is certainly an option.

Alternative General Proposal:

Use generic <milestone type="element"/> to indicate a milestone of a 
particular type, such as <q> or <verse> with a next= attribute to link 
it to the milestone that may be treated as the other end of a container 
for OSIS-level-2 processing. The second milestone should have a matching 
type and prev= attribute.


Patrick


>
>-Harry
>
>
>>-----Original Message-----
>>From: owner-osis-core@bibletechnologieswg.org
>>[mailto:owner-osis-core@bibletechnologieswg.org]On Behalf Of Patrick
>>Durusau
>>Sent: Thursday, June 20, 2002 2:02 PM
>>To: osis-core@bibletechnologieswg.org
>>Subject: Re: [osis-core] empty tag / milestone proposal
>>
>>
>>Harry,
>>
>>Harry Plantinga wrote:
>>
>>>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.
>>>
>>Realize you were kidding about " but why not suggest the entities &quot; 
>>and &apos; which are pre-defined for XML? If what you are seriously 
>>suggesting is markup to stand in for symbols, <q mStart=" "/>, the 
>>entity route gets you there without tormenting markup. ;-)
>>
>>Patrick
>>
>>
>>>-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
>>>>
>>-- 
>>Patrick Durusau
>>Director of Research and Development
>>Society of Biblical Literature
>>pdurusau@emory.edu
>>
>>
>>

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu