remote imported schema are invalid - download and fix?

[goBoating]

Hello All,

A quick search turned up nothing. I'm a Perl programmer working with XML. I am working on an app that creates a large detailed XML file and I need to generate a second format from that larger/detailed file. We're already using XSLTs to create concise versions of the larger report. So, I'd like to write an XSLT for this new format. I have Altova MapForce and doing the mapping from schema1 to schema2 would be trivial except that the second format/schema relies on some imports of other remote schema that are invalid. MapForce won't/can't open the second schema. XMLSpy reports that a given element in one remote schema is previously defined in another remote schema. This is the first error and there are numerous remote schema that are pulled into the picture. So, I'm expecting to find more.

Two questions, ...I think. First, does it make sense to download all of the remote schemata and change the schemaLocations to the local paths? I'd like to repair the problems so that I can get the second schema to load into MapForce. Both report schema are substantial. Manually mapping the one to the other would be very tedious. I'd really like to use MapForce for this chore.

Second, if the answer to the above is 'yes', then how can I download all of the remote schema? There are imports upon imports upon imports. The pile gets pretty big. Is there a way to tell the Altova tool(s) to pull the entire pile down and use it locally?

Finally, it is expected that those organizations responsible for the invalid remote schema will eventually fix them and once the XSLT is written, we'll revert back to using the remote schemata. And, as is often the case, I can't wait on them. I need to get this stuff pretty well put together and ready for minor tweaks when the remote schemata are fixed.

Thanks for any advice.



'hope this helps

If you are new to Tek-Tips, please use descriptive titles, check the FAQs, and beware the evil typo.

 

[tsuji]

[0] Where are all those mapforce users! When they ask questions, they are mapforce experts or nearly one; when people ask, they disappear?!

[1] Q1:>First, does it make sense to download all of the remote schemata and change the schemaLocations to the local paths?...
A1: Do you have a choice! It seems if you want to do your job asap without waiting for their fix, that is the only option left?!

[2] Q2:>Second, if the answer to the above is 'yes', then how can I download all of the remote schema?
A2: You can use XML::*, one module or another, to load/grab the remote xsd via probably http: protocol to save a local copy. Their xsd's are by themselves well-formed xml document as well.

[2.1] As to the chain download, you can do, but you've to write script all the same. The leading elements to inspect is the chain of xs:import, xs:include in the containing schema and its chained elements, tracing along.

[2.2] If you load them using XML:OM, say, apart from saving a local copy, you parse as well its xs:schema for xsi:schemaLocation or xsi:noNamespaceSchemaLocation and then xs:import and xs:include for their SchemaLocation attributes.

[2.3] Parse their locations and again use XML:OM to load them doing what you do in [2.2].

[2.4] In xs:import, it is optional to have SchemaLocation attribute, in that case, normally those schema you should have already downloaded and parsed in its containing schema components. Hence, it is not a factor to worry about. In xs:include, that attribute is mandatory, hence, it would have no uncertain factor.

[2.5] One other possible outcome is that the top containing schema has no xsi:noNamespaceSchemaLocation or xsi:schemaLocation and that their location is provisioned at application level, that may pose a problem. But as you have control at application level, that should not be a problem. Besides, if you're using mapforce, I think that would not be the case.

[2.6] Hence, the location is somewhat the above, only its realization takes some effort in writing it up. Maybe sometime, do it manually with a browser say visiting the url of the locations one by one would even be simpler!

 

[goBoating]

Tsuji, Thanks for the response. 'Sounds like you confirm my thinking. I've made requests of the owners of the offending schemata to fix them and will wait a day or two. After that, I may have to start pulling down the schema tree. I think a little Perl script may be in order.

Thanks, again.

'hope this helps

If you are new to Tek-Tips, please use descriptive titles, check the FAQs, and beware the evil typo.