Support for multiple values for schemaSpec/@docLang

[lb42]

The value of @docLang on schemaSpec is used to determine which <desc> elements are passed through to a RELAXNG schema as documentation elements, subsequently to appear as popup tool tips in oxygen. At the moment if multiple languages are specified (e.g. @docLang="de fr") this is interpreted as a single value "de fr" which does not exist, and the documentation is thus generated in English by default. It would be better either to flag this as an error, or much better to generate multiple documentation elements, each with an appropriate @xml:lang, which oxygen can then use appropriately.

Issue raised on TEI-L by Matthias Muller on 2016-02-03

[sydb]

Stylesheets group met today and discussed this ticket. It brings up lots of interesting XSLT issues if you dig down into it, but the higher-level issue of interest is What should happen if a <schemaSpec> has a @docLang with multiple values? Clearly it is not an error (the schema explicitly permits it; and some parts of the XSLT allow for it, although others do not), but what would a user want or expect to happen when @docLang="de fr it en" (I guess this is a Swiss user.)

1. Four separate outputs, each with <desc>s in one of the specfied languages (where available)?
2. One output with each <desc> in German if it is available in German, if not then in French if it is available in French, if not then in Italian if it is available in Italian, and if not available in any of those then in English?
3. One output which has (up to) 4 descriptions of each element, attribute, etc.

And, of course, the RELAX NG would correspond: 1. Four separate schemas, 2. One schema where each component gets a corresponding annotation that has a single description in one of four languages (in the order of preference specfied), 3. One schema where each component gets a corresponding annotation that has (up to) four descriptions in different languages.

[lb42]

If oxyGen can handle it, my preference (which I thought I had stated on the ticket) would be for option 3. If not, option 1. Option 2 is not one I would entertain.

[jamescummings]

The more I think about it the more I'm starting to favour number 3. That said, isn't a fourth option to have a processing parameter that says how to deal with this in schema generation? (i.e. to take all or take this specific one(s)?) Maybe that is the intent behind the many language-related parameters we have already that @martindholmes mentioned.

[lb42]

There is also a fifth option, which is to flag provision of multiple values as an error, or at least "not currently implemented". That would be the easiest option!

[sydb]

Yea, verily.

So, in order of my guess at degree of difficulty:

• (5) Warning message (“not currently implemented: first value ‘XX’ will be used”, or whatever)
• (1) Multiple separate outputs.
• (2) One output w/ a single language selected for each construct, chosen from those available by selecting those requested, in the order provided
• (3) One output w/ multiple glosses and descriptions in as many of chosen languages as are available (in order provided?)
• (4) A switch which says which of (1), (2), or (3) to do. (What’s the default?)

[lb42]

Option 2 (but not necessarily option 3) implies that the order of the components of a multivalued attribute string is significant. So I dislike it.

[sydb]

@martindholmes points out that the schema and the HTML (or ePub or whatever) output do not have to have the same solution — schemas should probably always have all langues. (Solution (3) for schemas, undecided for documentation.)

[sydb]

Stylesheets group agrees that this is important to do after translations have been improved, but still not particularly high priority, and until then outright low priority. So we agree to go with solution (5) for now until #138 is dealt with, and perhaps we have a better system in place for getting improved gloss and description translations faster.

[sydb]

@sydb to add wanring message, all to test and see if we think the output thereof is sufficient warning.

[martindholmes]

Another option would be to generate two separate versions of the schema initially, but then merge them in a subsequent operation. That might actually be much easier to accomplish.

[sydb]

Was I supposed to add this warning message to the ODD processor that finds 2+ values on @docLang, or to the tagdoc that describes the @docLang attribute? (Or both?)