Plugin access to frameworks and catalogs
Hello, We're developing a workspace plugin which reads form either existing editors or on-disk files. We're using all the catalogs in the standard 12.0 release using this rather brute-force approach: <configProperty name="cat_dita" value="${install.dir}/../../../frameworks/dita/catalog.xml" /> <configProperty name="cat_docbook" value="${install.dir}/../../../frameworks/docbook/catalog.xml" /> ... <configProperty name="cat_xmlspec" value="${install.dir}/../../../frameworks/xmlspec/catalog.xml" /> <configProperty name="xml.catalog.files" value="${cat_dita};${cat_docbook};...${cat_xmlspec}" /> However, we dont know about any user defined frameworks. Is there a way of knowing the framework associations of editors/files so that we could use the specific catalog file (also reducing the possibility of conflicts between the catalogs). Alternatively access to a URI/Entity resolver appropriate for the type of file which we could use when parsing (xerces) may be useful. We know about XMLUtilAccess and its resolvePathThroughCatalogs method, but we'd like something we can use with the resolver/xerces directly. We've also seen some references to a 'grammarCache' object but are unsure how to use it. Is there something we can use to improve our catalog handling. Many thanks, Nigel & Anthony (working on a comparison plugin) -- Nigel Whitaker, DeltaXML: "Change control for XML" nigel.whitaker@deltaxml.com http://www.deltaxml.com Registered in England: 02528681 Reg. Office: Monsell House, WR8 0QN, UK
Hi Nigel, Anthony, Oxygen has a single Catalog Resolver and all catalogs are added to it (catalogs from each document type + user defined catalogs + Oxygen default catalog file). So even if a document type contributes only with 2-3 catalogs files, the associated editor will be validated/processed by Oxygen using all catalogs. Indeed conflicts may appear but the user can disable individual document types, thus removing their list of catalogs from the Catalog Resolver. My suggestion for you is to use XMLUtilAccess.resolvePathThroughCatalogs() because besides some very little extra tests that's just what it does, it questions the EntityResolver or the URIResolver (depending on the paramters it receives) to resolve the reference. Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 10/29/2010 5:22 PM, Nigel Whitaker wrote:
Hello,
We're developing a workspace plugin which reads form either existing editors or on-disk files.
We're using all the catalogs in the standard 12.0 release using this rather brute-force approach:
<configProperty name="cat_dita" value="${install.dir}/../../../frameworks/dita/catalog.xml" /> <configProperty name="cat_docbook" value="${install.dir}/../../../frameworks/docbook/catalog.xml" /> ... <configProperty name="cat_xmlspec" value="${install.dir}/../../../frameworks/xmlspec/catalog.xml" />
<configProperty name="xml.catalog.files" value="${cat_dita};${cat_docbook};...${cat_xmlspec}" />
However, we dont know about any user defined frameworks. Is there a way of knowing the framework associations of editors/files so that we could use the specific catalog file (also reducing the possibility of conflicts between the catalogs). Alternatively access to a URI/Entity resolver appropriate for the type of file which we could use when parsing (xerces) may be useful.
We know about XMLUtilAccess and its resolvePathThroughCatalogs method, but we'd like something we can use with the resolver/xerces directly. We've also seen some references to a 'grammarCache' object but are unsure how to use it.
Is there something we can use to improve our catalog handling.
Many thanks,
Nigel& Anthony (working on a comparison plugin)
Hi Radu, Thanks for your quick answer. The catalog behaviour background info was very useful. We're still trying to work out the best way of using it: Radu Coravu wrote: ...
My suggestion for you is to use XMLUtilAccess.resolvePathThroughCatalogs() because besides some very little extra tests that's just what it does, it questions the EntityResolver or the URIResolver (depending on the paramters it receives) to resolve the reference.
If we try to plug resolvePathThroughCatalogs into: InputSource org.xml.sax.EntityResolver.resolve(String publicId, String systemId) and then configure our parser with .setEntityResolver(), then wouldn't we be loosing the ability to do catalog resolving based on the publicId of editors/files? Alternatively, would the XMLUtilAccess.newNonValidatingXMLReader() method return an XMLReader already configured with the resolver and the framework/user/default catalogs you described? Thanks, Nigel -- Nigel Whitaker, DeltaXML: "Change control for XML" nigel.whitaker@deltaxml.com http://www.deltaxml.com Registered in England: 02528681 Reg. Office: Monsell House, WR8 0QN, UK
Ni Nigel, You're right about the first issue, resolvePathThroughCatalogs does not resolve public IDs, so better try the solution suggested below: Indeed, the XMLUtilAccess.newNonValidatingXMLReader() returns an XML Reader which already has an entity resolver set up through the Oxygen catalogs. So as alternatives either you can use our XML Reader to parse resources or create an XML reader through our code and then do a XMLReader.getEntityResolver() on it to access the Entity Resolver set to it on our side. I will add as a feature request the possibility to get an EntityResolver or an URIResolver through our API. Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 10/29/2010 6:32 PM, Nigel Whitaker wrote:
Hi Radu,
Thanks for your quick answer. The catalog behaviour background info was very useful. We're still trying to work out the best way of using it:
Radu Coravu wrote: ...
My suggestion for you is to use XMLUtilAccess.resolvePathThroughCatalogs() because besides some very little extra tests that's just what it does, it questions the EntityResolver or the URIResolver (depending on the paramters it receives) to resolve the reference.
If we try to plug resolvePathThroughCatalogs into: InputSource org.xml.sax.EntityResolver.resolve(String publicId, String systemId) and then configure our parser with .setEntityResolver(), then wouldn't we be loosing the ability to do catalog resolving based on the publicId of editors/files?
Alternatively, would the XMLUtilAccess.newNonValidatingXMLReader() method return an XMLReader already configured with the resolver and the framework/user/default catalogs you described?
Thanks,
Nigel
participants (2)
-
Nigel Whitaker -
Radu Coravu