You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Matthew Peters (JIRA)" <tu...@ws.apache.org> on 2007/02/14 15:58:05 UTC

[jira] Created: (TUSCANY-1112) Incorrect namespaces in generated XML

Incorrect namespaces in generated XML
-------------------------------------

                 Key: TUSCANY-1112
                 URL: https://issues.apache.org/jira/browse/TUSCANY-1112
             Project: Tuscany
          Issue Type: Bug
          Components: C++ DAS
    Affects Versions: Cpp-current
         Environment: WinXP
            Reporter: Matthew Peters


Please excuse the fact that I have only a PHP testcase for this. The PHP is however pretty trivial and it seems a simple thing to make in C. Also, I know that the PHP layer is doing very little to interfere, so this is genuine Tuscany behaviour.

Here is the bug report from the PHP bug tracking system:

Description:
------------
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="http://www.test.com/info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="add">
  <person>
    <tns2:name>
      <first>Will</first>
      <last>Shakespeare</last>
    </tns2:name>
  </person>
</BOGUS>

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=http://www.test.com/info, 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 http://www.test.com/info namespace, but it makes no
difference to the generated XML. 

Reproduce code:
---------------
<?php
$xmldas = SDO_DAS_XML::create('types.xsd');
$person =
$xmldas->createDataObject('http://www.test.com/info','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;
?>

types.xsd:
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
      xmlns:ns0="http://www.test.com/info"
      targetNamespace="http://Component"
      elementNameDefault="qualified">
      <xs:import schemaLocation="person.xsd"
namespace="http://www.test.com/info"/>
      <xs:element name="add">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="person" type="ns0:personType"
nillable="true"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
    </xs:schema>

person.xsd:
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" 
    targetNamespace="http://www.test.com/info" 
    xmlns:info="http://www.test.com/info">
    <complexType name="nameType">
		<sequence>
			<element name="first" type="string"></element>
			<element name="last" type="string"></element>
		</sequence>
	</complexType>
	<complexType name="personType">
		<sequence>
			<element name="name" type="info:nameType"></element>
		</sequence>
	</complexType>	
</schema>

Expected result:
----------------
see above

Actual result:
--------------
see above

[2007-01-31 12:21 UTC] mfp at php dot net

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="http://www.w3.org/2001/XMLSchema"
 xmlns:cat="catalogNS" xmlns:ord="orderNS" targetNamespace="catalogNS">
  <include schemaLocation="Order.xsd"/>
  <element name="catalog" type="cat:CatalogType"/>
  <complexType name="CatalogType">
    <sequence>
      <element maxOccurs="unbounded" ref="ord:item"/>
    </sequence>
  </complexType>       
</schema>

Order.xsd defines the item element as being in the "OrderNS" namespace:
.../...
<schema xmlns="http://www.w3.org/2001/XMLSchema"
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="http://www.w3.org/2001/XMLSchema-instance"
xmlns:tns2="orderNS">
  <item>
.../...



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1112) Incorrect namespaces in generated XML

Posted by "Matthew Peters (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510712 ] 

Matthew Peters commented on TUSCANY-1112:
-----------------------------------------

I have just tested with the latest code - revision 553836 from branch sdo-cpp-pre2.1. 

The output is now:

<?xml version="1.0" encoding="UTF-8"?>
<add xmlns="http://Component" xmlns:tns="http://Component" xmlns:tns2="http://www.test.com/info" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <person>
    <name>
      <first>Will</first>
      <last>Shakespeare</last>
    </name>
  </person>
</add>

This is progress, but still not right yet.

The good thing is that the namespace prefixes are gone for <name>, <first> and <last>. However, because of the default namespace definition in the <add element, these are all effectively in the namespace http://Component, which is not right. They should be in no namespace. 

I don't think you can achieve the right result with a default namespace on the top level element, so I suggest you need the <add element to start like this:

<tns:add xmlns:tns="http://Component"

and not to use a default namespace at all. 

