proposal for extending <range-element>

[Stephen McConnel]

Could range-element inherit from extensible? This would help FLEx in a
number of places where the simple label-abbrev-description triad doesn't
adequately cover the information that needs to be transferred. The FLEx
export and import already does this in a number of places by using trait
elements. I've now encountered a need for (nested) field elements as
well. My past cheating here has gotten through validation because all
of the ranges are written to a separate .lift-ranges file that isn't
validated. :-) :-(

I thought this had already been discussed and agreed to, but I can't
find any record of it in my email archives. This enhancement is implied
(at least to some degree) by my proposal from last week for enhancing
field (and range) definitions (to which nobody has yet responded).
--
Steve McConnel

[John Hatton]

Hi Steve,
Over there, snow has been dumping on you. Over here, work has been piling
up on me just as dramatically, and we're gearing up for 3 weeks of field
work. So I appreciate the time you've put into these proposals, and I think
they're important ones. I apologize that I personally can't give them the
consideration-time they deserve... probably for a few months to come.

On this one in particular, I think we'll need to look at the impact for
WeSay, where traits are modeled just the same as LIFT... as simple strings.
It's painful that nothing in LIFT seems to be safe from a proposal to make
it more expressive, or hierarchical, or whatever. Ah well...

John Hatton
SIL Papua New Guinea, Palaso, & SIL International Software Development
Chat Google Talk: hattonjohn Skype: hattonjohn Google Wave:
hatto...@googlewave.com

[Martin Hosken]

Dear Steve,

> Could range-element inherit from extensible?

Everything is permissible but not everything is helpful ;)

> This would help FLEx in a
> number of places where the simple label-abbrev-description triad doesn't
> adequately cover the information that needs to be transferred. The FLEx
> export and import already does this in a number of places by using trait
> elements. I've now encountered a need for (nested) field elements as
> well. My past cheating here has gotten through validation because all
> of the ranges are written to a separate .lift-ranges file that isn't
> validated. :-) :-(

First question I have is. Are you managing to store everything you need in flex within a lift file or are you already using any kind of either offset markup or extra storage? The reason I ask is that if you are already storing extra information outside lift then much of this information would probably be best stored there rather than in lift.

If you need to be storing stuff in lift, then we really need to know what it is and whether fields are best (and the inherent costs for other implementations) or whether this is stuff that should be modelled. It's always a tough question: if it doesn't need to be modelled then why store it?

GB,
Martin

--
You received this message because you are subscribed to the Google Groups "LexiconInterchangeFormat" group.
To post to this group, send email to lexiconinter...@googlegroups.com.
To unsubscribe from this group, send email to lexiconinterchange...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lexiconinterchangeformat?hl=en.