Hi Scott, The "DITATopicCustomRuleMatcher" java class is where the magic happens :) It's quite hard to identify a DITA topic or map, it could use the base public IDs or it could refer to specialization DTDs, it could have various root element names, but the "DITATopicCustomRuleMatcher" Java class looks at various default attributes specified in the DTD like the "ditaarch:DITAArchVersion" attribute to decide if an opened XML document is actually a DITA topic or map. https://www.oxygenxml.com/InstData/Editor/SDK/javadoc/ro/sync/ecss/extension...) So with this extra rule added at the end of all other rules, our base "DITA" and "DITA Map" frameworks will be applied on any kind of specialized DITA XML topic or map, without the end user having to create a special DITA framework extension to match their type of documents. But once people start to create DITA framework extensions (like you do) for special DTD public ID, this extra rule placed at the end would no longer be necessary to you because you know that your topics and maps refer to specific DTDs. So I think it's correct that you are only using some very specific association rules in your DITA framework customization which no longer include our "DITATopicCustomRuleMatcher" class. About this behavior:
but I think I'm seeing that after I remove all but the necessary rules from a particular framework, after some time, additional rules are added. When I close and save the framework, sometime later I go back and there are rules that match on Root Local Name .. concept, task, reference, etc. .. I'd swear I didn't add those. Do I have gremlins, or is this a feature? This would be a bug, but we would need some way to consistently reproduce it.
Regards, Radu Radu Coravu Oxygen XML Editor On 10/18/23 01:54, Scott Prentice wrote:
I've got two different DITA models that are similar, and each may be edited at the same time in Oxygen. Their DTDs are different and use different Public IDs. I'm developing a framework for each which applies slightly different schematron validation and CSS styling. It's my understanding that I should be able to target each model using the Association Rules, and in general this seems to work fine.
Since I'm trying to be very specific about which documents are to use each framework, I thought I'd keep the Association Rules to a minimum, basically just the specific Public IDs. It's my understanding that if a document matches any one of these rules, the framework will be applied .. so no need to include extra match rules .. right?
One association rule that I see on many DITA frameworks is a Java Class rule of ..
ro.sync.ecss.extensions.dita.topic.DITATopicCustomRuleMatcher
Can someone tell me what this does and is it needed in all cases?
Also .. and I may be mistaken .. but I think I'm seeing that after I remove all but the necessary rules from a particular framework, after some time, additional rules are added. When I close and save the framework, sometime later I go back and there are rules that match on Root Local Name .. concept, task, reference, etc. .. I'd swear I didn't add those. Do I have gremlins, or is this a feature?
Thanks!
...scott
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user