You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Evyatar Kafkafi <Ev...@orsus.com> on 2002/10/31 14:24:30 UTC

problem: xsd schemas that are included or imported must be files !

Hi all,
 
My problem might be a feature of Xerces, or a feature of XML schema - I am not sure.
In any case, I think this feature is wrong.
 
In a schema like this:
 
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="  <http://schemas.devxpert.com/order> http://schemas.devxpert.com/order" 
                    xmlns:xsd="  <http://www.w3.org/2001/XMLSchema> http://www.w3.org/2001/XMLSchema" 
                    xmlns:my="my_imported_namespace" 
                    xmlns:dx="  <http://schemas.devxpert.com/order> http://schemas.devxpert.com/order" 
                    elementFormDefault="qualified">
     <xsd:import namespace="my_imported_namespace" schemaLocation="import.xsd"/>
...
</xsd:schema>
 
When the parser parses the xml:import, it takes the schemaLocation and assumes it is a file on the file system !
 
Now this approach is quite reasonable when you work with small systems, but not on large scale.
In the system I'm currently developing, we don't keep the schemas in file system at all !
We keep XML schemas in the Database. There are many good reasons for this.
 
When we use a parser to parse an XML instance and validate it with a schema, we take the schema (and all its imported and included xsd files) directly from the Database. We don't want to write them to the file system and then tell the parser where they are located on the disk.
Xerces supports this behavior by using the InputSource class, which allows the input to come from a string, not from a file.
In addition, Xerces has the Entity Resolver, which allows me to supply the parser an Input Source for the entity "import.xsd".
 
But before calling my custom made entity resolver, Xerces tries to expand the value "import.xsd" to a meaningfull URI, and its last resort is to assume it's in the "user.dir" directory [System.getProperty("user.dir")].
 
So you see, Xerces assumes that "import.xsd" is a file. Why is that? Is it Xerces, or is it defined by the XML Schema Recomendation?
And in any case, could it be changed?
Isn't it much more general (and thus elegant) to allow for entities to come not only from file system?
 
    Evyatar.
 

Re: problem: xsd schemas that are included or imported must be files !

Posted by Joseph Kesselman <ke...@us.ibm.com>.
>                      xmlns:my="my_imported_namespace" 

WARNING! The W3C has deprecated the use of relative URI references as 
namespace names. Tools are not required to accept the syntax shown here, 
and if they do accept it there is absolutely no promise about whether they 
interpret it as a literal or as relative to some base URI -- or which base 
they reference in the latter case. 

If you want your document to be portable, now or in the future, you should 
replace this with a fully qualified URI.

 ______________________________________
Joe Kesselman  / IBM Research

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org


Re: problem: xsd schemas that are included or imported must be files !

Posted by Milan Trninic <mt...@galdosinc.com>.
I had the same problem.
In the xerces API it says that the parser is required to resolve the id to a
meningful URI before passing it to the application (custom EntityResolver).
I was trying to find a way to intercept that, but due to the lack of time
gave up. I would certinly like to see if there is a way to do it. Otherwise,
the only solution I see is to preparse all the schemas and provide them as
external schemas to the parser.

Milan
  ----- Original Message -----
  From: Evyatar Kafkafi
  To: xerces-j-dev@xml.apache.org ; xerces-j-user@xml.apache.org
  Sent: Thursday, October 31, 2002 5:24 AM
  Subject: problem: xsd schemas that are included or imported must be files
!


  Hi all,

  My problem might be a feature of Xerces, or a feature of XML schema - I am
not sure.
  In any case, I think this feature is wrong.

  In a schema like this:

  <?xml version="1.0" encoding="UTF-8"?>
  <xsd:schema targetNamespace="http://schemas.devxpert.com/order"
                      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                      xmlns:my="my_imported_namespace"
                      xmlns:dx="http://schemas.devxpert.com/order"
                      elementFormDefault="qualified">
       <xsd:import namespace="my_imported_namespace"
schemaLocation="import.xsd"/>
  ...
  </xsd:schema>

  When the parser parses the xml:import, it takes the schemaLocation and
assumes it is a file on the file system !

  Now this approach is quite reasonable when you work with small systems,
but not on large scale.
  In the system I'm currently developing, we don't keep the schemas in file
system at all !
  We keep XML schemas in the Database. There are many good reasons for this.

  When we use a parser to parse an XML instance and validate it with a
schema, we take the schema (and all its imported and included xsd files)
directly from the Database. We don't want to write them to the file system
and then tell the parser where they are located on the disk.
  Xerces supports this behavior by using the InputSource class, which allows
the input to come from a string, not from a file.
  In addition, Xerces has the Entity Resolver, which allows me to supply the
parser an Input Source for the entity "import.xsd".

  But before calling my custom made entity resolver, Xerces tries to expand
the value "import.xsd" to a meaningfull URI, and its last resort is to
assume it's in the "user.dir" directory [System.getProperty("user.dir")].

  So you see, Xerces assumes that "import.xsd" is a file. Why is that? Is it
Xerces, or is it defined by the XML Schema Recomendation?
  And in any case, could it be changed?
  Isn't it much more general (and thus elegant) to allow for entities to
come not only from file system?

      Evyatar.