Purpose of mathml entity mapping in catalog.xml

[raducoravu]

The focheck comes with a mapping like:

  <systemSuffix systemIdSuffix="htmlmathml-f.ent" uri="htmlmathml-f.ent"/>

Is there a purpose for the mapping? Could it possibly be re-written to be more specific?
One of our clients used in his DTD something like:

<!ENTITY % bla-f 
     PUBLIC "-//BLA//ENTITIES HTML MathML Set//EN//XML"
         "bla_htmlmathml-f.ent"
    >

and they expected the "bla_htmlmathml-f.ent" to be resolved to their local DTD but because Oxygen also loads the focheck catalog, the entity was mapped to the "htmlmathml-f.ent" located in the focheck framework.

[tgraham-antenna]

Up until now, it was the simplest possible catalog that could be used. Suggestions welcome.

The catalog from https://www.w3.org/2003/entities/2007xml/catalog is:

<catalog  xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">

<rewriteSystem
  id = "w3centities"
  systemIdStartString = "http://www.w3.org/2003/entities/2007/"
  rewritePrefix = "file:///etc/xml/w3c-entities/" />

</catalog>

If the focheck catalog changed to use systemIdStartString, then you`d still have the possibility of it overriding other catalogs.

Does oXygen provide any other catalog that resolves htmlmathml-f.ent?

Maybe the answer is for this catalog to use systemIdSuffix="/htmlmathml-f.ent"?

[raducoravu]

But do you use that mapping from anywhere in your schema or Java code?

Right now your catalog is the only one mapping the "htmlmathml-f.ent" in some way. Probably all other places refer to the "htmlmathml-f.ent" as a relative location and expect it to be relative to the DTD which refers to it.
For example the DTD:

OXYGEN_INSTALL_DIR/frameworks/dita/DITA-OT2.x/plugins/org.oasis-open.dita.v1_3/dtd/technicalContent/dtd/mathml/mathml3/mathml3.dtd

has a reference like:

  <!ENTITY % htmlmathmlent PUBLIC "-//W3C//ENTITIES HTML MathML Set//EN//XML" "htmlmathml-f.ent">

which should be resolved relative to the DTD. It is now resolved to your ent file.

[tgraham-antenna]

It's needed because some MathML in fo:instream-foreign-object uses the MathML entities.

It's not referenced by the schema because it's a RELAX NG schema. Individual FO documents would have to have a DOCTYPE declaration declaring it.

focheck needs the catalog for parsing outside of oXygen, but the focheck frameworks could defer to an oXygen-wide catalog if that existed.

Is it possible for the users to set the priority of their framework to 'high'? Would that solve it?

We can talk about this more in Prague.

[raducoravu]

Usually XSL-FO is automatically generated using XSLT so all entities have already been expanded by the XSLT processor. So I think cases in which XSL-FO has a DOCTYPE, declares and uses entities are quite seldom.
About this remark:

   Is it possible for the users to set the priority of their framework to 'high'? Would that solve it?

It would only solve it if the framework would define its own catalog system mapping, similar to what you did. If it defines no catalog mapping considering the the entity is located in the same folder with the DTD which references it, the entity will always get resolved through your mapping.

I will not be at XML Prague, but about 5 members from our team will.

[tgraham-antenna]

Would the current catalog.xml work better?

[raducoravu]

@tgraham-antenna It's better the catalog mappings are now more precise for a certain system ID. I'm not sure when I'll be able to test the changes so you can probably close the issue.
For the uri value why do you use that strange "file:" notation "file:./htmlmathml-f.ent" instead of "htmlmathml-f.ent"?