Moses-support Digest, Vol 84, Issue 27

Send Moses-support mailing list submissions to
moses-support@mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.mit.edu/mailman/listinfo/moses-support
or, via email, send a message with subject or body 'help' to
moses-support-request@mit.edu

You can reach the person managing the list at
moses-support-owner@mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Moses-support digest..."


Today's Topics:

1. Re: Placeholders (Achim Ruopp)


----------------------------------------------------------------------

Message: 1
Date: Wed, 16 Oct 2013 12:16:51 -0400
From: "Achim Ruopp" <achimru@gmail.com>
Subject: Re: [Moses-support] Placeholders
To: <support@precisiontranslationtools.com>, <moses-support@mit.edu>
Message-ID: <010801ceca8b$1ffd6c50$5ff844f0$@com>
Content-Type: text/plain; charset="utf-8"

<anytag/> is XML-compliant in schema-less XML (as long as the tag name complies to http://www.w3.org/TR/REC-xml/#NT-Name)



IMHO Moses input (with the -xml-input option) should stay schema-less, or we should define a schema. Right now I can't see a pressing reason to define a schema.



In any case it would be good to parse the input (with the -xml-input option) with a proper XML parser, e.g.

http://www.boost.org/doc/libs/1_54_0/doc/html/boost_propertytree/parsers.html#boost_propertytree.parsers.xml_parser

There are probably better XML parsers, but Moses already requires Boost. Using an XML parser could also solve some of the character escaping uncertainty.



Achim



From: moses-support-bounces@mit.edu [mailto:moses-support-bounces@mit.edu] On Behalf Of support@precisiontranslationtools.com
Sent: Tuesday, October 15, 2013 10:25 PM
To: moses-support@mit.edu
Subject: Re: [Moses-support] Placeholders



A change from <anytag/> will no-doubt disrupt existing pipelines. Communicating the change with the new release will be a great help.



On 2013-10-15 01:35, Hieu Hoang wrote:

they're good ideas. I'll have a think if I get round to doing it.

Would also want to minimise the work I have to do, and minimize the disruption to people's existing pipeline.



On 15 October 2013 01:33, Tom Hoar <tahoar@precisiontranslationtools.com> wrote:

I agree that <anytag/> could cause problems, especially with the growing
list of reserved tag names (ne, wall, zone). I wholeheartedly support a
fixed tag, but I'm not sure "option" is it. What about <np/> (already in
the manual) or <xml-markup/> or <xml-input/> or <moses/>?

Here's another idea. The -xml-input flag supports values "exclusive,"
"inclusive," "ignore" and "pass-through." What about changing the flag
to a boolean flag. Then, use the value as the xml tags: <exclusive/>,
<inclusive/> and <ignore/> so the one invocation of Moses would support
all modes on a per-sentence basis. Just a thought. Think this would also
be easier if you dropped the "pass-through" option because no need for
backwards compatibility.

Another idea, although slightly different subject. Moses'
-monotone-at-punctuation flag would be more useful if we could
define/override the punctuation & symbols that we want it to use. Not
sure how to best accomplish this.

Tom




On 10/15/2013 04:07 AM, Hieu Hoang wrote:
> In fact, we're thinking of changing <anytag/> to something fixed, like
> <option/>
>
> The <anytag/> behaviour isn't good XML and will cause problems in the
> future
>
> Any opinions on this gratefully received
>

_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support




--
Hieu Hoang
Research Associate
University of Edinburgh
http://www.hoang.co.uk/hieu



_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20131016/816edea4/attachment-0001.htm

------------------------------

_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support


End of Moses-support Digest, Vol 84, Issue 27
*********************************************

Tweet