[osis-core] annotateRef: Question on whitespace

[Steven J. DeRose]

How about allowing whatever the unicode ellipsis character is, to 
function as a wildcard in the s[] argument? That would not be 
shitespace, but would give us a simple upgrade. It's unicode 2026.

I wouldn't mind just prohibiting the space (was just talking to prd 
about it on the phone), but it does have the drawback that you can't 
refer to non-first instances of the string.

Also, doc should say you should go as far down as you can with 
straight osisIDs before using a grain -- like, you shouldn't be using 
grain that count from the top of a book all the way to the 5th 
chapter, or something.


At 12:52 PM -0600 9/15/03, Todd Tillinghast wrote:
>See below.
>
>Todd
>>
>>  Greetings!
>>
>>  Note the whitespace issue that Todd raised recently has NOT been
>>  resolved. Need comments, suggestions, etc.
>  >
>  >> Todd's most recent post (and the last traffic on this issue):
>>
>>  > The issue is not what software will do or what we say the rules are
>but
>>  > the fact that with XML Schema a list is defined to be whitespace
>>  > separated.
>>  >
>>  > It is possible to express in XML Schema that a simple type is a list
>of
>>  > other simple types that allow whitespace.  But a list is defined as
>>  > being whitespace separated.  So in practice you must not allow
>>  > whitespace in a simple type you use to make a simple type that is a
>>  > list.
>>  >
>>  > My suggestion is to not allow whitespace in the string portion of
>the
>>  > @s: grain structure.
>>
>>  Todd: Is your proposal to non allow whitespace in the string portion
>of
>>  the @s: grain structure only for annotateRef?
>>
>>  Hmmm, I think having whitespace in the string portion of the @s: grain
>>  structure is fairly important in other uses of the osisRef regex.
>>
>I agree that it is useful to allow space.
>
>>  General feeling on whether this will be confusing to allow whitespace
>>  sometimes but not others?
>>
>>  Could do a separate regex for annotateRef that does not allow the
>  > whitespace.
>>


-- 

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