|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #57345 Using remote schemas that <import> causes unnecessary warnings
Submitted: 2006-11-06 10:46 UTC Modified: 2007-04-25 19:59 UTC
From: jonathan dot abbett at childrens dot harvard dot edu Assigned: tuscany (profile)
Status: Closed Package: SCA_SDO (PECL)
PHP Version: 5.1.6 OS: Windows XP 5.1.2600
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: jonathan dot abbett at childrens dot harvard dot edu
New email:
PHP Version: OS:


 [2006-11-06 10:46 UTC] jonathan dot abbett at childrens dot harvard dot edu
(Apologies in advance for my inability to elegantly describe this bug.)

I'm using php_sdo.dll version php-5.1.2.

When I attempt to create an SDO_DAS_XML object with a schema that imports other schemas remotely, I get several "failed to load external entity" warnings.  In addition to successfully loading the remote schemas, SDO is attempting to retrieve several malformed URLs of its own creation, which results in a swarm of warning messages.

My main schema:

Reproduce code:

try {
  $xmldas = SDO_DAS_XML::create("");

  try {
    $doc = $xmldas->createDocument('', 'Insurance');
    $rdo = $doc->getRootDataObject();
    $rdo->GroupNumber = "12345";
    $rdo->Comments = "The quick brown fox jumps over the lazy dog.";
  } catch (SDO_Exception $e) {
} catch (SDO_Exception $e) {
	print("Problem creating an XML document: " . $e->getMessage());


Expected result:
<?xml version="1.0" encoding="UTF-8"?>
<Insurance xmlns="" xsi:type="InsuranceType" xmlns:tns="" xmlns:xsi=""><Comments>The quick brown fox jumps over the lazy dog.</Comments><GroupNumber>12345</GroupNumber></Insurance>

In other words, XML with no warnings.

Actual result:
Many of these warning messages...

Warning: SDO_DAS_XML::create( [function.SDO-DAS-XML-create]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in C:\websites\indivotech\sdo.php on line 8

Warning: SDO_DAS_XML::create() [function.SDO-DAS-XML-create]: I/O warning : failed to load external entity "" in C:\websites\indivotech\sdo.php on line 8

...followed by the expected XML output.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-11-06 11:12 UTC]
The import statements in the schema look like: 
<import namespace="" schemaLocation=""/>

As you can see from the error message:
SDO_DAS_XML::create( [function.SDO-DAS-XML-create]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found

we're gluing the namespace to the schema location to locate the imported schema. 

All the examples I can see at W3C work that way, where the schemaLocation part is just a file name: 

Is it possible to update your schema accordingly?
 [2006-11-06 13:53 UTC] jonathan dot abbett at childrens dot harvard dot edu
As I understand it, one should not expect a namespace URI to be related to the physical location of a schema.  With regard to locating schemas on the web, the W3C instructs:

"When a schemaLocation is present, it must contain a single URI reference which the schema author warrants will resolve to a serialization of a ?schema document? containing the component(s) in the <import>ed namespace referred to elsewhere in the containing schema document."

And then:

"The author of a document uses namespace declarations to indicate the intended interpretation of names appearing therein; there may or may not be a schema retrievable via the namespace name. Accordingly whether a processor's default behavior is or is not to attempt such dereferencing, it must always provide for user-directed overriding of that default."

The location strategy they then suggest involves looking in a local repository first, then resolving the schemaLocation URI, and only then trying to resolve the namespace:

Were SDO to follow the W3C Recommendation, it would attempt to retrieve first and it would succeed -- no need to infer anything from the namespace and throw warnings.
 [2006-11-06 13:57 UTC] jonathan dot abbett at childrens dot harvard dot edu
Updating summary to better describe the problem.
 [2006-11-07 12:15 UTC]
Yes, I was not suggesting that your schema is invalid, only that it is unconventional. And I'm not sure that it's fair to imply any ordering from recommendations prefaced by "Given a namespace name (or none) and (optionally) a URI reference from xsi:schemaLocation or xsi:noNamespaceSchemaLocation, schema-aware processors may implement any combination of the following strategies, in any order:"!

FWIW, just to correct what I said earlier, and so that I don't confuse anyone reading this, it is not the namespace that is being used, but the location of the current file, in your case the location of insurance.xsd. The namespace is only used when other mechanisms fail. 

An algorithm which glues together two well-formed URIs and attempts to use the result is clearly broken, and I shall raise this with the Apache Tuscany team, who own the C++ SDO library. I hope they will change this behaviour to eliminate the pointless warnings. I'll keep you posted.
 [2006-11-07 13:31 UTC] jonathan dot abbett at childrens dot harvard dot edu
Good point, I hadn't noticed that "in any order" bit!

I wouldn't go so far as to say our schemata are unconventional.  It's not far-fetched to use full URIs in the schemaLocation field when the schemata are deployed online and used within an Internet-based application.

In any case, it's an unnecessary argument -- raising the issue of bad URIs with the Tuscany team is a good idea, and I look forward to their response.  Thanks for your help!
 [2006-11-27 06:17 UTC]
This Tuscany fix didn't make the 1.1.0 release - I'll keep watching it.
 [2007-04-25 19:59 UTC]
Thank you for your bug report. This issue has been fixed
in the latest released version of the package, which you can download at

Sorry I hadn't updated this sooner, but the problem seems to have gone in recent versions. The schema loads without any warning messages.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Wed Mar 22 04:03:45 2023 UTC