Pete Robbins wrote:
On 14/12/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
.. .and I suppose attributes too although we don't currently ever
write a
prefix on an attribute (we should!)
OK so I have been trying to fix the SDOXMLWriter code to "do the right
thing" and I think it is OK now for writing xsi:type information. The
problem we have is writing namespace prefix for elements. For example
(apologies for the inaccurate and loose schema but the gist should be
here):
<schema targetNameSpace="fred">
<element>
<complexType name="myType">
<sequence>
<element name="elemA" .../>
<element name="elemB" .../>
<any ...>
</sequence>
</complexType>
</element>
</schema> <schema targetNameSpace="joe">
<element name="elemX" ...../>
</schema>
So myType is open.
I could now load an xml document
<myType xmlns="fred" xmlns:tns="fred" xmlns:tns1="joe">
<elemA .../>
<elemB .../>
<tns1:elemX ... />
</myType>
and get a DataObject of Type "fred#myType" with 3 properties set: elemA,
elemB and elemX
Now if I want to write this as xml form the DataObject using
XMLHelper->save() what do I get?
Well we can write the <myType> and the "defined" properties elemA and
elemB without much trouble but how do we determine the namespace of
element
elemX? In this case I recently added code to the parsing code to
remember
the element namespace in our PropertyDefinition which is available to us
from the Property when serializing. So... I can see that elemX is an
element
defined in namespace "joe" and write it out correctly. THis is easy
!!! ;-)
So where does it all fall apart? A. If you create the DataObject not
from
deserializing an XML document as above but programatically.
Your code would look something like:
DataObjectPtr x = datafactory->create("fred", "myType");
x->setXXX("elemA", blah...);
or..
x->create("elemB");
x->setDataObject("elemX", somevalue_or_other);
So trying to serialize this we have no imformation about the namespace
that elemX is in.
I can't see any easy way around this and the various attempts to fix the
problem are really just best guess as to the namespace of the element:
- use the namespace of the element type
- use the namespace of the receiving DO
- use the namspace of the root DO
None of these are correct and each works fine in different scenarios
(which is why we are flip-flopping between breaking Sebastien's open
type
REST samples and Caroline's wsdl/soap php tests).
The only thing I can think of to fix this requires a change in the SDO
specification to make property names QNames. This would allow
programatically setting the namespace:
x->setDataObject("joe#elemx", somevalue_or_other);
Thoughts? Help?
--
Pete
I'm going to code up some "best guess" logic which I hope will cope with
most cases. Something along the lines of:
1. If the property was defined via schema then we know the
element namespace so we'll write the correct prefix
2. If the property was defined programatically
(DataFactory::addPropretyToType()) then we will assume the property
is in
the namespace of the parent Type
3. If the property is not defined (open property) then we will use the
namespace; if a global element property of the same name is defined
on the
RootType of
1. the namespace of the Type of the property
2. the target namespace
3. the namespace of the Type of the DataObject the property is
set on
Not perfect by any means but I think this will work for all our current
scenarios.
Pete,
I investigated further and found a workaround for the SDO issue breaking
the REST scenarios.
The REST code was doing something like
xmlHelper->save(xmlHelper->createDocument(dataObject)) to serialize the
response of the REST service to an XML doc.
Given a dataObject containing an integer (created from adding an integer
value to a DataObjectList), the SVN head code produces:
<Integer xmlns="commonj.sdo">3</Integer>
Loading this back into SDO results in a NULL value on the client instead
of the expected value "3".
With SVN r480964, an old revision but the last one that was working for
me, the same code produced:
<Integer>3</Integer>
which correctly loaded "3" (as a string but I was still getting some data).
I changed my code to pass a dummy http://tempuri.org namespace to the
createDocument() method if dataObject->getType().getURI() ==
"commonj.sdo" and with the SVN head this produces:
<Integer xmlns="http://tempuri.org";>3</Integer>
which SDO correctly loads on the client.
I am OK for now using this http://tempuri.org namespace when there is no
WSDL/XSD describing the expected response, and am getting the data back
on the client, all happy :)
Hope this helps understand what the issue was, and at least gives you
more time to think through it.
The SDO improvements you've described in this thread look fine to me,
but this goes a little over my head :) maybe our SDO C++ and Java folks
could jump in and give us their thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
