[osis-users] Unambiguous and Consistent OSIS for Interchange: Stand-off Markup
Weston Ruter
westonruter at gmail.com
Tue Jan 26 23:21:23 MST 2010
Robert:
On Mon, Jan 25, 2010 at 10:53 AM, Robert Hunt <hunt.robertj at gmail.com>wrote:
> I like this in many ways. But effectively, having layers which depend on
> one another would mean that if the source text changed (esp. if it's not
> under our control), the stand-off markup becomes totally confused. It might
> be a huge-job to reconstruct it???
>
Yes, the identifiers used for the anchor points would need to be stable, for
this reason and for the sake of addressability (i.e. “Cool URIs Don't
Change”)… hence my question about the IDs in the ESV API:
http://groups.google.com/group/open-scriptures/browse_thread/thread/d6bd33646335c2c6
What do you mean exactly by the situation where the text isn't “under our
control”? Stand-off markup could be used to impose structures on remote
data, but I was thinking the markup would be in the same document as the
actual target content, at least in the normal case.
On Mon, Jan 25, 2010 at 10:58 AM, Robert Hunt <hunt.robertj at gmail.com>
wrote:
> I'm not a JS / web API expert, but couldn't an intermediate API layer be
> used here, i.e., a library written in the more efficient language that JS
> then makes calls upon? (I guess the library code is on the server where the
> data is and the JS is on the client???)
>
> Alternatively, an intermediate (derived) format (or database) which
> combines the data and stand-off markup and is not necessarily XML or any
> other standard, but rather designed for ease / speed of access?
>
Yes, the end-user could invoke the data via a variety of adapters which
translate the underlying canonical OSIS data into the desired format for
most efficient usage. If the underlying OSIS data is consistently marked up
(e.g. using stand-off markup), then these adapters could be applied to any
OSIS data without having to account for different OSIS document styles.
Weston
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/osis-users/attachments/20100126/df713112/attachment.html>
More information about the osis-users
mailing list