[osis-core]
RE: OSIS to USFM Best Practice Meeting, table for review
Todd Tillinghast
todd at contentframeworks.com
Tue Nov 9 13:27:23 MST 2004
Nathan,
I have added what I believe to be the mapping between USFM and OSIS that
best represents the established OSIS best practice for encoding Bibles.
Patrick Durusau reviewed the mapping and commented on the ones I had
questions about and made suggestions.
In the process I also consulted the mapping that Jim Albright created
between USFM, OSIS, TE, and several flavors of SFM. In several cases
the mapping expressed is identical to Jim's and in the majority of cases
the differences are conceptually the same and differ mainly by syntax
corrections.
A note of caution related to a mapping between USFM and OSIS: The
mapping will only be reliable if the format markers in the map are used
for the meaning assigned to the format marker and not simply to achieve
the presentation type typically associated with a given format marker.
There is a mail list already established for discussion of issues
related to OSIS and SFM (USFM more commonly moving forward).
Please send any questions, concerns, corrections, or comments related to
the attached mapping.
I will be arriving at CTC Thursday evening if I can be of help with
final questions or issues prior to you meeting Saturday.
Todd
(The two attached files are the same only different formats.)
> -----Original Message-----
> From: Nathan Miles [mailto:nmiles at ubs-icap.org]
> Sent: Friday, November 05, 2004 2:33 PM
> To: todd at contentframeworks.com; sderose at speakeasy.net;
Jeff_Gayle at sil.org;
> Alan_Conner at sil.org; kdeblois at biblesocieties.org;
jklassen at ubs-icap.org;
> Michael_Cochran at sil.org; Ed_Abrahamson at sil.org; Marie_Titus at sil.org
> Subject: OSIS to USFM Best Practice Meeting, table for review
>
> Greetings,
>
> I am sending this material out because a few people wanted
> review it in advance of "USFM to OSIS Best Practice"
> meeting.
>
> My theory is that the main thing we need to do
> at this meeting is determine for the 170 or so USFM 2.0 markers
> exactly what OSIS tags we will generate.
> These tags and structure will of course need to be consistent
> with the OSIS schema and the Users Guide.
>
> If you have a different proposal about what we should discuss
> at the meeting you should probably communicate it to the group ASAP.
>
> Jeff Klassen has included the updated info for USFM 2.0 here:
> http://ubs-icap.org:8080/confluence/display/USFM/Home
>
> The OSIS 2.0 schema and User Manual is here:
> http://www.bibletechnologies.net/UserManualandSchema.dsp
>
> I am attaching a spreadsheet which proposes a mapping
> from USFM to OSIS. Read it as follows:
>
> Column A: USFM marker
>
> Column B: IGNORE THIS COLUMN (When doing an actual conversion
> from USFM to OSIS it is one way of stating when an
> new USFM needs to force the closure of previously opened
> XML tags. Specifically any XML tag generated with a larger
> value must be closed before opening any XML tags associated
> with the new marker)
>
> Column C: The xml tags generated as a result of the USFM marker.
> X[@Y="Z"] means generate <X Y="Z">.
> This is XPATH notation.
>
> If multiple tags are present, any not currently open must be
> generated. Example \ip (intro paragraph) has value:
div[@type="intro"]//p
> This is intended to mean if there is not already a div of type "intro"
> open,
> generate a <div type="intro"> marker before creating the <p> marker
> for the paragraph. The "//" is present because if a intro <div>
> is already open, there may have already been lower level intro
> section <div type="section"> already generated -- so
> // means more or less /.../
> or in this specific case /div[@type="section"]/.
>
> Column D: text description of USFM marker
>
>
> I have no great emotional attachment to the proposed tags.
> If anyone would like to send me an alternate proposal I will include
> it and redistribute the updated table to the attendees. Please place
you
> alternatives in
> Column E so that I can clearly see what you would like changed.
>
> The biggest problem I see currently is that there are dozens of USFM
> markers that have no (to me at least) obviously correct mapping to
OSIS.
> In these cases I have created custom types (x-abc...).
> For each of these markers we will need to do one of the following.
>
> o Find an existing OSIS tag/type it should map to that I missed
> o Create a new OSIS type (or in an extreme cases a new tag)
> o Create a custom type (x-example) not defined directly in the
OSIS
> standard
> but used only with USFM origin data.
>
>
>
> Nathan
>
> -------------------------------
> Nathan_Miles at ubs-icap.org
> United Bible Societies
> 972 708 7377 (Dallas)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmltag2.xls
Type: application/vnd.ms-excel
Size: 75264 bytes
Desc: not available
Url : http://www.bibletechnologieswg.org/pipermail/osis-core/attachments/20041109/4b883f4f/xmltag2-0001.xls
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmltag2.csv
Type: application/octet-stream
Size: 32336 bytes
Desc: not available
Url : http://www.bibletechnologieswg.org/pipermail/osis-core/attachments/20041109/4b883f4f/xmltag2-0001.obj
More information about the osis-core
mailing list