Page 1 of 1

Use different DITA version

Posted: Fri Mar 18, 2016 7:43 pm
by Denis
Hi,
we are using Eclipse Oxygen Author 17.1.

Is it possible to use the a different version from DITA as you deliver.
We have a case, where we want to use DITA 1.1.
I have tried to put all dita schema files to the same location, where the editing file is located.
But the content completion suggest me to use e.g. a hazardstatement, which is first available in DITA 1.2.

Best regards
Denis

Re: Use different DITA version

Posted: Fri Mar 18, 2016 7:48 pm
by Costin
Hello,

Yes, you can use an external DITA OT.
Starting with the version 17 of oXygen, you can set the location of your custom DITA OT in the oXygen preferences, from the Preferences

More details regarding this are available in the oXygen User-Guide, at:
https://www.oxygenxml.com/doc/versions/ ... ta-ot.html

Regards,
Costin

Re: Use different DITA version

Posted: Tue Mar 22, 2016 12:32 pm
by Denis
Hi Costin,
this is a nice way to refer to another DITA version.
Thanks.

Now I have a further use case, which is not covered with the DITA OT.
What could I do, when I have a customized DITA schema.
I deliver the DTD to the equal location like the editing file.
The validation has to be against the delivered DTD first.
If there is no DTD at this location the DITA OT could be used for validation.

Best regards
Denis

Re: Use different DITA version

Posted: Tue Mar 22, 2016 4:02 pm
by Radu
Hi Denis,

I'm afraid I do not quite understand.
So a DITA topic has a DOCTYPE like this:

Code: Select all

<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
First Oxygen will try to resolve the Public ID "-//OASIS//DTD DITA Topic//EN" to a local DTD using its XML catalog support.
Each document type association in the Preferences Document Type Association page provides a set of catalogs. All these catalogs are gathered together and Oxygen searches in them in the order in which they are contributed by the document type associations.
There is also an XML / XML Catalog page. All catalogs referenced there will be considered high priority and will be used to resolve the public ID first.

If Oxygen does not find a mapping for the public ID, it will try to map the system ID (in our case topic.dtd) through the XML catalogs to a local DTD, using the same approach.

If this also fails, Oxygen will consider the system ID as a local relative reference and try to open it relative to the XML document.

In order to provide your own prioritary XML catalog mappings:

1) You could force set the list of XML catalogs using the API:

Code: Select all

    PluginWorkspaceProvider.getPluginWorkspace().setGlobalObjectProperty("catalogs.v5", new String[]{
"${workspace}/REPOSITORY/system/catalog.xml"
});


If you use a custom editor variable in the URL, you can register a custom editor variables resolver:

Code: Select all


     PluginWorkspaceProvider.getPluginWorkspace().getUtilAccess().addCustomEditorVariablesResolver(new EditorVariablesResolver() {
/**
* @see ro.sync.exml.workspace.api.util.EditorVariablesResolver#resolveEditorVariables(java.lang.String, java.lang.String)
*/
@Override
public String resolveEditorVariables(String contentWithEditorVariables,
String currentEditedFileURL) {
return contentWithEditorVariables.replace("${workspace}", "realLocation");
}
});
You just need to make sure that the final location to which the catalog will be resolved is in URL syntax (like: file:/C:/.../catalog.xml).

2) Or you can use the API:

Code: Select all

 ro.sync.exml.workspace.api.PluginWorkspace.importGlobalOptions(File)
to force import an options XML file in the global options.

3) Or you could set up a custom priority entity resolver which could for example try to delegate to your own custom catalog resolver:

Code: Select all


     PluginWorkspaceProvider.getPluginWorkspace().getXMLUtilAccess().addPriorityEntityResolver(new EntityResolver() {
org.apache.xml.resolver.CatalogManager catalogManager = new CatalogManager();
{
catalogManager.setCatalogFiles("file:/c:/a../catalog.xml");
}
CatalogResolver resolver = new CatalogResolver(catalogManager);
@Override
public InputSource resolveEntity(String publicId, String systemId) throws SAXException,
IOException {
return resolver.resolveEntity(publicId, systemId);
}
});
Regards,
Radu

Re: Use different DITA version

Posted: Tue Mar 22, 2016 6:36 pm
by xephon
Do you deliver your topic and map specializations as a DITA-OT plugin, see Extending the XML catalog?

Code: Select all

<plugin id="com.example.catalog">
<feature extension="dita.specialization.catalog.relative" file="catalog-dita.xml"/>
</plugin>

Re: Use different DITA version

Posted: Wed Mar 23, 2016 6:07 pm
by Denis
Hi,

So, if I do not use a DITA OT.
I have to create a catalog.xml file which contains the public identifiers and refers to the dtd.
Then I can configure in the preferences, the path to the catalog and remove the other ones.
After that the content completion will show me the tags for the dtd, which I have defined in the catalog, only?

Best regards
Denis

Re: Use different DITA version

Posted: Thu Mar 24, 2016 8:52 am
by Radu
Hi Denis,

Whatever XML catalog references you add in the XML / XML Catalog preferences page will take precedence. So no need in removing references to other catalogs provided by the document type associations.

Regards,
Radu