[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
