Re: Advantages & Disadvantages of ProXML over Python

From: Mark Huckvale (M.Huckvale@ucl.ac.uk)
Date: Tue Nov 28 2000 - 14:29:32 GMT

  • Next message: Mark Wainwright: "Re: Advantages & Disadvantages of ProXML over Python"

    At 11:18 27/11/00 +0000, you wrote:
    >[From an earlier message of Mark H's:]
    >
    >>>> I would like to hear someone describe what the disadvantages of
    >>>> changing to ProXML are.
    >
    >As I see it they are (i) the time taken,

    I don't see why it should take longer to use a language optimised
    for the job rather than a general purpose language.

    (iii) the danger of hidden "traps" -- technical or
    >other problems with the re-write that might come to light half-way down
    >the road.

    Surely with our own code, we have complete control over this.

    (iv) rules written directly in ProXML, or any
    >programming language, might look even more unattractive to a linguist
    >than the current Procsy rules.

    I don't agree at all. ProXML is specifically designed for looking
    at hierarchical data. This is exactly the phonological structure
    we propose to be important. Where ProXML is ugly is when the knowledge
    doesn't match the theory.

    >Functionality: ProXML is an elegant language for changing values of
    >attributes on an XML file with a reasonable amount of computational
    >power. But that's not what Procsy does, and the most obvious things
    >it currently does that ProXML can't easily handle are:
    >
    > reading in other files (the .x file)

    I haven't put this in because I didn't think that PROSY would need to
    read in ESPS files.

    > examining the next node in sequence of a particular type
    > (used in current Procsy rules like "if SEG+1: NAS is Y then ...")

    There are a number of mechanisms for this, all more flexible than the
    existing Python code.

    > building up a data structure for output
    > writing out a structured file at the end of processing

    Mark and I agreed that we would probably need: (i) dynamic allocation of
    data tables and (ii) more control over the times at which procedures
    are called. I expected that we would need to add this.

    In summary, we could end up with a set of scripts for synthesis
    which just used XML for linguistic representations and proXML for
    knowledge representation. Or we could have a motley collection of
    C programs, Python programs, intermediate text files and rules designed
    to work on linear phonological representations.

    Mark



    This archive was generated by hypermail 2b29 : Tue Nov 28 2000 - 14:28:34 GMT