[developers] RESTful ERG parsing

[Michael Wayne Goodman]

Hi again,

On Mon, Apr 4, 2016 at 12:41 PM Stephan Oepen <oe at ifi.uio.no> wrote:

All that you described sounds good to me.

(a) top, index, relations, label, predicate, arguments, constraints,
> relation, variables, ...
> (b) top, index, rels, lbl, pred, args, hcons, icons, rel, vars, ...
>
> my current preference is for (a)


I agree on (a)


> [...] or argue other fine points of JSON
> serialization, please do so in the next couple of days!
>

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 (http://enable-cors.org/). 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.


>   i think i
> will standardize on 3.3 and upwards then, and if and when you get to
> adding a client interface to pyDelphin, i will let you find out
> whether and how to work around Unicode limitations in 2.x :-).
>

Ok. Last night I put together a MRS-JSON serializer-deserializer, based on
our discussions. So that part is ready.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20160405/8b998365/attachment.html>