> Incorrect namespaces in generated XML
> -------------------------------------
>
>                 Key: TUSCANY-1112
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1112
>             Project: Tuscany
>          Issue Type: Bug
>          Components: C++ SDO
>    Affects Versions: Cpp-Next
>         Environment: WinXP
>            Reporter: Matthew Peters
>             Fix For: Cpp-Next
>
>
> Please excuse the fact that I have only a PHP testcase for this. The PHP is however pretty trivial and it seems a simple thing to make in C. Also, I know that the PHP layer is doing very little to interfere, so this is genuine Tuscany behaviour.
> Here is the bug report from the PHP bug tracking system:
> Description:
> ------------
> 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="http://www.test.com/info"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="add">
>   <person>
>     <tns2:name>
>       <first>Will</first>
>       <last>Shakespeare</last>
>     </tns2:name>
>   </person>
> </BOGUS>
> 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=http://www.test.com/info, 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 http://www.test.com/info namespace, but it makes no
> difference to the generated XML. 
> Reproduce code:
> ---------------
> <?php
> $xmldas = SDO_DAS_XML::create('types.xsd');
> $person =
> $xmldas->createDataObject('http://www.test.com/info','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;
> ?>
> types.xsd:
>     <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
>       xmlns:ns0="http://www.test.com/info"
>       targetNamespace="http://Component"
>       elementNameDefault="qualified">
>       <xs:import schemaLocation="person.xsd"
> namespace="http://www.test.com/info"/>
>       <xs:element name="add">
>         <xs:complexType>
>           <xs:sequence>
>             <xs:element name="person" type="ns0:personType"
> nillable="true"/>
>           </xs:sequence>
>         </xs:complexType>
>       </xs:element>
>     </xs:schema>
> person.xsd:
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema" 
>     targetNamespace="http://www.test.com/info" 
>     xmlns:info="http://www.test.com/info">
>     <complexType name="nameType">
> 		<sequence>
> 			<element name="first" type="string"></element>
> 			<element name="last" type="string"></element>
> 		</sequence>
> 	</complexType>
> 	<complexType name="personType">
> 		<sequence>
> 			<element name="name" type="info:nameType"></element>
> 		</sequence>
> 	</complexType>	
> </schema>
> Expected result:
> ----------------
> see above
> Actual result:
> --------------
> see above
> [2007-01-31 12:21 UTC] mfp at php dot net
> 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="http://www.w3.org/2001/XMLSchema"
>  xmlns:cat="catalogNS" xmlns:ord="orderNS" targetNamespace="catalogNS">
>   <include schemaLocation="Order.xsd"/>
>   <element name="catalog" type="cat:CatalogType"/>
>   <complexType name="CatalogType">
>     <sequence>
>       <element maxOccurs="unbounded" ref="ord:item"/>
>     </sequence>
>   </complexType>       
> </schema>
> Order.xsd defines the item element as being in the "OrderNS" namespace:
> .../...
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> 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="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:tns2="orderNS">
>   <item>
> .../...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1112) Incorrect namespaces in generated XML

Posted by "Matthew Peters (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498284 ] 

Matthew Peters commented on TUSCANY-1112:
-----------------------------------------

Is there anything happening to this defect, which is several months old by now?

> Incorrect namespaces in generated XML
> -------------------------------------
>
>                 Key: TUSCANY-1112
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1112
>             Project: Tuscany
>          Issue Type: Bug
>          Components: C++ SDO
>    Affects Versions: Cpp-current
>         Environment: WinXP
>            Reporter: Matthew Peters
>             Fix For: Cpp-current
>
>
> Please excuse the fact that I have only a PHP testcase for this. The PHP is however pretty trivial and it seems a simple thing to make in C. Also, I know that the PHP layer is doing very little to interfere, so this is genuine Tuscany behaviour.
> Here is the bug report from the PHP bug tracking system:
> Description:
> ------------
> 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="http://www.test.com/info"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="add">
>   <person>
>     <tns2:name>
>       <first>Will</first>
>       <last>Shakespeare</last>
>     </tns2:name>
>   </person>
> </BOGUS>
> 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=http://www.test.com/info, 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 http://www.test.com/info namespace, but it makes no
> difference to the generated XML. 
> Reproduce code:
> ---------------
> <?php
> $xmldas = SDO_DAS_XML::create('types.xsd');
> $person =
> $xmldas->createDataObject('http://www.test.com/info','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;
> ?>
> types.xsd:
>     <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
>       xmlns:ns0="http://www.test.com/info"
>       targetNamespace="http://Component"
>       elementNameDefault="qualified">
>       <xs:import schemaLocation="person.xsd"
> namespace="http://www.test.com/info"/>
>       <xs:element name="add">
>         <xs:complexType>
>           <xs:sequence>
>             <xs:element name="person" type="ns0:personType"
> nillable="true"/>
>           </xs:sequence>
>         </xs:complexType>
>       </xs:element>
>     </xs:schema>
> person.xsd:
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema" 
>     targetNamespace="http://www.test.com/info" 
>     xmlns:info="http://www.test.com/info">
>     <complexType name="nameType">
> 		<sequence>
> 			<element name="first" type="string"></element>
> 			<element name="last" type="string"></element>
> 		</sequence>
> 	</complexType>
> 	<complexType name="personType">
> 		<sequence>
> 			<element name="name" type="info:nameType"></element>
> 		</sequence>
> 	</complexType>	
> </schema>
> Expected result:
> ----------------
> see above
> Actual result:
> --------------
> see above
> [2007-01-31 12:21 UTC] mfp at php dot net
> 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="http://www.w3.org/2001/XMLSchema"
>  xmlns:cat="catalogNS" xmlns:ord="orderNS" targetNamespace="catalogNS">
>   <include schemaLocation="Order.xsd"/>
>   <element name="catalog" type="cat:CatalogType"/>
>   <complexType name="CatalogType">
>     <sequence>
>       <element maxOccurs="unbounded" ref="ord:item"/>
>     </sequence>
>   </complexType>       
> </schema>
> Order.xsd defines the item element as being in the "OrderNS" namespace:
> .../...
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> 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="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:tns2="orderNS">
>   <item>
> .../...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1112) Incorrect namespaces in generated XML

Posted by "Matthew Peters (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511154 ] 

Matthew Peters commented on TUSCANY-1112:
-----------------------------------------

I just checked out the most recent code from the branch, including 553980 and it this is working fine now. 

The output is 
<?xml version="1.0" encoding="UTF-8"?>
<tns:add xmlns:tns="http://Component" xmlns:tns2="http://www.test.com/info" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <person>
    <name>
      <first>Will</first>
      <last>Shakespeare</last>
    </name>
  </person>
