[osis-core] Outstanding issues.

[Steve DeRose]

At 02:03 PM -0600 08/14/02, Todd Tillinghast wrote:
>Patrick,
>
>1) Outstanding is osisID as a list.  We all need to be clear on what an
>osisID is and what we intend to be used for.  If osisID is not a list I
>cannot encode things like Matt.1.6-Matt.1.11.

Lists seem fine to me; they cover this case, and also the case of 
encoding multiple ref-systems in a document.

>
>2) I am not clear on the current strategy for segmentation.  I know we
>have milestones and they can be used for ALL forms of segmentation, but
>I thought that we had agreed that the primary mechanism to handle
>segmentation would be through some sort of prev/next/segID strategy (or
>as recently discussed, just segID what follows a convention that
>specifies order).

My understanding is that we can do everything with segmentID. If one 
wants to use milestones, each pair gets a segmentID the same way, and 
each start points to its corresponding end as well. This could be 
done several other ways, too, of course.

>
>3) No one has addressed the concerns raised related to creating
>expressions that "get" elements based on a identifier in an osisID.  One
>option would be to put ( and ) around each identifier.  (Or [ and ] but
>we already use that for grain.)  Ex: <verse osisID="[Matt.1.6]
>[Matt.1.7] [Matt.1.8] [Matt.1.9] [Matt.1.10] [Matt.1.11]
>[Bible.TEV:Matt.1.6.b]"> and <div osisID="[Matt.1]">.  This works for me
>if it works for everyone else.  Thoughts?

Of I'm understanding this right, your concern is ensuring a token 
boundary, yes?  Such that a matching system with \< and \> would not 
pose this problem. Hmmm. CSS selectors work fine; XPath sadly doesn't 
(though you can fake it by searching for the ID with a space on each 
end, and adding a space to each end of the attribute value -- just a 
little grosser (wish we'd thought of that when doing XPath, though I 
don't know that I could have sold it anyway).

>
>Without resolution to #1 and #2 it will be difficult to encode the
>non-trivial test texts.  And with out resolution to #3 reliable XSL
>transformations will be hard to find.

I find the brackets a little ugly for case #3, and we could only 
explain them by resorting to shortcomings of certain specs and/or 
apps -- I think I'd rather document the needed XPath to ensure a good 
match, and leave it at that.

S

-- 

Steve DeRose -- http://www.stg.brown.edu/~sjd
Chair, Bible Technologies Group -- http://www.bibletechnologies.net
Email: sderose@speakeasy.net
Backup email: sjd@stg.brown.edu