Backwards-compatibility of LIFT
Dave
was mistaken in an assumption I was making regarding the backwards-
compatibility of LIFT. He suggested I send a message to the group to
get your thoughts, so here it is!
I was under the impression that since all newer versions of LIFT are
guaranteed to be backwards-compatible with previous versions, the onus
is on the developer of the target (import) application to simply
ignore anything it doesn’t know about. Thus, if I output 0.13 but the
target application only knows about 0.12, it simply ignores the
elements/attributes it doesn't know about.
Thus, LIFT behaves like RTF. I can save in the latest version of RTF,
but open it in a program that was written when RTF was three versions
older. I may not get all the features, but it still opens and handles
the RTF tags that it does know, while ignoring the ones it doesn't
understand (or care about.)
The impression I got from John is that my assumption is not accurate,
i.e. applications are simply failing if they receive a newer LIFT
version file. I'm wondering if it's too late to turn the tide on this
and encourage LIFT-compatible readers to degrade gracefully
I realize this makes the import process more difficult for us
developers, but hey, that's our job! The alternatives, as I see it,
are either:
(1) We suddenly break functionality for users. If I export LIFT 0.12
and the user imports it into an application that understands 0.12,
everything is fine. But then they upgrade to the latest version of my
application, which now exports 0.13, and suddenly their import fails.
It forces an extremely tight upgrade-coupling between the
applications, which I doubt most of our users will find undertandable
or possible. The way upgrades happen in the field ("I got this last
year from the translation conference ... do you want to try it?")
guarantees this will be a frequent experience. We routinely receive
"new registrations" for versions that are 3-5 years old. To expect
users to simultaneously upgrade applications from different vendors is
unreasonable.
(2) Or we implement multiple export formats and force the user to
select the right version at the point of export. ("Do you want version
0.10? 0.11? 0.12? 0.13?...") I doubt this will make much sense to many
users. ("How do I know what version I want? I want to go to ProgramX.
Is that version 0.10?")
Either alternative puts the onus on the end-user, which seems
unreasonable to me when, technically speaking, the specification opens
the possibility of handling everything "under the hood."
Thoughts?
Dave Mateer
Cambell Prince
Here's my take on the issue. Comments below.
Dave wrote:
> I was under the impression that since all newer versions of LIFT are
> guaranteed to be backwards-compatible with previous versions, the onus
> is on the developer of the target (import) application to simply
> ignore anything it doesn’t know about. Thus, if I output 0.13 but the
> target application only knows about 0.12, it simply ignores the
> elements/attributes it doesn't know about.
>
>
That would be fine. The intention I think, is that Lift changes slowly
and is backwards compatible. That is, there is a reasonable migration
path from one version to the next.
> Thus, LIFT behaves like RTF. I can save in the latest version of RTF,
> but open it in a program that was written when RTF was three versions
> older. I may not get all the features, but it still opens and handles
> the RTF tags that it does know, while ignoring the ones it doesn't
> understand (or care about.)
>
>
To play nicely with others there are certain obligations on software.
This isn't explicit in the lift standard per se, but makes sense.
Perhaps these could be come recommended practices for implementors.
- If the input complies with the schema, then your app must round trip
the file correctly. Including elements you don't use. The principle of
'do no harm' to the data.
- The app *could* have a go at importing lift that is 'future' from it's
perspective. e.g. last build with say 10 and trying to load 13. The 'do
no harm' above should help there.
As you say, some apps at the moment just don't load future (to them)
versions.
> The impression I got from John is that my assumption is not accurate,
> i.e. applications are simply failing if they receive a newer LIFT
> version file. I'm wondering if it's too late to turn the tide on this
> and encourage LIFT-compatible readers to degrade gracefully
>
No it's not too late. Certainly I don't think anyone is advocating that
apps just fail on new lift.
> I realize this makes the import process more difficult for us
> developers, but hey, that's our job!
Agree whole heartedly.
Some times, to inter-operate with a particular app tools might have to
'down grade' the lift. One idea that we've had floating around is that
we provide some transforms (or whatever) to save our model to current
lift, and back to older lift also.
WeSay for example has the save to lift suitable for flex 5.4 which had
limited lift import export capability.
> The alternatives, as I see it,
> are either:
>
>
As you say, the alternatives are not pleasant.
Regards,
Cambell
John Hatton
apps just fail on new lift.
I sure am, and that's exactly what WeSay and FLEx do. Maybe I'm just
overwhelmed with how much lift-related code and features I'm responsible
for... from where I sit, I can't imagine taking on the burden of "doing no
harm" to a format that was created after I wrote the code, which has a
schema that I don't posses. I'm not going there, and I don't want to get
the bug reports when my software tries to read the results of others who do
go there. I'm already tired of the bug reports that go "when I open the
LIFT I exported from _____ into wesay, it says these awful things like 'the
<entry> element was not closed'. What's wrong with WeSay?"
John Hatton
SIL PNG, Palaso, & SIL International Software Development
Google Talk chat: hattonjohn
Dave Mateer
First, I don't think it's reasonable to support malformed Xml. If--like in your example below--an <entry> tag is not closed, or for that matter, if I send you a tab-delimited list and call it "LIFT," of course we fail. No need to go there.
The situation I am envisioning is where an application exports fully LIFT-compliant data in a later version than the import application knows about. Based
on the LIFT specification (under the section entitled "Stability"), any elements and attributes it knows about up to the previous version are guaranteed to still be available--though perhaps deprecated. Additional elements and attributes can be ignored.
I could see this being implemented in a maintainable way by a series of XSLT documents, one for each version. Each transform reads a LIFT file and transforms it into exactly the version it is targeting (by only transforming the elements and attributes it knows about; the rest are lost). Thus, you would have a Lift_TransformLaterVersionTo_0_10.xslt, Lift_TransformLaterVersionTo_0_11.xslt, etc. A simple "transforming library" (probably a few lines of code, depending on your language of choice) could then be used to run this transform in the case of a later version discovered. The receiving application would only have to include exactly one XSLT document--the version it expects. The transforming application could remain exactly the same between versions of the receiving application, just a new XSLT swapped in if they want to support a later version of LIFT. Not a big load on developers. The burden is creating a new XSLT document each time a version is released, which requires a knowledge of the LIFT specification up to that point. This would be part of the LIFT project. It would be up to the applications how to handle this. Obviously, preserving the information round-trip is not possible. A warning about loss of data would be appropriate. (Much like saving a Word 2007 document in 2003 format, for example.)
Without this--and I'm not trying to be inflammatory here, but say this because I want to see the format succeed--the "I" in LIFT becomes very, very limited if you can only interchange lexicon information when you as an end user are careful to preserve software versions that happen to import and export the same LIFT version. In areas where Internet access is readily available, that might be reasonable (although I still contend this is confusing for your average user), but out where many of our missionaries serve, this just isn't going to happen.
The support issues mentioned previously are exactly my concern. If LIFT is too fragile, so that users suddenly lose the ability to exchange their lexicon when they UPGRADE one application to a newer version, I'm simply not going to include it. I can't support walking people in remote locations through the process of making sure they keep applications from different vendors in sync. Of course, the reality is when this happens (sudden functionality loss), users revert to something more stable, like Excel or Word, to maintain their lexicon. They lose out on all the extra helpful features, but that security that they aren't going to lose their data in the middle of a church plant is worth it. I don't want to see the LIFT specification fail, because there is great potential here. But to be stable, my opinion is that we ought to do as much as we can to handle it like RTF, and degrade gracefully when it's possible to do so.
Dave