I agree with Peter (there really is no spec), but you have to be
realistic about what you can do as the developer. I would add everything
that you can from the UBS reference document and then gradually add
other common USFM elements as time goes by.
Obviously you would have to decide what USFM practices you are willing
to support since some practices may conflict with others. But my thought
is, if it is common practice and does not conflict seriously with the
reference document or the fundamental way you have constructed the
script to work, support it. Less common practices and those that pose
serious conflicts should be cleaned up in the USFM files before being
put through the script. I know "common practice" is hopelessly vague,
but you have seen a few texts and can make good judgments about what
should be in there.
Daniel
On 08/01/2012 12:02 AM, ref...@gmx.net wrote:
My immediate thought is, there is no USFM text which conforms to spec.
And those that try to still vary in their interpretation and the
semantics. So a tool to transform needs to be flexible and editable.
Sent from my HTC
----- Reply message -----
From: "Chris Little" <chris...@crosswire.org>
To: "SWORD Developers' Collaboration Forum" <sword-devel@crosswire.org>
Subject: [sword-devel] USFM conformance in usfm2osis.py
Date: Wed, Aug 1, 2012 3:16 am
My new usfm2osis.py script is progressing quite nicely. I've got it
generating valid OSIS from one Bible that uses a very minimal set of
USFM elements. At the moment, I'm working to make it process all tags
present within the USFM versions of the WEB and RV, and this has
raised an issue.
I've been working primarily with the USFM reference from UBS ICAP,
treating it as a sort of specification. My question is: should this
new utility accept USFM that does not conform to the reference at UBS
ICAP?
Should it accept & interpret USFM tags that are not present in the
reference?
One specific example is that the WEB uses \fqa*, which is obviously
intended as an end-tag version of \fqa (used to mark alternate
translations). But the USFM reference does not identify this as a
valid end-tag, by my reading.
So... should we...
a) Make the new utility accept non-conformant USFM (from the
perspective of the USFM reference). I'm leery of this, since one of my
reasons for writing the new utility was to keep it pristinely
spec-conformant and I have a feeling we might start incorporating tags
and syntax that are less obviously interpretable than \fqa*.
b) Write a separate utility to convert common and interpretable
non-conformant tags/syntax to conformant markup.
c) Add a command-line switch to usfm2osis.py so that it performs a
pre-processing step of making non-conformant tags/syntax into
conformant markup. (This would be the same as option b, but would
place everything in a single utility.)
d) Punt on the issue, and let those performing conversion deal with
non-conformant markup on a case by case basis.
--Chris
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
