[oXygen-user] Working with Catalogs

[Eliot Kimber]

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


www.innodata-isogen.com