On 15/12/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
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
That sounds an easy thing to fix. I shouldn't be writing any
commonj.sdonamespace info.
Cheers,
--
Pete
