Robert:<br><br><div class="gmail_quote">On Mon, Jan 25, 2010 at 10:53 AM, Robert Hunt <span dir="ltr">&lt;<a href="mailto:hunt.robertj@gmail.com">hunt.robertj@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">




  
  

<div bgcolor="#ffffff" text="#000000">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&#39;s
not under our control), the stand-off markup becomes totally confused.
It might be a huge-job to reconstruct it???<br></div></blockquote><div><br>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&#39;t Change”)… hence my question about the IDs in the ESV API: <a href="http://groups.google.com/group/open-scriptures/browse_thread/thread/d6bd33646335c2c6">http://groups.google.com/group/open-scriptures/browse_thread/thread/d6bd33646335c2c6</a> <br>

<br>What do you mean exactly by the situation where the text isn&#39;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.<br>

<br><br>On Mon, Jan 25, 2010 at 10:58 AM, Robert Hunt &lt;<a href="mailto:hunt.robertj@gmail.com">hunt.robertj@gmail.com</a>&gt; wrote:<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">

I&#39;m not a JS / web API expert, but couldn&#39;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???)<br>

<br>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?<br></blockquote>


<br>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.<br>

<br>Weston<br>
</div></div>