</tns:add>

which is completely correct and does validate with XERCES

> Incorrect namespaces in generated XML
> -------------------------------------
>
>                 Key: TUSCANY-1112
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1112
>             Project: Tuscany
>          Issue Type: Bug
>          Components: C++ SDO
>    Affects Versions: Cpp-Next
>         Environment: WinXP
>            Reporter: Matthew Peters
>             Fix For: Cpp-Next
>
>
> Please excuse the fact that I have only a PHP testcase for this. The PHP is however pretty trivial and it seems a simple thing to make in C. Also, I know that the PHP layer is doing very little to interfere, so this is genuine Tuscany behaviour.
> Here is the bug report from the PHP bug tracking system:
> Description:
> ------------
> 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="http://www.test.com/info"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="add">
>   <person>
>     <tns2:name>
>       <first>Will</first>
>       <last>Shakespeare</last>
>     </tns2:name>
>   </person>
> </BOGUS>
> 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=http://www.test.com/info, 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 http://www.test.com/info namespace, but it makes no
> difference to the generated XML. 
> Reproduce code:
> ---------------
> <?php
> $xmldas = SDO_DAS_XML::create('types.xsd');
> $person =
> $xmldas->createDataObject('http://www.test.com/info','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;
> ?>
> types.xsd:
>     <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
>       xmlns:ns0="http://www.test.com/info"
>       targetNamespace="http://Component"
>       elementNameDefault="qualified">
>       <xs:import schemaLocation="person.xsd"
> namespace="http://www.test.com/info"/>
>       <xs:element name="add">
>         <xs:complexType>
>           <xs:sequence>
>             <xs:element name="person" type="ns0:personType"
> nillable="true"/>
>           </xs:sequence>
>         </xs:complexType>
>       </xs:element>
>     </xs:schema>
> person.xsd:
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema" 
>     targetNamespace="http://www.test.com/info" 
>     xmlns:info="http://www.test.com/info">
>     <complexType name="nameType">
> 		<sequence>
> 			<element name="first" type="string"></element>
> 			<element name="last" type="string"></element>
> 		</sequence>
> 	</complexType>
> 	<complexType name="personType">
> 		<sequence>
> 			<element name="name" type="info:nameType"></element>
> 		</sequence>
> 	</complexType>	
> </schema>
> Expected result:
> ----------------
> see above
> Actual result:
> --------------
> see above
> [2007-01-31 12:21 UTC] mfp at php dot net
> 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="http://www.w3.org/2001/XMLSchema"
>  xmlns:cat="catalogNS" xmlns:ord="orderNS" targetNamespace="catalogNS">
>   <include schemaLocation="Order.xsd"/>
>   <element name="catalog" type="cat:CatalogType"/>
>   <complexType name="CatalogType">
>     <sequence>
>       <element maxOccurs="unbounded" ref="ord:item"/>
>     </sequence>
>   </complexType>       
> </schema>
> Order.xsd defines the item element as being in the "OrderNS" namespace:
> .../...
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> 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="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:tns2="orderNS">
>   <item>
> .../...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1112) Incorrect namespaces in generated XML

Posted by "Pete Robbins (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510653 ] 

Pete Robbins commented on TUSCANY-1112:
---------------------------------------

I've fixed this (I hope) in the branch. Please let me know if this works for you. I will then apply the fix in HEAD

> Incorrect namespaces in generated XML
> -------------------------------------
>
>                 Key: TUSCANY-1112
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1112
>             Project: Tuscany
>          Issue Type: Bug
>          Components: C++ SDO
>    Affects Versions: Cpp-Next
>         Environment: WinXP
>            Reporter: Matthew Peters
>             Fix For: Cpp-Next
>
>
> Please excuse the fact that I have only a PHP testcase for this. The PHP is however pretty trivial and it seems a simple thing to make in C. Also, I know that the PHP layer is doing very little to interfere, so this is genuine Tuscany behaviour.
> Here is the bug report from the PHP bug tracking system:
> Description:
> ------------
> 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="http://www.test.com/info"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="add">
>   <person>
>     <tns2:name>
>       <first>Will</first>
>       <last>Shakespeare</last>
>     </tns2:name>
>   </person>
> </BOGUS>
> 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=http://www.test.com/info, 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 http://www.test.com/info namespace, but it makes no
> difference to the generated XML. 
> Reproduce code:
> ---------------
> <?php
> $xmldas = SDO_DAS_XML::create('types.xsd');
> $person =
> $xmldas->createDataObject('http://www.test.com/info','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;
> ?>
> types.xsd:
>     <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
>       xmlns:ns0="http://www.test.com/info"
>       targetNamespace="http://Component"
>       elementNameDefault="qualified">
>       <xs:import schemaLocation="person.xsd"
> namespace="http://www.test.com/info"/>
>       <xs:element name="add">
>         <xs:complexType>
>           <xs:sequence>
>             <xs:element name="person" type="ns0:personType"
> nillable="true"/>
>           </xs:sequence>
>         </xs:complexType>
>       </xs:element>
>     </xs:schema>
> person.xsd:
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema" 
>     targetNamespace="http://www.test.com/info" 
>     xmlns:info="http://www.test.com/info">
>     <complexType name="nameType">
> 		<sequence>
> 			<element name="first" type="string"></element>
> 			<element name="last" type="string"></element>
> 		</sequence>
> 	</complexType>
> 	<complexType name="personType">
> 		<sequence>
> 			<element name="name" type="info:nameType"></element>
> 		</sequence>
> 	</complexType>	
> </schema>
> Expected result:
> ----------------
> see above
> Actual result:
> --------------
> see above
> [2007-01-31 12:21 UTC] mfp at php dot net
> 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="http://www.w3.org/2001/XMLSchema"
>  xmlns:cat="catalogNS" xmlns:ord="orderNS" targetNamespace="catalogNS">
>   <include schemaLocation="Order.xsd"/>
>   <element name="catalog" type="cat:CatalogType"/>
>   <complexType name="CatalogType">
>     <sequence>
>       <element maxOccurs="unbounded" ref="ord:item"/>
>     </sequence>
>   </complexType>       
> </schema>
> Order.xsd defines the item element as being in the "OrderNS" namespace:
> .../...
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> 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="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:tns2="orderNS">
>   <item>
> .../...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1112) Incorrect namespaces in generated XML

