|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #57484 Incorrect namespaces in generated XML
Submitted: 2007-01-18 08:46 UTC Modified: 2007-07-09 12:43 UTC
From: Assigned: tuscany 1112 (profile)
Status: Closed Package: SCA_SDO (PECL)
PHP Version: 5.1.6 OS: WinXP
Private report: No CVE-ID: None
 [2007-01-18 08:46 UTC]
I have been quite sceptical about the XML that SDO is producing when it builds a SOAP request, especially w.r.t. the namespaces. So I tried loading the XML that SDO is producing into Java XERCES with validation on. There are several problems with the XML generated, I think.

Using the two xsds that are in the reproduce section below, and the short PHP script also there, SDO generates:

<?xml version="1.0" encoding="UTF-8"?>
<BOGUS xmlns="http://Component" xmlns:tns="http://Component" xmlns:tns2="" xmlns:xsi="" xsi:type="add">

There are three (!) things wrong with this.
1. XERCES will not accept the xsi:type="add". I do not really know why. I assume this is because there is no type called "add", it's only an element. So I do not think this should be coming out. 

2. name should not be in tns2=, neither should "first" and "last" be in the default namespace of http://Component. The person.xsd has no elementFormDefault, so the elements below <person> should all ne in the no name namespace. 

3.You have to change the person.xsd to see the third thing: put ElementNameDefault="qualified" in
the person schema, then "name", "first" and "last" should all now be coming out in the namespace, but it makes no difference to the generated XML. 

Reproduce code:
$xmldas = SDO_DAS_XML::create('types.xsd');
$person = $xmldas->createDataObject('','personType');
$name = $person->createDataObject('name');
$name->first = "Will";
$name->last  = "Shakespeare";
$add = $xmldas->createDataObject('http://Component','add');
$add->person = $person;
$xdoc   = $xmldas->createDocument('', 'BOGUS', $add);
$xmlstr = $xmldas->saveString($xdoc, 2);
echo $xmlstr;

    <xs:schema xmlns:xs="" 
      <xs:import schemaLocation="person.xsd" namespace=""/>
      <xs:element name="add">
            <xs:element name="person" type="ns0:personType" nillable="true"/>

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="" 
    <complexType name="nameType">
			<element name="first" type="string"></element>
			<element name="last" type="string"></element>
	<complexType name="personType">
			<element name="name" type="info:nameType"></element>

Expected result:
see above

Actual result:
see above


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2007-01-31 07:21 UTC]
I just came across what I think is another example of this. Now I understand better how namespaces work, I suspect it is more common than we realise. 

Here's the example in a nutshell:

Catalog.xsd defines a catalog element in the catalogNS namespace, which contains items defined in a different namespace in a different file, Order.xsd:

<schema xmlns=""
 xmlns:cat="catalogNS" xmlns:ord="orderNS" targetNamespace="catalogNS">
  <include schemaLocation="Order.xsd"/>
  <element name="catalog" type="cat:CatalogType"/>
  <complexType name="CatalogType">
      <element maxOccurs="unbounded" ref="ord:item"/>

Order.xsd defines the item element as being in the "OrderNS" namespace:
<schema xmlns=""
xmlns:ord="orderNS" xmlns:cust="customerNS" targetNamespace="orderNS">
  <element name="item">

but when you build a catalog and write it out, although a namespace prefix is defined for "orderNS", everything is in the default namespace, "catalogNS":

<catalog xmlns="catalogNS" xmlns:tns="catalogNS" xmlns:xsi="" xmlns:tns2="orderNS">
 [2007-04-24 11:11 UTC]
Although there are several problems reported here, I think this is partly covered by

In that JIRA, the problem of something being in the default namespace when it should be in its own is raised. I think it best to wait for a resolution to that and see if any part of this defect still stands.
 [2007-04-24 13:09 UTC]
My mistake, Tuscany 962 is fixed and not quite the same as it affects open types. I have raised JIRA 1231 instead
 [2007-05-09 05:36 UTC] phpsoa at gmail dot com
just testing to see to where this comment gets emailed - please ignore
 [2007-05-23 12:23 UTC]
After raising Tuscany JIRA 1231 I found Tuscany JIRA 1112 which I had raised earlier. 1112 is the JIRA that covers this. It has been open for three months though.
 [2007-06-29 09:07 UTC]
We have just had some exchanges on Tuscany JIRA 1112. The saga continues.
 [2007-07-09 12:43 UTC]
Fixed at last
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Sun Mar 26 03:03:47 2023 UTC