[developers] [pet] Whoa, missed someting, sorry

Stephan Oepen oe at ifi.uio.no
Sun Apr 13 15:39:06 CEST 2008

hi again,

> Just a few more words on the C++ MRS code. For the moment, the new
> C++ codes only extract MRS from FS, and pretty print them into XML
> format (which in principle should be identical to the old -mrs=mrx
> option). There is no implementation of MRS->RMRS conversion yet. VPM
> mapping is supported though.

apologies for my tardy follow-up!  i can see how it is desirable not
to have to depend on ECL for PET.  but i can also see how it could be
difficult to synchronize MRS-related functionality across code bases
(fortunately, the MRS core has been quite stable for many years now).

i think the strategy sketched by zhang yi is a good solution: add the
necessary code to extract (and serialize) MRSs from parsing results,
but avoid incorporating MRS-level functionality that is not directly
related to parsing.  scope resolution, MRS comparison, dependencies,
and in my view also conversion to RMRS fall into the latter category.
maybe in terms of a mid-term goal we can envision an MRS processor, a
separate component that provides more sophisticated functionality?  i
guess a mildly modified LKB binary could do that, as a starting point.

--- more short-term however: in [incr tsdb()] and LOGON, we have been
focusing on the `simple' (rather than XML) MRS format.  not to have a
discussion about the benefits (and maybe disadvantages) of XML here,
but in large [incr tsdb()] profiles and in LOGON fan-out mode size is
a real concern.  a serialized MRS in XML is nearly eight times larger
than the same information in `simple' format; of the existing formats,
`simple' is the most compact one that preserves all information, and i
would say it strikes a good balance with human readability.

in conclusion, my suggestion would be to have two standard formats of
MRS serialization modes, XML (probably best for use in the HoG and the
like) and `simple' (for bulk use in [incr tsdb()] and LOGON).  can you
agree to that strategy (i could possibly add and maintain the PET code
for `simple')?

                                                     all best  -  oe

+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125
+++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
+++       --- oe at ifi.uio.no; oe at csli.stanford.edu; stephan at oepen.net ---

More information about the developers mailing list