Posted by "Matthew Peters (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509084 ] 

Matthew Peters commented on TUSCANY-1112:
-----------------------------------------

I will continue with your convention of answering inline with some inlines of my own.

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.
<PGR> The xsi:type is valid and is written because you are writing the root as an unknown element: "BOGUS". If you
saved this with the correct root element name, "add"m, then the xsi:type would not be needed and would be supressed </PGR>
<MP> Fair enough. I quite accept that we are generating XML that could not validate against any xsd so in some sense all bets are off. We will deal with the xsi:type attributes ourselves. Consider that one closed. </MP>

2. name should not be in tns2=http://www.test.com/info, 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.

<PGR> From the schema name SHOULD be in tns2 and is written correctly. "first" and "last" should also be in tns2. This is a bug in writing primitive elements and I will check in a fix.
elementFormDefault=unqualified means that a prefix is not REQUIRED not that it can not be written </PGR>


<MP> 
First of all, I made a mistake when I submitted the original jira - I cut and pasted a nasty wrong bit of XML when I included    elementNameDefault="qualified" It's because I was messing about with different values afterwards, when I was writing the jira. Not only is it the wrong thing - I meant elementFormDefault, but in the example I had been running, I didn't have it specified, so it should take its default value of "unqualified". So I hope that has not contributed to any misunderstanding.

I am going to carry on as if that had not happened, though, because that typo was in the types.xsd, and I think that the discussion is really about the person.xsd. Here goes:

How do you arrive at the conclusion that name should be in tns2? With a careful reading of pp 158 and 159 of the O'Reilly XML Schema book plus XERCES to test my understanding, I have reached the opposite conclusion. I'll just cut out a few quotes from there, in the order that tells the story as I see it:
1. the default value for elementFormDefault is "unqualified" ... "appropriate to the case in which only the document element uses a namespace"
2. "global elements and attributes must be qualified" ... but ...
3. "...elements and attributes that don't belong to any namespace "called unqualified"

Your understanding of elementFormDefault=unqualified as meaning that a prefix can be written if you want to, but you do not have to, is not what I think it means. 

As I say, I have worked through all these combinations using XERCES to tell me when there are validation errors, and what you have put as the fix below will not validate. Here is what I had to do make it validate, against the xsds above (but just to be clear, no rubbishy elementNameDefault and let both xsds use the default value for elementFormDefault of unqualified...)

First I change the BOGUS to add. The I find that putting a default namespace of http://Component has put person in the wrong namespace. so let's make the namespace explicit:

<tns:add xmlns:tns="http://Component" xmlns:tns2="http://www.test.com/info">
  <person>
    <tns2:name>
      <tns2:first>Will</tns2:first>
      <tns2:last>Shakespeare</tns2:last>
    </tns2:name>
  </person>
</tns:add>

Now I get "Invalid content was found starting with element 'tns2:name'. One of '{"":name}' is expected."

This is because <name> is not in any namespace, for the reasons discussed above. The tns2 prefix must be removed. I do this and try again with 
<tns:add xmlns:tns="http://Component" xmlns:tns2="http://www.test.com/info">
  <person>
    <name>
      <tns2:first>Will</tns2:first>
      <tns2:last>Shakespeare</tns2:last>
    </name>
  </person>
</tns:add>

Now I get "Invalid content was found starting with element 'tns2:first'. One of '{"":first}' is expected." This is for exactly the same reason as <name" .... first and last are not global elements and elementFormDefault="unqualified", the default, says that they are not in any namespace. So I take thes eof:

<tns:add xmlns:tns="http://Component" xmlns:tns2="http://www.test.com/info">
  <person>
    <name>
      <first>Will</first>
      <last>Shakespeare</last>
    </name>
  </person>
</tns:add>

which now validates. This is what I want SDO to generate when I serialise my SDO., 

So I am sorry but I don't think the output you are proposing is correct. 

</MP>

<MP>The following block of text was put in by PGR without flags so I have added start and stop flags</MP>

<PGR>
With the fix I will apply the output looks like:
<?xml version="1.0" encoding="UTF-8"?>
<BOGUS xmlns="http://Component" xsi:type="add" xmlns:tns="http://Component" xmlns:tns2="http://www.test.com/info" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <person>
    <tns2:name>
      <tns2:first>Will</tns2:first>
      <tns2:last>Shakespeare</tns2:last>
    </tns2:name>
  </person>
