Loading an AbtXmlSchema witth includes from current directory

[jtu...@objektfabrik.de]

Hi,

I am having trouble loading a Schema (provided form a third party) that uses includes that refer to the current directory like this:

<xs:include schemaLocation="./includedSchema.xsd">

The import of the included schema doesn't work on Windows. I get SGML exceptions because schema information is missing.

If I change the schema to this:

<xs:include schemaLocation="includedSchema.xsd">

All is fine. I haven't tested this on Linux yet, so I cannot tell if this is a slash vs. backslash issue.
But no matter if it is, my understanding is that in XML land a path like './includedSchema.xsd' is correct. I see that in many schemas I come across.
So VAST should treat the slashes correctly.

Or am I missing some setting that has to be made before parsing a Schema file?

Joachim

[jtu...@objektfabrik.de]

HI again,

the same seems to be true for
<xs:import namespace="" schemaLocation="./includedSchema.xsd"/>

... and what makes me a bit surprised: shouldn't I get an exception if imports cannot be imported? Or is this again a setting that I can change if I want exceptions?

Joachim

[Marten Feldtmann]

I thought, that this is controlled via

[Xml]
; This stanza is only needed at runtime if your runtime app used XML.
DefaultResourceQualifier=C:\Program Files\Instantiations\VA
Smalltalk\8.5\xml\


in your ini file ?


Marten

[jtu...@objektfabrik.de]

Hi Marten,

maybe it is, I haven't tried...

But this would somehow be strange for two reasons:
1) I'd have to put all my schema files into one directory, no matter if they are shipped with VAST or are needed by my application code - I'd like to avoid that for several reasons (version control for xml files on a project being one of them - VAST and business schemata have their own lifecycles)
2) It is perfectly okay in XML schemata to include files from a path named './', so VASTs implementation would show some strange difference here.

Joachim

[Thomas Koschate]

On Wednesday, August 15, 2012 9:05:04 AM UTC-4, jtu...@objektfabrik.de wrote:

 

2) It is perfectly okay in XML schemata to include files from a path named './', so VASTs implementation would show some strange difference here.

 
You might want to try full URI names such as file:///... or, serve up the files from a web server and use an http:// style reference for the resource files.

Tom

[jtu...@objektfabrik.de]

Tom,

sure. But this requires me to hand-edit schema files that I get from other projects. 

They assume all their schemas are in the same directory and in order to allow easy deployment for all parties involved, this sounds like a valid assumption for me. It seems other projects using other languages have no issues with this approach. So this is either a cry for help or a feature request, depending on whether I can customize the behaviour of VASTs XML parsers to handle such relative paths the way they are meant.

Why on earth is that a problem? It's easy, just remove './' in the files.

It is a problem because by doing so I am producing new artefacts from artefacts I receive from other projects and thus take full responsibility for their correctness and maintenance. The other project will just say: "Hey, that's not the schema we sent you, we cannot help you with your issues if you make changes to a working schema file. go fix them yourself.". I'll get into trouble when somebody forgets to make this change in the next version of the schemas. The exceptions thrown are correct, but not that easy to understand, especially not friday night at 9pm when go-live is Saturday morning ;-)

Joachim

[dfe]

Hi Joachim,

In case you haven't found an acceptable solution to your problem with the existing schema import/include mechanism not recognizing the current directory as "./"  when importing a schema, I thought I would suggest an approach.

The class involved in locating imported schemas (and other file resources) is AbtXmlFileReader.   Look at the method canReadResource:   on the instance side.

I would recommend either working with this class or subclassing it or AbtXmlResourceReader itself to create a class which understands how to locate and open a file referred to by "./" 

Diane