[sword-devel] osis.py

[Weston Ruter]

I've finished writing the OsisWork class for the Open Scriptures OSIS module
(osis.py): it can parse an existing OsisWork strings into its component
parts, allows these parts to be mutated, and then it can be serialized back
out.

Source: http://github.com/openscriptures/api/blob/master/osis.py
Commit:
http://github.com/openscriptures/api/commit/9221c71136fdd3703cce97c8a4cb54a0eb077e47

See the tests for example usages:
http://github.com/openscriptures/api/blob/9221c71136fdd3703cce97c8a4cb54a0eb077e47/osis.py#L554

I'd very much appreciate your feedback. If we can agree on all of the
functionality that such an OSIS library needs, we can create a reference
implementation which can then be ported over to the language of choice.

Whats next is to build:

   - OsisPassage
   - OsisID (OsisWork & OsisPassage)
   - OsisRef (OsisWork & OsisPassage+ & fragments)

Things have been a bit slow on my end lately... because we had a baby two
weeks ago!

Weston


On Tue, May 11, 2010 at 9:32 AM, Weston Ruter <westonruter at gmail.com> wrote:

> I'm working on a Python module for representing osisIDs (works, passages,
> IDs, and refs). I think I've got the OsisWork class baked pretty well (at
> least for reading/parsing), and I would appreciate your thoughts:
> http://github.com/openscriptures/api/blob/master/osis.py#L122
>
> It supports osisID works like those listed here (you can run these tests
> via `python osis.py`):
> http://github.com/openscriptures/api/blob/master/osis.py#L474
>
>    - Bible
>    - KJV
>    - Bible.en
>    - Bible.en.KJV
>    - Bible.en.KJV.1611
>    - Bible.en.ChurchOfEngland.KJV.1611
>    - KJV.1611.06.07
>    - KJV.1611.06.07.235930
>
> In the last two examples, the month and day are also provided (if they
> aren't, then they default to 1); and in the very last example, the time is
> also included (HHMMSS).
>
> An OsisWork then has the following members:
>
>    - segments (each of the period-delimited segments in the osisID)
>    - type (one of the strings enumerated in TYPES)
>    - publisher (a string, the first of two segment slugs listed in the
>    osisID)
>    - name (a string, the single slug listed or the second of two)
>    - pub_date (a datetime object; is “pub_date” the best name?)
>
> Are there other pieces of information that should be parsed out? What about
> revision, version, or edition like:
>
>    - Bible.Example.2010.r231239921
>    - Bible.Example.2010.v2
>    - Bible.Example.2010.ed3
>
> Currently if anything is included which isn't recognized, then it will
> raise an exception; instead it should probably glob the unrecognized
> segments into a "etc" or "splat" list.
>
> Thoughts? I'd love to get this implementation fully built out to be a
> reference implementation for ports into PHP, JavaScript, etc.
>
> Weston
>
>
>
> On Tue, May 4, 2010 at 12:52 AM, Weston Ruter <westonruter at gmail.com>wrote:
>
>> Hello all,
>> Things have been a bit quiet on my end the past few weeks, so I wanted to
>> update you on where I am at and what I see as coming next for the API
>> development.
>>
>> I've been working on a standalone Python module for representing and
>> working with OsisWork, OsisPassage, OsisID, and OsisRef objects. Since OSIS
>> identifiers form such an integral part of the URI space for the RESTful API
>> as it is currently designed, having a solid OSIS library seemed like a good
>> thing to work on. You can see what I have so far here:
>> http://github.com/openscriptures/api/blob/master/osis.py (it's not yet at
>> an alpha state). Please let me know what you think and fork the code to make
>> corrections and improvements.
>>
>> Once osis.py is baked, then the Django views can be written to handle the
>> various OSIS objects. I hope that the osis.py module could also be ported
>> over to JavaScript and PHP and other primary languages to give us a familiar
>> interface for working with OSIS identifiers.
>>
>> In other news, my wife and I are expecting the birth of our first child, a
>> son, in three weeks. I plan to keep involved here as much as possible, but
>> will probably be distracted (though hopefully not as much as I have been
>> these past few weeks).
>>
>> Weston
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20100608/80b51bff/attachment.html>