On 15/12/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
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.
Fix checked in. Apologies for breaking it for a few days ;-)
--
Pete
