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

[Steve DeRose]

At 04:41 PM -0400 08/13/02, Patrick Durusau wrote:
>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?

>
>
>
>>
>>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.

>
>
>>
>>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.

>>
>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 :)

>
>>
>>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