directory structure
Martin Hosken
People are talking about the need to standardise a directory structure to account for ancillary data that can accompany a lift file, for example audio files or pictures.
To be honest, I'm not sure what the fuss is about, but I do realise it does expose a bug in the standard. At least that's where I'm coming from.
As far as LIFT is concerned, it doesn't care where other files are. So long as the reference points to the file, it can be anywhere. So there is no requirement for a standard place for these files. But, once that LIFT file moves to another machine, there is a requirement that that LIFT file can also access the ancillary files given the same URI.
I propose that we tighten the specification of URL to be:
URL
A URI reference as specified in RFC 3986 with the added constraint that a file: type or unspecified scheme must use a relative reference (relative to the LIFT file) with an empty authority and with the path not being absolute. This allows for off system referencing using such schemes as http:, ftp: etc.
I can understand for project merging why people would a) not want ancillary files to move or change filename and b) be held in the same project tree. I can see the temptation to therefore want to specify the tree structure, and that's fine, but probably this needs to be part of a standard project layout.
But then I'm probably missing a huge elephant that is about to rest its trunk on my shoulder and make me think a huge "duh!". So if someone could point out the elephant, that would help me.
TIA,
GB,
Martin
John Hatton
Thanks for brining this up. Let's look at what would happens if people just
put the images wherever. An app reads the url, it can show the image. No
problem so far. But now it wants to edit the image (crop, make grey-scale,
compress since it's so small in the dictionary). Is that ok? Well, it sure
matters where the image lives, doesn't it? If it lives inside the proposed
lift directory, it's likely ok, the image is there for the dictionary. But
if it's elsewhere... maybe the user will be surprised to find that the
original copy was just changed. (and if someone says "just ask them", like
that's cheap, I say make sure you get yourself a a user-interaction
specialist on your next project).
Next problem. In your app, the user adds a new picture. Do you link to it,
or copy it? (I know, just ask the user and hope they are also a geek who
has a clue what you're talking about). Ok.... somehow you decide you should
copy it into the lift folder. But where? There's no standard. So if the
user has two apps that work with the dictionary, maybe they have an "images"
folder and an "illustrations" one. And all these things are true of audio,
as well. Or let's say you decide *not* to copy it in to the LIFT folder.
Now, when you go to print and the URL doesn't resolve anymore, what do you
do? Well, you could add a nice pre-publication tool to point these problems
out to the user... sigh.
Ok, so I admit, nothing goes up in smoke with this flexibility, it's just a
wee bit too messy for my tastes. And I can't seem to ever remember what it
bought the user.
Note, it doesn't affect me whether this is part of the LIFT standard or not,
so long as my clients have applications which all do the same thing, to keep
their life simple. So far, this is happening; the early, dominant LIFT apps
are carving out path along which other apps will find it easiest to follow.
We now have 3 apps informally using "images" & "audio". The next directory I
hope to see WeSay, FLEx, and DictionaryExpress use is "stylesheets".
John Hatton
SIL PNG, Palaso, & SIL International Software Development
Google Talk chat: hattonjohn
-----Original Message-----m
From: lexiconinter...@googlegroups.com
[mailto:lexiconinter...@googlegroups.com] On Behalf Of Martin
Hosken
Sent: 01 October, 2009 2:02 PM
To: lexiconinter...@googlegroups.com
Subject: [LIFT] directory structure
cambell
Well, we do need agreement on so many things when it comes to
interoperability between our various apps. If apps deal with
referenced media / writing systems etc then they should do so in a
common way.
1) media.
Sure, URI in general is fine. As is saying that file refs should be
relative to the lift file. But I think we all are after something
more. If we put a media file on disk, where should we best put it to
promote interoperability?
Agreed this is heading towards a project folder structure. But, lets
keep the scope to just lexicon, promoting interoperability between
lexicon apps.
How about introducing some recommendations which are not normative,
but are at least published along with the standard so that we
implementers can follow one another.
e.g.
For audio, the folder with respect to the lift file 'audio'
For images, the folder with respect to the lift file 'pictures'
For video, the folder with respect to the lift file 'video'
I'd be happy with just 'media', with the type of media being defined
by the file extension / mime type as per the OS. But the above is the
way WeSay currently does it, and doesn't seem bad to me.
2) Traits and Fields
Recently with the work that Stephen and John have done on getting Flex
and WeSay working together has introduced new names etc that need to
be documented for others to follow if they want to do the same sort of
thing.
Could this be a similar sort of recommendation?
<side note>
The thing is that XML is a standard that doesn't say much. It's a
container format. Now lift defines a certain basic ontology for
lexicon, and the 'container' for extensions. But where others want to
interoperate with these extensions we need some way of documenting
them for all to see so that when implementing feature x we can operate
in the same way, using the same ontology as other tools.
</side note>
3) Writing Systems
I suggest that we have a folder 'ldml' to store writing system info
in. The file format for these files *may* be the same as that
described here:
http://projects.palaso.org/repositories/entry/palaso-doc/LdmlExtensions-Draft.pdf
This probably needs to be another lift like standard in it's own
right.
Regards,
Cambell