help with catalog setup?

[jstanford]

Hi,

I am trying to get a proper catalog set up so I don't have to have my xsd files in my working directory. Here is a sample header from one of my working files:

<executionPlan
xmlns="http://www.xyz.com/schema/SPS"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.xyz.com/schema/SPS plan.xsd
"

So far I have done the following:

created /Applications/oxygen/frameworks/sps/xsd
placed plan.xsd in it
created spscatalog.xml
added <nextcatalog catalog="sps/sxd/spscatalog.xml"/> to /Applications/oxygen/frameworks/catalog.xml

I have tried various things in the spscatalog.xml based on previous postings, but obviously don't know much about them since nothing has worked. I have been restarting oxygen after each modification.

Any help would be greatly appreciated...

Regards,
John

[george]

Hi John,

The steps you took look ok to me, (alhough you could very well add your catalog through the preferences instead of modifying the default catalog) so I guess the problem is in the part that you did not show us, that is in the catalog file content.
Make sure you are using the system mapping and not the uri mapping. The catalog is the configuration for a resolver and eveything that is related with XML parsing is in an EnityRever created from the catalog files and it takes the system and pubic mappings. The uri mappings are used for an UriResolver that is used for XSLT transformations.

Best Regards,
George

[jstanford]

Hi George,

Here is an entry from my catalog.

<?xml version="1.0" encoding="UTF-8"?>

<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer='public'>
<rewriteSystem
systemIdStartString="plan.xsd"
rewritePrefix="file:///Applications/oxygen/frameworks/sps/xsd/plan.xsd
"/>

Thanks,

John

[george]

Hi John,

Sorry, I should have noticed from your initial post that you are using a relative location to specify the schema. That is resolved to an absolute location before it reaches the catalog resolver so your catalog entry will not match that. You should use an absolute location to specify your schema in the document, something like http://www.xyz.com/schema/SPS/plan.xsd and eventually have the schema at that location then map that to a local copy in the catalog.

Best Regards,
George

[jstanford]

Hi George,

Thanks for the response. Unfortunately, I am just working with a vendor application, and don't know much about XML. Can you give me an example of what you mean by modifying the schemalocation and catalog entry that I posted?

Thanks,
John

[george]

Hi John,

In the instance document you should have

<executionPlan
xmlns="http://www.xyz.com/schema/SPS"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.xyz.com/schema/SPS http://www.xyz.com/schema/SPS/plan.xsd"
...

and in the catalog file

<system systemId="http://www.xyz.com/schema/SPS/plan.xsd" uri="plan.xsd"/>


Best Regards,
George

[jmeyer]

Hi George,

I am having the same problem as John Stanford.

This seems like a bug to me.

The schemaLocation entry of:

xsi:schemaLocation="
http://www.xyz.com/schema/SPS plan.xsd
...

still points to a systemId for plan.xsd and therefore should be able to be resolved as a systemId. So the following entry in the catalog should work.

<system systemId="plan.xsd" uri="file://Applications/oxygen/frameworks/sps/xsd/plan.xsd"/>

Yet this does not work.

While I do have it working if I change the systemId on the schemaLocation, this is not how the files are being delivered. Also it does not seem to be an efficient use of the catalog.

Thanks for the previous posts - they have help clearify my conclusions.

John Meyer

[george]

Hi John,

The catalog acts as an entity resolver so it gets the fully expanded location of the schema (although you write it as a relative location in the XML file). Then the catalog does not have a way to say anything that ends in this should be resolved to that. If you still want to use such instance documents then you have two options:
1. Place the schema in the same folder as the instance file so that the application will find it.
2. Add in the catalog mappings from all the possible expanded locations of the schema to the actual location.

Best Regards,
George

[jmeyer]

George,

Thanks,

It seems to me that in the future there are two possible ways to go about this (Enhancements to XML catalogs).

First would be to add a different attribute to rewriteSystem that is called systemIdEndString - which would test the end of the systemId instead of the start.

The second way would be to treat the namespace portion of schemaLocation as a public identifier. And therefore allow resolution based on a public entry if exists.

I know this is outside your scope of help and support - just thoughts.

Thanks again,
John

[george]

Hi John,

The second part is possible with a small change: it should use the uri mappings not the public ones. However in order to implement that one has to use Xerces specific code to set an XMLEntityResolver (which works at XNI level - Xerces Native Interface). This resolver receives an XMLResourceIdentifier object that has a namespace property and the resolver can use that to try to get the actual resource.
We have on our bugzilla an entry to add this kind of support.

Best Regards,
George