<div dir="ltr"><div class="gmail_quote"><div>Hello again,</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">our RESTful service at <a href="http://erg.delph-in.net/rest/0.9/" rel="noreferrer" target="_blank">http://erg.delph-in.net/rest/0.9/</a> now supports<br>
CORS (i.e. provides the ‘Access-Control-Allow-Origin: *’ header).  i<br>
hope this much will be sufficient for you to escape the cross-domain<br>
limitations in your JavaScript client, ned?<br></blockquote><div><br></div><div><span style="line-height:1.5">Ah excellent! It is indeed. Proof of which can be found here: </span><a href="http://ned2.github.io/delphin-viz/demo/" style="line-height:1.5">http://ned2.github.io/delphin-viz/demo/</a><span style="line-height:1.5"> It&#39;s essentially a minimal clone of the LOGON demo. It only supports viewing derivations currently, which are SVGs generated using code taken and adapted from Woodley&#39;s full forest treebanker (which I also used for rendering trees in Typediff).</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">i am delighted you are developing this client already, but i need to<br>
caution that (a) mike and i are still discussing minor modificitions<br>
to the JSON serialization for MRS and that (b) there appears to be a<br>
bug in the JSON representation of multi-token leaf nodes in the<br>
derivation.  i hope to have both resolved over the next few days!<br></blockquote><div><br></div><div>Understood, and this is only to be expected for an API under development.</div><div><br></div><div><div>As far as the API is concerned, I found it to be quite accessible and seems to cover the basics with respect to the needs of visualising the derivations -- with the obvious exception of the shorthand node labels still to come. </div><div><br></div><div>From my own perspective, there are two additional pieces of data that I made use of for the Typediff trees, which I believe could also add value to the ERG API. One is including the lexical type name for nodes corresponding to lexical entries. I personally prefer derivation trees rendered with lexical type names rather than lex entry identifiers -- and in the case of Typediff, this was an explicit design choice. Perhaps this could be a user configurable option in my demo. </div><div><br></div><div>The other is including TO and FROM values within derivation nodes to map sub-trees onto the corresponding  character spans in the original string. While not as enlightening as in the case of doing this for predications---since the surface yield of a derivation is a little easier to see directly in the tree---I still feel like the input highlighting would be a useful feature. I guess I could manually extract them from the contents of the &#39;tokens&#39; attribute, however this will make the client dependant on the ERG&#39;s token mapping setup and my understanding is that this can vary from grammar to grammar? Although, to be fair, this is only advertised as an &#39;ERG&#39; API. That said, this still feels like lower level implementation logic that an API should smooth over.</div><div><br></div><div>Cheers,</div><div>Ned</div><div class="gmail_quote"></div></div></div></div>