Sorin Ristache wrote:
Hello,
There are only user errors, not limitations in the <oXygen/>'s catalog implementation.
1. First the root element of an OASIS catalog must be in the "urn:oasis:names:tc:entity:xmlns:xml:catalog" namespace, for example:
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"> ... </catalog>
Yes, I have all the correct declarations, I just didn't show them for brevity.
Second you tried to resolve an external identifier with a URI entry of the catalog. You must use an external identifier entry, for example *system*:
<system systemId="http://dita.oasis-open.org/DITA/version.1.0/topic.dtd" uri="topic.dtd"/>
Oops. This was an error on my part.
The catalog works like this: try to resolve the URL via the catalog, *only* upon failure try to resolve the URL by accessing the remote location. So the possible user preference that you specified does not make sense.
I'm not sure I understand your response. I'm saying that *I want it to work the way I said I want it work:* try to resolve via the catalog *first*, then only on failure try to resolve via the net. I want that option and there's no reason not to provide it. There's nothing in the Entity Resolution spec that requires you to try to resolve a system ID via the Net first. From the spec: "This Committee Specification does not dictate when an entity manager should access this catalog; for example, an application may attempt other mapping algorithms before or after accessing this catalog." Therefore, there's every reason to offer users the option of how they want catalogs to be applied when resolving entities and resources.
XML Catalog operations are completely independent of accessing any resource specified by a URL. You can find this explained in the OASIS XML Catalogs specification directly linked from the "Working with XML Catalogs" section of the <oXygen/> User Manual:
I'm not sure what you mean here: the entity resolution spec is quite clear that it can be used for resolving non-entity resources referenced from within a XML document (or in any other processing context for that matter): "A catalog can be used in two different, independent ways: (1) it can be used to locate the replacement text for an external entity, or (2) it can be used to locate an alternate URI reference for a resource." Therefore, it's not unreasonable to expect any parser to use an available catalog to resolve both entity external identifiers and non-entity resource URIs. In fact, one would expect this to always be available for schema locations since without this it would be very hard to migrate from DTDs to schemas in environments where catalogs have been used to manage the local access to DTD components. Again, user options should be provided, i.e. "use catalogs to resolve non-entity URIs?". So, given that, here's where I've gotten after fixing my error identified above: - I can resolve system IDs that map directly to a local file. But what I would like to be able to do and sort of expected to work, is to map through several levels of resolution. In particular, given this DOCTYPE declaration: <!DOCTYPE topic SYSTEM "http://dita.oasis-open.org/DITA/version.1/topic.dtd"> I would like to be able to resolve through this system of catalog entries: <!-- Application-version-dependent, resource version indenpendent URL: --> <system systemId="http://dita.oasis-open.org/DITA/version.1/topic.dtd" uri="http://dita.oasis-open.org/DITA/version.1.0/topic.dtd"/> <!-- Version-specific URL: --> <system systemId="http://dita.oasis-open.org/DITA/version.1.0/topic.dtd" uri="./topic.dtd"/> That is, I was hoping that the entity resolution would work as follows: Step 1: resolve system ID "http://dita.oasis-open.org/DITA/version.1/topic.dtd" to URI "http://dita.oasis-open.org/DITA/version.1.0/topic.dtd" Step 2: try to reslve URI "http://dita.oasis-open.org/DITA/version.1.0/topic.dtd" via catalog, resolve it to URI "./topic.dtd" Step 3: try to reslve URI "./topic.dtd" via catalog. Find no entry, try to resolve it using outside system, find local file topic.dtd. However, it appears that Oxygen's resolver does not try to resolve the URI returned in step 1, causing it to fail the validation with an HttpException. Essentially, in the case where an Oxygen user has requested that all URIs be resolved via the catalogs, it should just automatically be applied recursively because every URI will be passed to a "resolveUri()" method that will try to resolve it first via the catalog, which will have the effect of recursing through all relevant catalog entries until no entry is found for a result URI. Also, it appears that the oXygen resolver is resolving noNamespaceSchemaLocation= values via SYSTEM catalog entries and not URI entries. I don't think this is correct given that noNamespaceSchemaLocation and schemaLocation are not entity references but are references to non-entity resources. They should be resolved via URI entries exclusively. Cheers, Eliot -- W. Eliot Kimber Professional Services Innodata Isogen 9390 Research Blvd, #410 Austin, TX 78759 (512) 372-8841 ekimber@innodata-isogen.com www.innodata-isogen.com