[osis-core] Milestone proposal

[Steven J. DeRose]

At 9:29 AM -0400 5/28/03, Patrick Durusau wrote:
>Troy,
>
>Troy A. Griffitts wrote:
><snip>
>
>><verse osisID="John.1.1" mID="X"/>In the beginning...<verse mID="X"/>
>>
>>
>>Todd brought up a good point before we left that we should discuss.
>>He pointed out that if we have an excerpt of an OSIS doc that 
>>contains the ending milestone, we won't be able to tell that it is 
>>an end milestone, as opposed to a start milestone.
>>
>>I agreed with him in Dallas, but have thought about it and I'm not sure now.
>>
>>If, indeed, milestone 'containers' should be treated exactly like 
>>real XML containers, then the proposed problem case should be 
>>illegal anyway.
>
>Not illegal, just not meaningful. Note that treating matching 
>milestones as a "container" is not the same as being a container for 
>purposes of the XML tree syntax. If you have a missing "starting" 
>milestone, you simply have an empty element that has little meaning. 
>Software looking for matching empty elements would simply fail to 
>find a match but not a syntax error.

I think I disagree -- if we did know which end the empty element we 
*do* have represents, then it's not meaninless at all -- we know 
exactly what we've got: the start (or end) of the named thing, and we 
know we don't have it all (and of course, we know which direction to 
look for it, barring encoding errors).

>
>>So, I'm not sure.  I don't mind either, really.  Todd's proposed 
>>change would look something like:
>>
>><verse osisID="John.1.1" mB="X"/>In the beginning...<verse mE="X"/>
>
>Not sure what this buys us as opposed to your "mID." It does rely 
>upon a notion of document order to be meaningful but since we are 
>talking about static documents (at least at this stage) I don't see 
>that as a weakness.

It does buy us more info in the fragment case; and it lets us detect 
and report ordering errors, rather than simply generate the wrong 
result. This one could be big: it would be easy to accidentally move 
a milestone via cut and paste, and without a begin/end distinction 
there would be no way to catch it automatically later (in general -- 
of course some cases could be caught by various kinds of consistency 
checks).

>
>If we go with Todd's proposal, we introduce the need to use 
>different attribute names for either end, which should still be 
>occuring in document order. If I find a "mE" and value without an 
>"mB" with a matching value it looks to me like the same situation as 
>finding an "mID" and its value, without another "mID" with a 
>matching value. There is still no control over the order of 
>placement of the elements.

That's ok at schema level; it's easy to write a checker that *does* 
validate for order, and any halfway decent OSIS editor will have to 
do it.

I'm not fond of mE and mB, first because they're not very mnemonic, 
and second because it's not obvious to me whether "mB" would mean 
"I'm the beginning and X is my ID" or "Im the ending and the ID of my 
corresponding beginning milestone is X". I think I'd prefer startID 
and endID, because I find having "ID" in their suggests that the 
value is about oneself -- so startID would go on the start milestone, 
and endID on the end.

>
>Since most overlap is localized, in other words, we are not talking 
>about more than a screen full of text where the user will be 
>entering the values, I would go with using the same attribute name 
>to ease the work (and lessen possible errors) on the manual entry 
>user.
>
>See note soon to follow on my investigation into the schema.
>
>Hope everyone is having a great day!
>
>Patrick
>
>--
>Patrick Durusau
>Director of Research and Development
>Society of Biblical Literature
>Patrick.Durusau@sbl-site.org
>Co-Editor, ISO 13250, Topic Maps -- Reference Model
>
>
>
>
>_______________________________________________
>osis-core mailing list
>osis-core@bibletechnologieswg.org
>http://www.bibletechnologieswg.org/mailman/listinfo/osis-core


-- 

Steve DeRose -- http://www.derose.net
Chair, Bible Technologies Group -- http://www.bibletechnologies.net
Email: sderose@acm.org  or  steve@derose.net