<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="Verdana">Thanks, Radu!</font></p>
<p><font face="Verdana">That's sorta what I was assuming, but wanted
to make sue there wasn't some special reason that entry was
needed for "all" DITA-based frameworks. Yes, after removing the
"DITATopicCustomRuleMatcher" java class entry, the matching
seems to work as expected. Nice. Simple is good. :-)</font></p>
<p><font face="Verdana">And, regarding he gremlin behavior .. so far
I'm not seeing anything unexpected. Perhaps I was being careless
at the end of the day .. hard to believe, I know. Fingers
crossed.</font></p>
<p><font face="Verdana">All the best,</font></p>
<p><font face="Verdana">Scott<br>
</font></p>
<pre class="moz-signature" cols="72">
</pre>
<div class="moz-cite-prefix">On 10/17/23 11:19 PM, Oxygen XML Editor
Support (Radu Coravu) wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2b216fd2-1a6a-488b-b97d-ad62f964cafb@oxygenxml.com">Hi
Scott,
<br>
<br>
The "DITATopicCustomRuleMatcher" java class is where the magic
happens :)
<br>
<br>
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.
<br>
<br>
<a class="moz-txt-link-freetext" href="https://www.oxygenxml.com/InstData/Editor/SDK/javadoc/ro/sync/ecss/extensions/dita/topic/DITATopicCustomRuleMatcher.html#matches(java.lang.String,java.lang.String,java.lang.String,java.lang.String,org.xml.sax.Attributes)">https://www.oxygenxml.com/InstData/Editor/SDK/javadoc/ro/sync/ecss/extensions/dita/topic/DITATopicCustomRuleMatcher.html#matches(java.lang.String,java.lang.String,java.lang.String,java.lang.String,org.xml.sax.Attributes)</a>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
About this behavior:
<br>
<br>
<blockquote type="cite">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? </blockquote>
This would be a bug, but we would need some way to consistently
reproduce it.
<br>
<br>
Regards,
<br>
<br>
Radu
<br>
<br>
Radu Coravu
<br>
Oxygen XML Editor
<br>
<br>
On 10/18/23 01:54, Scott Prentice wrote:
<br>
<blockquote type="cite">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.
<br>
<br>
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?
<br>
<br>
One association rule that I see on many DITA frameworks is a
Java Class rule of ..
<br>
<br>
ro.sync.ecss.extensions.dita.topic.DITATopicCustomRuleMatcher
<br>
<br>
Can someone tell me what this does and is it needed in all
cases?
<br>
<br>
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?
<br>
<br>
Thanks!
<br>
<br>
...scott
<br>
<br>
<br>
<br>
_______________________________________________
<br>
oXygen-user mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:oXygen-user@oxygenxml.com">oXygen-user@oxygenxml.com</a>
<br>
<a class="moz-txt-link-freetext" href="https://www.oxygenxml.com/mailman/listinfo/oxygen-user">https://www.oxygenxml.com/mailman/listinfo/oxygen-user</a>
<br>
</blockquote>
<br>
_______________________________________________
<br>
oXygen-user mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:oXygen-user@oxygenxml.com">oXygen-user@oxygenxml.com</a>
<br>
<a class="moz-txt-link-freetext" href="https://www.oxygenxml.com/mailman/listinfo/oxygen-user">https://www.oxygenxml.com/mailman/listinfo/oxygen-user</a>
<br>
</blockquote>
</body>
</html>