<div dir="ltr">Hi again,<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 4, 2016 at 12:41 PM Stephan Oepen <<a href="mailto:oe@ifi.uio.no">oe@ifi.uio.no</a>> wrote:</div><div dir="ltr"><br></div><div>All that you described sounds good to me.</div><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(a) top, index, relations, label, predicate, arguments, constraints,<br>
relation, variables, ...<br>
(b) top, index, rels, lbl, pred, args, hcons, icons, rel, vars, ...<br>
<br>
my current preference is for (a)</blockquote><div><br></div><div>I agree on (a)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...] or argue other fine points of JSON<br>
serialization, please do so in the next couple of days!<br></blockquote><div><br></div><div>How do you feel about cross-domain requests? If you don't mind other web services utilizing your infrastructure for these requests, you could setup CORS (<a href="http://enable-cors.org/">http://enable-cors.org/</a>). Alternatively you can use JSONP (not to be confused with JSPON I mentioned earlier), where you wrap the json object in a client-defined function callback. Of these options, JSONP is the easiest to setup, and I'd be happy to assist.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> i think i<br>
will standardize on 3.3 and upwards then, and if and when you get to<br>
adding a client interface to pyDelphin, i will let you find out<br>
whether and how to work around Unicode limitations in 2.x :-).<br></blockquote><div> </div><div>Ok. Last night I put together a MRS-JSON serializer-deserializer, based on our discussions. So that part is ready.</div><div><br></div><div>Regarding unicode: I don't think I have experienced the problem you're describing, but in transport the requests should be encoded byte sequences, whether it's Python 2 or 3. Python 2 often confuses byte strings and unicode (codepoint) strings and operations using both will implicitly up-cast bytes (assuming some default encoding) to unicode. Python 3 makes the division more clear and doesn't implicitly decode bytes, so you might see more errors initially, but in the end it is (I think) more understandable.</div><div><br></div></div></div>