I follow John Hatton's suggestion to repost the problem I seem to have
encountered when dealing with the .lift-ranges file exported as 'full
lexicon' from FLEx 7.0.6-beta (Ubuntu natty).
The FLEx list thread is here:
http://groups.google.com/group/flex-list/browse_thread/thread/b706f02ed316c30f
and the problem, in a nutshell, is this (with apologies for repetition):
The following fragment comes from .lift-ranges, exported from FLEx, in
which I enabled Bantu noun classes for nouns. One of the differences
between this export and the export without noun classes enabled is that
the <trait> element got added.
The problem with that fragment is that <trait> is not licensed in this
position in the LIFT 0.13 schema -- it may not be a child of
<range-element>.
<range-element guid="93bca1bc-f405-49cc-9a6a-ca1d3dd3b117" id="Noun">
<label>
<form lang="en"><text>Noun</text></form>
</label>
<abbrev>
<form lang="en"><text>n</text></form>
</abbrev>
<description>
<form lang="en"><text>A noun is a broad classification of parts of
speech which include substantives and nominals.</text></form>
</description>
<trait name="inflectable-feat" value="nagr"></trait>
</range-element>
range-element is defined in LIFT 0.13 as:
<define name="range-element-content">
<attribute name="id"/>
<optional>
<!-- refers to another range-element's id -->
<attribute name="parent"/>
</optional>
<optional>
<attribute name="guid"/>
</optional>
<interleave>
<optional>
<element name="description">
<ref name="multitext-content"/>
</element>
</optional>
<optional>
<element name="label">
<ref name="multitext-content"/>
</element>
</optional>
<optional>
<element name="abbrev">
<ref name="multitext-content"/>
</element>
</optional>
</interleave>
</define>
The question now is whether this is a FLEx issue (allowing for
unconstrained content of .lift-ranges) or a LIFT issue (missing the
intent expressed in .lift-ranges).
Best regards,
Piotr
The standard fields allowed in LIFT 0.13 don't contain all the
information needed for some of the complex range types, especially when
it comes to grammatical information. This problem motivated the changes
you noticed in the (never implemented) LIFT 0.14. I expect to get LIFT
0.15 implemented in the Palaso library soon, which will enable Flex (and
presumably WeSay and other LIFT consumers) to handle this new version.
I apologize for the confusion this has caused.
--
Steve McConnel
> X-Quarantine ID /var/spool/MD-Quarantine/20/qdir-2011-11-28-20.51.05-001
jh
-----Original Message-----
From: lexiconinter...@googlegroups.com
[mailto:lexiconinter...@googlegroups.com] On Behalf Of Steve
McConnel
Sent: Tuesday, November 29, 2011 9:07 AM
To: lexiconinter...@googlegroups.com
Cc: Piotr Bański
Subject: Re: [LIFT] the schema of .lift-range in FLEx is not 0.13
It's true that Flex puts out information in the .lift-ranges file that
does not fit the LIFT 0.13 standard. (I think it will fit the LIFT 0.15
standard, however.) Since WeSay doesn't look at the .lift-ranges file (at
least it hasn't in the past), and since Flex doesn't apply the schema to the
.lift-ranges file (since it's really a bit different than the real LIFT
file), it seemed harmless to jump the gun (so to speak) in adding this to
the LIFT export and import in Flex.
The standard fields allowed in LIFT 0.13 don't contain all the information
needed for some of the complex range types, especially when it comes to
grammatical information. This problem motivated the changes you noticed in
the (never implemented) LIFT 0.14. I expect to get LIFT
0.15 implemented in the Palaso library soon, which will enable Flex (and
presumably WeSay and other LIFT consumers) to handle this new version.
I apologize for the confusion this has caused.
--
Steve McConnel
Sometime in the near future, Flex will support LIFT version 0.15. This
needs to be coordinated with WeSay, and possibly other LIFT
consuming/producing programs.
--
Steve McConnel