recursive framework extension / derivation

[kai_weber]

After having already spent quite a while editing a framework definition which is derived / extended from another oXygen framework, I noticed that I cannot derive frameworks recursively: If my framework B is derived from framework A, I cannot create a derived framework C from B. If I do so, I get another framework C directly derived from A.

I can very much understand the implementer's point of view that they want to limit problems arising from transitive / recursive extension relationships. So this is not a feature request. However, I wonder what is the best way to deal with a situation, where I want to share settings, code, images, schemas, resources etc. between several, somewhat related frameworks. Here are the options that came to my mind:

1. I could just follow the approach that oXygen suggests: Derive frameworks B and C from A independently. Problem: B and C have a lot in common, so that would mean a lot of settings and resources for Author actions, buttons, CSS, schema, transformations would have to be duplicated and maintained separately. This approach does not scale well - what if I need further frameworks D, E, F that share settings with B and C (but not with A)?

2. I could try to make B a new base framework: I create a hard copy of framework A, customize it to my needs and call it B. I derive C from B, just adding / changing, what's different in C, as compared to B. This approach is OK, but the disadvantage is: A is an open source framework maintained by a community. I will lose the chance to easily update framework A without too much manual labour. If I need functionality of newer versions of A in my new base framework B, I will have to manually copy and sort it out.

3. I am already using an oXygen project file with my setup anyway. I could switch from "external" to "internal" storage of my frameworks and marry the framework definitions with the project file settings. Whereever my frameworks B and C need to access common resources (like e. g. images for buttons, common schema or template files, etc.), I would refer to them using the ${pd} editor variable instead of ${frameworkDir}. I will not be able to use my framework definitions independently from my project file anymore, but that is a price I might be willing to pay for not having to maintain duplicate versions of shared resources. I could still derive B and C from A and install updates of framework A when needed. But even though I don't have to maintain duplicate resources, I might still have to maintain quite a few duplicate definitions. (If I want to change the image file name for an Author action, I would have to adjust the Author action in every framework definition that is using this button image.)

So, none of the strategies is ideal, but I have a tendency of going down path number 3. But before I decide about that, I'd like to hear from the oXygen community, if there are any other possible solutions that I may have overlooked, and that are potentially easier or more flexible to be maintained.

Best regards,
Kai

[Radu]

Hello Kay,

Starting with Oxygen 23.1 we added a new way to extend frameworks named the "framework extension script":
https://blog.oxygenxml.com/topics/custo ... cript.html
There are links to the user's guide and to a webinar at the end of that article.

Such extension scripts can define extensions of base frameworks and you can extend them multiple times as opposed to the framework extension which can be done only once.
Also Author actions can be saved externally, outside of the .framework configuration file and then used from the script:
https://www.oxygenxml.com/doc/versions/ ... _section_2

Regards,
Radu

[kai_weber]

Dear Radu,

I knew you'd be coming up with helpful suggestions, thanks a lot. Both approaches sound better than the ideas I had myself.

Best regards,
Kai

[kai_weber]

Dear Radu,

I've had a look at the extension script approach now, but it seems that there is a limitation concerning the handling of an associated schema. Is it correct that I cannot change the associated schema in a framework extension script, i. e. I always have to use the schema association from the base framework that I am extending?

Best regards,
Kai

[alex_jitianu]

Hi Kai,

That's true, right now you can't specify a default schema in the script. We have a issue recorded, but we didn't get the time to implement it. If I understand it correctly, your XML documents do not have a schema association in them? If they have, the association will be passed through catalogs and the default schema is not really relevant.

Best regards,
Alex

[kai_weber]

Hi Alex,
no, our documents don't have explicit schema associations. We could possibly add them, though.

The base framework uses TEI_all as its schema, which we would like to restrict the schema to just the required subset of elements - as it is common in the TEI community. Sure, there might be other ways... We could live with the TEI_all schema association from the base framework and try to just restrict the autocompletion setup in the derived framework to suppress elements we don't want the authors / editors to use, but that might be a lot of extra customization work, in a non-standard way. (ODD is certainly the best standard-conformant way to do TEI schema customizations...)

[kai_weber]

I just saw in the release notes of oXygen v25.1 that you implemented the feature I was missing (setting of a default schema via framework extension script). Thanks a lot for such a swift action!

[alex_jitianu]

Hi,
I was under the impression that I notified all those that stumbled on this limitation, but apparently I missed some channels. Sorry about that! It's a good thing you've seen it in the release notes!
Best regards,
Alex