</BOGUS>

... which I believe is correct.

I will look at the second problem you have with the catalog example. (If you could attach the full schema rather than sniippets it would make my life a lot easier ;-) )
</PGR>

<MP>I will attach full schema in future</MP>

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 http://www.test.com/info namespace, but it makes no
difference to the generated XML.

<PGR>elementFormDefault="qualified" is not currently supported. I am looking into this </PGR> 

<MP>Let's resolve 2. above i..e agree on the meaning of unqualified - and this may just come out in the wash</MP>

> Incorrect namespaces in generated XML
> -------------------------------------
>
>                 Key: TUSCANY-1112
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1112
>             Project: Tuscany
>          Issue Type: Bug
>          Components: C++ SDO
>    Affects Versions: Cpp-Next
>         Environment: WinXP
>            Reporter: Matthew Peters
>             Fix For: Cpp-Next
>
>
> Please excuse the fact that I have only a PHP testcase for this. The PHP is however pretty trivial and it seems a simple thing to make in C. Also, I know that the PHP layer is doing very little to interfere, so this is genuine Tuscany behaviour.
> Here is the bug report from the PHP bug tracking system:
> Description:
> ------------
> 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="http://www.test.com/info"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="add">
>   <person>
>     <tns2:name>
>       <first>Will</first>
>       <last>Shakespeare</last>
>     </tns2:name>
>   </person>
> </BOGUS>
> 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=http://www.test.com/info, 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 http://www.test.com/info namespace, but it makes no
> difference to the generated XML. 
> Reproduce code:
> ---------------
> <?php
> $xmldas = SDO_DAS_XML::create('types.xsd');
> $person =
> $xmldas->createDataObject('http://www.test.com/info','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;
> ?>
> types.xsd:
>     <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
>       xmlns:ns0="http://www.test.com/info"
>       targetNamespace="http://Component"
>       elementNameDefault="qualified">
>       <xs:import schemaLocation="person.xsd"
> namespace="http://www.test.com/info"/>
>       <xs:element name="add">
>         <xs:complexType>
>           <xs:sequence>
>             <xs:element name="person" type="ns0:personType"
> nillable="true"/>
>           </xs:sequence>
>         </xs:complexType>
>       </xs:element>
>     </xs:schema>
> person.xsd:
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema" 
>     targetNamespace="http://www.test.com/info" 
>     xmlns:info="http://www.test.com/info">
>     <complexType name="nameType">
> 		<sequence>
> 			<element name="first" type="string"></element>
> 			<element name="last" type="string"></element>
> 		</sequence>
> 	</complexType>
> 	<complexType name="personType">
> 		<sequence>
> 			<element name="name" type="info:nameType"></element>
> 		</sequence>
> 	</complexType>	
> </schema>
> Expected result:
> ----------------
> see above
> Actual result:
> --------------
> see above
> [2007-01-31 12:21 UTC] mfp at php dot net
> 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="http://www.w3.org/2001/XMLSchema"
>  xmlns:cat="catalogNS" xmlns:ord="orderNS" targetNamespace="catalogNS">
>   <include schemaLocation="Order.xsd"/>
>   <element name="catalog" type="cat:CatalogType"/>
>   <complexType name="CatalogType">
>     <sequence>
>       <element maxOccurs="unbounded" ref="ord:item"/>
>     </sequence>
>   </complexType>       
> </schema>
> Order.xsd defines the item element as being in the "OrderNS" namespace:
> .../...
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> 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="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:tns2="orderNS">
>   <item>
> .../...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Closed: (TUSCANY-1112) Incorrect namespaces in generated XML

Posted by "Matthew Peters (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matthew Peters closed TUSCANY-1112.
-----------------------------------

    Resolution: Fixed

> Incorrect namespaces in generated XML
> -------------------------------------
>
>                 Key: TUSCANY-1112
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1112
>             Project: Tuscany
>          Issue Type: Bug
>          Components: C++ SDO
>    Affects Versions: Cpp-Next
>         Environment: WinXP
>            Reporter: Matthew Peters
>             Fix For: Cpp-Next
>
>
> Please excuse the fact that I have only a PHP testcase for this. The PHP is however pretty trivial and it seems a simple thing to make in C. Also, I know that the PHP layer is doing very little to interfere, so this is genuine Tuscany behaviour.
> Here is the bug report from the PHP bug tracking system:
> Description:
> ------------
> 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="http://www.test.com/info"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="add">
>   <person>
>     <tns2:name>
>       <first>Will</first>
>       <last>Shakespeare</last>
>     </tns2:name>
>   </person>
> </BOGUS>
> 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=http://www.test.com/info, 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 http://www.test.com/info namespace, but it makes no
> difference to the generated XML. 
> Reproduce code:
> ---------------
> <?php
> $xmldas = SDO_DAS_XML::create('types.xsd');
> $person =
> $xmldas->createDataObject('http://www.test.com/info','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;
> ?>
> types.xsd:
>     <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
>       xmlns:ns0="http://www.test.com/info"
>       targetNamespace="http://Component"
>       elementNameDefault="qualified">
>       <xs:import schemaLocation="person.xsd"
> namespace="http://www.test.com/info"/>
>       <xs:element name="add">
>         <xs:complexType>
>           <xs:sequence>
>             <xs:element name="person" type="ns0:personType"
> nillable="true"/>
>           </xs:sequence>
>         </xs:complexType>
>       </xs:element>
>     </xs:schema>
> person.xsd:
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema" 
>     targetNamespace="http://www.test.com/info" 
>     xmlns:info="http://www.test.com/info">
>     <complexType name="nameType">
> 		<sequence>
> 			<element name="first" type="string"></element>
> 			<element name="last" type="string"></element>
> 		</sequence>
> 	</complexType>
> 	<complexType name="personType">
> 		<sequence>
> 			<element name="name" type="info:nameType"></element>
> 		</sequence>
> 	</complexType>	
> </schema>
> Expected result:
> ----------------
> see above
> Actual result:
> --------------
> see above
> [2007-01-31 12:21 UTC] mfp at php dot net
> 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="http://www.w3.org/2001/XMLSchema"
>  xmlns:cat="catalogNS" xmlns:ord="orderNS" targetNamespace="catalogNS">
>   <include schemaLocation="Order.xsd"/>
>   <element name="catalog" type="cat:CatalogType"/>
>   <complexType name="CatalogType">
>     <sequence>
>       <element maxOccurs="unbounded" ref="ord:item"/>
>     </sequence>
>   </complexType>       
> </schema>
> Order.xsd defines the item element as being in the "OrderNS" namespace:
> .../...
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> 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="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:tns2="orderNS">
>   <item>
> .../...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1112) Incorrect namespaces in generated XML

Posted by "Pete Robbins (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498555 ] 

Pete Robbins commented on TUSCANY-1112:
---------------------------------------

In a word... no :-(

I've been very busy on other things and am struggling to find the time to look into these.

On the plus side... it is open source and fairly easy to extract and build so don't be afraid to step in and provide patches ;-)

SDOXMLWriter.cpp is a good place to start.

Cheers,

PS. I'll try and find time to look at this next week.

> Incorrect namespaces in generated XML
> -------------------------------------
>
>                 Key: TUSCANY-1112
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1112
>             Project: Tuscany
>          Issue Type: Bug
>          Components: C++ SDO
>    Affects Versions: Cpp-current
>         Environment: WinXP
>            Reporter: Matthew Peters
>             Fix For: Cpp-current
>
>
> Please excuse the fact that I have only a PHP testcase for this. The PHP is however pretty trivial and it seems a simple thing to make in C. Also, I know that the PHP layer is doing very little to interfere, so this is genuine Tuscany behaviour.
> Here is the bug report from the PHP bug tracking system:
> Description:
> ------------
> 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="http://www.test.com/info"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="add">
>   <person>
>     <tns2:name>
>       <first>Will</first>
>       <last>Shakespeare</last>
>     </tns2:name>
>   </person>
> </BOGUS>
> 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=http://www.test.com/info, 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 http://www.test.com/info namespace, but it makes no
> difference to the generated XML. 
> Reproduce code:
> ---------------
> <?php
> $xmldas = SDO_DAS_XML::create('types.xsd');
> $person =
> $xmldas->createDataObject('http://www.test.com/info','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;
> ?>
> types.xsd:
>     <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
>       xmlns:ns0="http://www.test.com/info"
>       targetNamespace="http://Component"
>       elementNameDefault="qualified">
>       <xs:import schemaLocation="person.xsd"
> namespace="http://www.test.com/info"/>
>       <xs:element name="add">
>         <xs:complexType>
>           <xs:sequence>
>             <xs:element name="person" type="ns0:personType"
> nillable="true"/>
>           </xs:sequence>
>         </xs:complexType>
>       </xs:element>
>     </xs:schema>
> person.xsd:
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema" 
>     targetNamespace="http://www.test.com/info" 
>     xmlns:info="http://www.test.com/info">
>     <complexType name="nameType">
> 		<sequence>
> 			<element name="first" type="string"></element>
> 			<element name="last" type="string"></element>
> 		</sequence>
> 	</complexType>
> 	<complexType name="personType">
> 		<sequence>
> 			<element name="name" type="info:nameType"></element>
> 		</sequence>
> 	</complexType>	
> </schema>
> Expected result:
> ----------------
> see above
> Actual result:
> --------------
> see above
> [2007-01-31 12:21 UTC] mfp at php dot net
> 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="http://www.w3.org/2001/XMLSchema"
>  xmlns:cat="catalogNS" xmlns:ord="orderNS" targetNamespace="catalogNS">
>   <include schemaLocation="Order.xsd"/>
>   <element name="catalog" type="cat:CatalogType"/>
>   <complexType name="CatalogType">
>     <sequence>
>       <element maxOccurs="unbounded" ref="ord:item"/>
>     </sequence>
>   </complexType>       
> </schema>
> Order.xsd defines the item element as being in the "OrderNS" namespace:
> .../...
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> 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="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:tns2="orderNS">
>   <item>
> .../...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1112) Incorrect namespaces in generated XML

Posted by "Matthew Peters (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473121 ] 

Matthew Peters commented on TUSCANY-1112:
-----------------------------------------

Sorry there is a typo in the test case above - in one of the xsds I have put elementNameDefault and it should be elementFormDefault. 

> Incorrect namespaces in generated XML
> -------------------------------------
>
>                 Key: TUSCANY-1112
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1112
>             Project: Tuscany
>          Issue Type: Bug
>          Components: C++ DAS
>    Affects Versions: Cpp-current
>         Environment: WinXP
>            Reporter: Matthew Peters
>
> Please excuse the fact that I have only a PHP testcase for this. The PHP is however pretty trivial and it seems a simple thing to make in C. Also, I know that the PHP layer is doing very little to interfere, so this is genuine Tuscany behaviour.
> Here is the bug report from the PHP bug tracking system:
> Description:
> ------------
> 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="http://www.test.com/info"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="add">
>   <person>
>     <tns2:name>
>       <first>Will</first>
>       <last>Shakespeare</last>
>     </tns2:name>
>   </person>
> </BOGUS>
> 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=http://www.test.com/info, 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 http://www.test.com/info namespace, but it makes no
> difference to the generated XML. 
> Reproduce code:
> ---------------
> <?php
> $xmldas = SDO_DAS_XML::create('types.xsd');
> $person =
> $xmldas->createDataObject('http://www.test.com/info','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;
> ?>
> types.xsd:
>     <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
>       xmlns:ns0="http://www.test.com/info"
>       targetNamespace="http://Component"
>       elementNameDefault="qualified">
>       <xs:import schemaLocation="person.xsd"
> namespace="http://www.test.com/info"/>
>       <xs:element name="add">
>         <xs:complexType>
>           <xs:sequence>
>             <xs:element name="person" type="ns0:personType"
> nillable="true"/>
>           </xs:sequence>
>         </xs:complexType>
>       </xs:element>
>     </xs:schema>
> person.xsd:
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema" 
>     targetNamespace="http://www.test.com/info" 
>     xmlns:info="http://www.test.com/info">
>     <complexType name="nameType">
> 		<sequence>
> 			<element name="first" type="string"></element>
> 			<element name="last" type="string"></element>
> 		</sequence>
> 	</complexType>
> 	<complexType name="personType">
> 		<sequence>
> 			<element name="name" type="info:nameType"></element>
> 		</sequence>
> 	</complexType>	
> </schema>
> Expected result:
> ----------------
> see above
> Actual result:
> --------------
> see above
> [2007-01-31 12:21 UTC] mfp at php dot net
> 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="http://www.w3.org/2001/XMLSchema"
>  xmlns:cat="catalogNS" xmlns:ord="orderNS" targetNamespace="catalogNS">
>   <include schemaLocation="Order.xsd"/>
>   <element name="catalog" type="cat:CatalogType"/>
>   <complexType name="CatalogType">
>     <sequence>
>       <element maxOccurs="unbounded" ref="ord:item"/>
>     </sequence>
>   </complexType>       
> </schema>
> Order.xsd defines the item element as being in the "OrderNS" namespace:
> .../...
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> 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="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:tns2="orderNS">
>   <item>
> .../...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Updated: (TUSCANY-1112) Incorrect namespaces in generated XML

Posted by "Caroline Maynard (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Caroline Maynard updated TUSCANY-1112:
--------------------------------------

    Component/s:     (was: C++ DAS)
                 C++ SDO

> Incorrect namespaces in generated XML
> -------------------------------------
>
>                 Key: TUSCANY-1112
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1112
>             Project: Tuscany
>          Issue Type: Bug
>          Components: C++ SDO
>    Affects Versions: Cpp-current
>         Environment: WinXP
>            Reporter: Matthew Peters
>
> Please excuse the fact that I have only a PHP testcase for this. The PHP is however pretty trivial and it seems a simple thing to make in C. Also, I know that the PHP layer is doing very little to interfere, so this is genuine Tuscany behaviour.
> Here is the bug report from the PHP bug tracking system:
> Description:
> ------------
> 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="http://www.test.com/info"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="add">
>   <person>
>     <tns2:name>
>       <first>Will</first>
>       <last>Shakespeare</last>
>     </tns2:name>
>   </person>
> </BOGUS>
> 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=http://www.test.com/info, 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 http://www.test.com/info namespace, but it makes no
> difference to the generated XML. 
> Reproduce code:
> ---------------
> <?php
> $xmldas = SDO_DAS_XML::create('types.xsd');
> $person =
> $xmldas->createDataObject('http://www.test.com/info','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;
> ?>
> types.xsd:
>     <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
>       xmlns:ns0="http://www.test.com/info"
>       targetNamespace="http://Component"
>       elementNameDefault="qualified">
>       <xs:import schemaLocation="person.xsd"
> namespace="http://www.test.com/info"/>
>       <xs:element name="add">
>         <xs:complexType>
>           <xs:sequence>
>             <xs:element name="person" type="ns0:personType"
> nillable="true"/>
>           </xs:sequence>
>         </xs:complexType>
>       </xs:element>
>     </xs:schema>
> person.xsd:
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema" 
>     targetNamespace="http://www.test.com/info" 
>     xmlns:info="http://www.test.com/info">
>     <complexType name="nameType">
> 		<sequence>
> 			<element name="first" type="string"></element>
> 			<element name="last" type="string"></element>
> 		</sequence>
> 	</complexType>
> 	<complexType name="personType">
> 		<sequence>
> 			<element name="name" type="info:nameType"></element>
> 		</sequence>
> 	</complexType>	
> </schema>
> Expected result:
> ----------------
> see above
> Actual result:
> --------------
> see above
> [2007-01-31 12:21 UTC] mfp at php dot net
> 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="http://www.w3.org/2001/XMLSchema"
>  xmlns:cat="catalogNS" xmlns:ord="orderNS" targetNamespace="catalogNS">
>   <include schemaLocation="Order.xsd"/>
>   <element name="catalog" type="cat:CatalogType"/>
>   <complexType name="CatalogType">
>     <sequence>
>       <element maxOccurs="unbounded" ref="ord:item"/>
>     </sequence>
>   </complexType>       
> </schema>
> Order.xsd defines the item element as being in the "OrderNS" namespace:
> .../...
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> 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="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:tns2="orderNS">
>   <item>
> .../...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1112) Incorrect namespaces in generated XML

Posted by "Pete Robbins (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505150 ] 

Pete Robbins commented on TUSCANY-1112:
---------------------------------------

I think you may have 2 separate problems here. Let's start with your original report comments inline:

You say:

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. 
<PGR> The xsi:type is valid and is written because you are writing the root as an unknown element: "BOGUS". If you
saved this with the correct root element name, "add"m, then the xsi:type would not be needed and would be supressed </PGR>

2. name should not be in tns2=http://www.test.com/info, 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. 
<PGR> Fromm the schema name SHOULD be in tns2 and is written correctly. "first" and "last" should also be in tns2. This is a bug in writing primitive elements and I will check in a fix. 
elementFormDefault=unqualified means that a prefix is not REQUIRED not that it can not be written </PGR>

With the fix I will apply the output looks like:
<?xml version="1.0" encoding="UTF-8"?>
<BOGUS xmlns="http://Component" xsi:type="add" xmlns:tns="http://Component" xmlns:tns2="http://www.test.com/info" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <person>
    <tns2:name>
      <tns2:first>Will</tns2:first>
      <tns2:last>Shakespeare</tns2:last>
    </tns2:name>
  </person>
</BOGUS>

... which I believe is correct.

I will look at the second problem you have with the catalog example. (If you could attach the full schema rather than sniippets it would make my life a lot easier ;-) )
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 http://www.test.com/info namespace, but it makes no 
difference to the generated XML. 
<PGR>elementFormDefault="qualified"  is not currently supported. I am looking into this </PGR>



> Incorrect namespaces in generated XML
> -------------------------------------
>
>                 Key: TUSCANY-1112
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1112
>             Project: Tuscany
>          Issue Type: Bug
>          Components: C++ SDO
>    Affects Versions: Cpp-Next
>         Environment: WinXP
>            Reporter: Matthew Peters
>             Fix For: Cpp-Next
>
>
> Please excuse the fact that I have only a PHP testcase for this. The PHP is however pretty trivial and it seems a simple thing to make in C. Also, I know that the PHP layer is doing very little to interfere, so this is genuine Tuscany behaviour.
> Here is the bug report from the PHP bug tracking system:
> Description:
> ------------
> 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="http://www.test.com/info"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="add">
>   <person>
>     <tns2:name>
>       <first>Will</first>
>       <last>Shakespeare</last>
>     </tns2:name>
>   </person>
> </BOGUS>
> 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=http://www.test.com/info, 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 http://www.test.com/info namespace, but it makes no
> difference to the generated XML. 
> Reproduce code:
> ---------------
> <?php
> $xmldas = SDO_DAS_XML::create('types.xsd');
> $person =
> $xmldas->createDataObject('http://www.test.com/info','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;
> ?>
> types.xsd:
>     <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
>       xmlns:ns0="http://www.test.com/info"
>       targetNamespace="http://Component"
>       elementNameDefault="qualified">
>       <xs:import schemaLocation="person.xsd"
> namespace="http://www.test.com/info"/>
>       <xs:element name="add">
>         <xs:complexType>
>           <xs:sequence>
>             <xs:element name="person" type="ns0:personType"
> nillable="true"/>
>           </xs:sequence>
>         </xs:complexType>
>       </xs:element>
>     </xs:schema>
> person.xsd:
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema" 
>     targetNamespace="http://www.test.com/info" 
>     xmlns:info="http://www.test.com/info">
>     <complexType name="nameType">
> 		<sequence>
> 			<element name="first" type="string"></element>
> 			<element name="last" type="string"></element>
> 		</sequence>
> 	</complexType>
> 	<complexType name="personType">
> 		<sequence>
> 			<element name="name" type="info:nameType"></element>
> 		</sequence>
> 	</complexType>	
> </schema>
> Expected result:
> ----------------
> see above
> Actual result:
> --------------
> see above
> [2007-01-31 12:21 UTC] mfp at php dot net
> 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="http://www.w3.org/2001/XMLSchema"
>  xmlns:cat="catalogNS" xmlns:ord="orderNS" targetNamespace="catalogNS">
>   <include schemaLocation="Order.xsd"/>
>   <element name="catalog" type="cat:CatalogType"/>
>   <complexType name="CatalogType">
>     <sequence>
>       <element maxOccurs="unbounded" ref="ord:item"/>
>     </sequence>
>   </complexType>       
> </schema>
> Order.xsd defines the item element as being in the "OrderNS" namespace:
> .../...
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> 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="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:tns2="orderNS">
>   <item>
> .../...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org