Issue 453 better support for glossaries

[fsteimke]

This is a big one. I hope it fits in with your plans for further development of the stylesheets.

• separate functions that are designed for a use independent from the stylesheets (so that you can use them in Schematron) in a new file standalone-functions.xsl. It contains a public function f:glossentries.
• Use the function f:glossentries in 50-normalize.xsl to create content for automatic glossaries.
• Since i have no idea to support glossdiv in automatic glossaries, created a new templatet:glossary-content which enables overwriting it.
• some new test cases for the use of automatic glossaries
• new section how to use glossaries in the reference manual
• definition for f:glossentries and `t:glossary-content' in the reference manual

I don't expect this contribution to be adopted as is, but I'd be very happy if my work at least partially contributes to better glossary support in xslTNG.

I tried to avoid the whitespace problems. Please let me know if i could do better.

Greetings, Frank

[fsteimke]

In retrospect, I have identified two problems with this PR:

• there is an error in my code in 50-normalize which prevents the copy of $glossary/info into the resulting glossary;
• relative URIs in glossary-collection should be resolved against base uri of input document, not the static context ( i think this is what the user would expect) I will fix these issues and make an new PR asap Frank

[ndw]

I like what you've done, but I've had to make a few changes.

1. As you note in the comment above, making the glossary-collection URIs absolute is an interesting problem. The only "correct" answer is that they should be made absolute against the processing instruction that defines them. I've added a new variable (v:pi-db-attributes-are-uris) to handle this.
2. You've extended the semantics of the glossary-collection PI to be a list of URIs. I think that's okay, so I'm updating the documentation to reflect that fact.
3. The relative URIs in your glossary examples don't work, but maybe that's related to what they used to resolve against.
4. I've extended the test harness to make the $glossary-collection parameter point to glosscollection.xml by default for most of the glossary tests. (Except the ones that use a PI.)
5. I find the xpath-default-namespace intensly confusing. I've taken it out.
6. The t:glossary-content template is only defined in transforms/50-normalize.xsl so it doesn't fit into the documentation. I'm still trying to work out what to do about that.

It feels like bibliography-collection might need a similar sort of treatment, at least with respect to things like taking a list of values. But I may not try to do that right now.

[ndw]

I'm tempted to take t:glossary-content out. It seems like it might reasonably be considered a bug to have multiple glossary entries for the same entry. There's no mechanism for users to add customizations to the internal transformations, so it's not really practical to provide an alternate definition.

If you have a glossary with multiple entries, you can deal with that when the glossary is being formatted.

[ndw]

No, that doesn't work. You don't want to have multiple versions "visible" to the cross-referencing mechanisms.

[fsteimke]

Thats right, i dont want two glossentries for the same term in my glossary. But a general definition in the shared glossary, and a specific definition in my internal glossary is a use case that we had in practice. The specific entry covers the general definition

[fsteimke]

When I have your solution for Glassaries, I'd be happy to use it as a blueprint for bibliography. There are typically three parts that can be shared and need similar schematron rules in our documents:

• glossaries
• bibliography
• abbreviations/ acronyms