alternative handling of schema and ODD files

[bansp]

This is a potential enhancement for handling schemas and ODD, if the current situation is seen as suboptimal.
Sebastian mentions elsewhere that symlinking the ODDs and schemas in each dictionary directory may still cause problems on some systems (if I understand it correctly).

One way to handle that would be for the source distribution packages to always contain two directories: the directory of the dictionary and the shared/ directory. So, for example, the ara-eng dictionary would be packed as follows:

ara-eng.tgz
        ara-eng/
            ara-eng.tei
            README
            Makefile
            COPYING
            INSTALL
            ...
        shared/
            Freedict-P5.rng
            Freedict-P5.xml

At the same time, the top of each dictionary would have to contain the following lines:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="../shared/freedict-P5.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="../shared/freedict-P5.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<TEI xmlns="http://www.tei-c.org/ns/1.0">
...

The <?xml-model> processing instruction is by now so standard that it should suffice to state the association between the dictionary document and its schema. And the INSTALL would have to contain the command for validating with xmllint, which I think is still unable to read the xml-model instruction (though I may be wrong):

xmllint --noout --relaxng ../shared/freedict-P5.rng lg1-lg2.tei

(The archive listing contains the minimal number of necessary files; some dictionaries would also need the Freedict-ontology; maybe Freedict-P5.dtd would have to be included under shared/ as well, in case some users for some unknown reason needed to use that.)

The above is only relevant if the current setup is suboptimal, of course.

[humenda]

Sebastian mentions elsewhere that symlinking the ODDs and schemas in each dictionary directory may still cause problems on some systems (if I understand it correctly).

I asked in another issue about including the schemas with the tooling. To what respect is this not optimal? A dictionary should be buildable with a certain version of the tooling. Eng-deu in 0.1 required the possibly oldest version of freedict-tools, no t versioned back then. eng-deu 1.8.1 requires fd-tools 0.5.0. It looks natural to me to include the schemas in each version of the tools.

One way to handle that would be for the source distribution packages to always contain two directories: the directory of the dictionary and the shared/ directory.

That is an imperfect solution, IMHO.

**The above is only relevant if the current setup is suboptimal**, of course.

Can you please elaborate on this? I suppose most of our contributors use the suboptimal setting :).

[bansp]

Overall admission: I shouldn't have given this ticket the label "enhancement". I was looking for something like "discussion" and went for the more or less closest thing. Gonna remove that label.

And now, regarding each of your three comments:

1. why don't we continue talking about the placement of schemas where I replied to your comment on removing schemas from fd_dictionaries, namely at issue 62? The discussion will be easier to manage, that way, and for others to chime in, if they wish. I'll copy your paragraph from above and will reply to it, hoping that that's all right with you.
2. if turning symlinks into hard links while creating an archive is for some reason bad, nowadays (it used to be bad, with early SVN, but that was long ago on another platform) then the above solution is a relatively elegant alternative (because it preserves the project directory structure, so it's easier to go from a small bit of the project to the full view); it may be less perfect than the currently existing solution, but I don't have an objective scale to measure these solutions against; and I never said I want things to be as above -- it's just an option that I thought worth mentioning, if the current state of affairs is for some reason 'wrong'.
3. no, I can't elaborate on why symlinking is bad, because that was your claim, or at least that's what I understood (if I understood you wrong, then let's close the current issue, please); I think symlinking works well, and far far better than it did in the early SVN, and since it works well, I don't really see any advantage in breaking stuff that ain't broken :-)