[osis-core] Candidate (with truly ugly regex, but validates)

[Todd Tillinghast]

> >Todd,
> >
> >Todd Tillinghast wrote:
> >
> >>Looking at <verse> element at this point.
> >>
> >>What are the roles of the attributes "osisWork" and "osisRef".  I
> >>thought that we got rid of them.  "osisWork" is ambiguous and
redundant
> >>related to the values in osisID.  What every "osisRef" would be used
for
> >>should be accomplished with a <reference> element.
> >>
> >Think you are correct about osisWork (actually an optional part of
> osisID).
> 
> Yes, since work can be prefixed to the reference we don't need the
> attribute. Do we want to allow it in some places in order to set
> defaulting? Or just keep it local and hence simpler?
> 
> >
> >osisRef is used by the <reference> element since we don't define how
> >to use XLink/XPointer in the syntax.
> 
> Huh? Isn't OSISref the whole gory regex we've been doing?

We have been working on the form/syntax that self-identifiers and
references will take.  The problem with having osisRef in
globalAttributes is that its meaning is not clear.  What does an osisRef
mean in a <title> element, what does it mean in a <verse> element.  It
is not for self identification since osisID serves that purpose.  Its
purpose is to associate an element with the reference.  By putting
references in a child element the type of the reference can be specified
(the subtype as well).  Also there can be multiple references associated
with a single element rather than just one.

I do think that <note> and <figure> should have an optional osisRef that
means that this note is tied to the text that the osisRef points to.
Presumably text in same document.  Since both elements must be inserted
at a POINT in the XML tree and often a note relates to a specific range
of text this adds real value.  

> 
> >
> >
> >
> >>
> >>There was discussion that also that "annotationWork" and
> >>"annotationType" could be served as a child <reference> element with
the
> >>"type" attribute of "annotation" and a "subtype" of whatever would
have
> >>been put in the "annotationType" attribute.
> >>
> >Can you say a little more about what this would look like? I seem to
> >remember the discussion but can't picture it at the moment. What
> >sort of child element? A local one?
> 
> I don't quite follow this either. annotationType seems like it should
> be the extensible enum of values that we allow for the type attr on
> annotation. i'll go look at this in the latest schema and see if i
> can figure out what's going on.

Maybe I am unclear on what we would be using annotationWork and
annotationType for.  Can anyone provide concrete examples.  I recall
from an example that Patrick gave over the phone once thinking that it
should just be a reference, but now I am fuzzy on the purpose of
annotations?  Please help me out here.

> 
> >
> >
> >>
> >>I do not see segID to go along with prev and next, with it absent
there
> >>is no reliable values to put in prev and next.
> 
> Then again, if you have segID why do you need prev and next? you can
> find and sort out the segments just by segid (even if they've been
> re-ordered somehow). Seems like the only other thing we need is for
> segments (if any) that are done via milestones -- in that case we
> need the start milestone for each segment to point to its
> corresponding end milestone (we could instead number each milestone
> with a different segID, but it's more error-prone (mismatched
> start/ends, etc), and makes the segment numbers less intuitive.
> 

If we are saying that segIDs carry with them some convention of sequence
then prev and next should be removed.  However, if there is no implied
sequence then there must some mechanism to travel backwards and forwards
like a linked list. (or is it a doublely linked list)  With no unique
identifier there is nothing for prev and next to point to.  It seems
that seqID is needed, the question is do we need prev and next?

> >>
> >Doesn't the named milestones (start/end) with matching osisIDs and
> >splitIDs take care of that? (I will generate documentation a little
> >later today and try to go  through it with a fine tooth comb. Will
> >also post it to the list.)
> 
> I think that's pretty much what I just said too (except for the
> promise of documentation :)
> 

Are you suggesting that identifiers (splitIDs) in osisID be used to for
segmentation?  That works fine when the segmented entity is a logical
verse in a reference system, but does nothing to help us for <q> that is
split across several <div> and <p> elements as well as a <verse> element
split across a <lineGroup>/<line> set.

It seems inefficient to use milestones for segmented elements.  Like a
segmented <div> or segmented <p> or segmented <verse>.  I can see
milestones usefulness for some cases but I think that we should retain
the current non-milestone strategy and I don't think that splitIDs in
osisID will suffice.  (The segmentation would be ambiguous as to which
identifier in the osisID is apart of a segmentation strategy if at all.
Secondly, there are a number of elements that can be segmented that do
not have an osisID and I think a consistent strategy for segmentation
should be used.)

> >
> >>
> >>osisIDType needs to be a list of osisIDTypes as shown below.
> >>
> >><xs:simpleType name="osisIDType">
> >>	<xs:list itemType="osisIDPrimativeType"/>
> >></xs:simpleType>
> >><xs:simpleType name="osisIDPrimativeType">
> >>	<xs:restriction base="xs:string">
> >>		<xs:pattern
>
>>value="((((\p{L}\p{N})*((\.\p{L}\p{N})*)?):)?(\p{L}\p{N}((\.\p{L}\p{N}
)*
> >>)?))"/>
> >>	</xs:restriction>
> >></xs:simpleType>
> >>
> >Why do I need the list? That was obscure even for me! ;-)
> >
> >Thanks!
> >
> >Patrick
> >
> >>
> >>Todd
> >>
> >
> >--
> >Patrick Durusau
> >Director of Research and Development
> >Society of Biblical Literature
> >pdurusau@emory.edu
> 
> 
> --
> 
> 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

Todd