On 15/12/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote:
> Pete Robbins wrote:
>> 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 ;-)
>>
>>
>
> Is the test on SDOXMLWriter.cpp:974 correct? Here's the code:
> <<<
> if (pi && !(pi->getPropertyDefinition().isElement))
> writeDO(doValue, seqPropURI, seqPropName, xsiTypeNeeded);
> >>>
>
> I have an open type DataObject, and am doing
> dataObject->getList("abc").append(anotherDataObject).
> SDOXMLWriter.writeDO(dataObject) gets to line 974, as dataObject is a
> sequenced DataObject, and does not write the element representing
> anotherDataObject since there is no XSDPropertyInfo for the sequence
> entry and pi == NULL.
>
> Is this by design or a bug?
> Shouldn't a sequence entry be written as an element if there's no XSD
> info for it (which is the case with open content)?
> I thought that sequences were only used for elements, is that true?
>
> Thanks
>
More info, I tried a local change to investigate further. If I change
line 974 to the opposite condition: if (!pi ||
(pi->getPropertyDefinition().isElement)), then complex DataObjects under
a Sequence in an Open DataObject are correctly written as elements.
--
Jean-Sebastien
umm I don't think that line should be there at all.!!!
--
Pete
