You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Pete Robbins <ro...@googlemail.com> on 2006/12/15 00:09:34 UTC
[C++] The saga of writing xml element namespace prefixes ...
.. .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
Re: [C++] The saga of writing xml element namespace prefixes ...
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Pete Robbins wrote:
> On 15/12/06, Pete Robbins <ro...@googlemail.com> wrote:
>>
>>
>>
>> On 15/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> >
>> > Pete Robbins wrote:
>> > > On 14/12/06, Pete Robbins <robbinspg@googlemail.com > 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 ;-)
>
>
No problem, your fix works! the REST scenarios are up and running again.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Re: [C++] The saga of writing xml element namespace prefixes ...
Posted by Caroline Maynard <ca...@gmail.com>.
It works for me! Sebastien?
On 21/12/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> I have checked in a fix which I believe works for the PHP wsdl generation
> scenario and for our SCA samples.
>
--
Caroline
Re: Re: [C++] The saga of writing xml element namespace prefixes ...
Posted by Pete Robbins <ro...@googlemail.com>.
I have checked in a fix which I believe works for the PHP wsdl generation
scenario and for our SCA samples.
Cheers,
On 20/12/06, Caroline Maynard <ca...@gmail.com> wrote:
>
> Thanks, we're OK to stick with the old level for now. I understood this
> thread to say that the latest version would work both for Sebastien's
> scenario and for the WSDL generation, but it seems I was confused. I'll
> keep
> waiting for the ultimate fix ...
>
> On 20/12/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> >
> > Yes I know and it will likely remain that way for some time as I'm on
> > leave...
> >
> > I believe r485600 gives you the behaviour you want (though it is
> > incorrect it just happens to work for your scenario) so I would
> > recommend sticking with that until we can find a good solution.
>
>
> --
> Caroline
>
>
--
Pete
Re: Re: [C++] The saga of writing xml element namespace prefixes ...
Posted by Caroline Maynard <ca...@gmail.com>.
Thanks, we're OK to stick with the old level for now. I understood this
thread to say that the latest version would work both for Sebastien's
scenario and for the WSDL generation, but it seems I was confused. I'll keep
waiting for the ultimate fix ...
On 20/12/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> Yes I know and it will likely remain that way for some time as I'm on
> leave...
>
> I believe r485600 gives you the behaviour you want (though it is
> incorrect it just happens to work for your scenario) so I would
> recommend sticking with that until we can find a good solution.
--
Caroline
Re: Re: [C++] The saga of writing xml element namespace prefixes ...
Posted by Pete Robbins <ro...@googlemail.com>.
On 20/12/06, Caroline Maynard <ca...@gmail.com> wrote:
> Pete et al,
>
> The latest code from HEAD is still broken - it fails the
> http://issues.apache.org/jira/browse/TUSCANY-962 scenario. This is the #1
> use case for SCA - we cannot use this latest code with PHP.
>
> --
> Caroline
>
>
Yes I know and it will likely remain that way for some time as I'm on leave...
I believe r485600 gives you the behaviour you want (though it is
incorrect it just happens to work for your scenario) so I would
recommend sticking with that until we can find a good solution.
Cheers,
--
Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] The saga of writing xml element namespace prefixes ...
Posted by Caroline Maynard <ca...@gmail.com>.
Pete et al,
The latest code from HEAD is still broken - it fails the
http://issues.apache.org/jira/browse/TUSCANY-962 scenario. This is the #1
use case for SCA - we cannot use this latest code with PHP.
--
Caroline
Re: [C++] The saga of writing xml element namespace prefixes ...
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Pete Robbins wrote:
> On 15/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> Jean-Sebastien Delfino wrote:
>> > Pete Robbins wrote:
>> >> On 15/12/06, Pete Robbins <ro...@googlemail.com> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On 15/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> >>> >
>> >>> > Pete Robbins wrote:
>> >>> > > On 14/12/06, Pete Robbins <robbinspg@googlemail.com > 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.!!!
>
Easy to fix then, less code is better :) now removed under revision
r487692. Everything works for me now after having removed that line.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] The saga of writing xml element namespace prefixes ...
Posted by Pete Robbins <ro...@googlemail.com>.
On 15/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Jean-Sebastien Delfino wrote:
> > Pete Robbins wrote:
> >> On 15/12/06, Pete Robbins <ro...@googlemail.com> wrote:
> >>>
> >>>
> >>>
> >>> On 15/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >>> >
> >>> > Pete Robbins wrote:
> >>> > > On 14/12/06, Pete Robbins <robbinspg@googlemail.com > 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
Re: [C++] The saga of writing xml element namespace prefixes ...
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Pete Robbins wrote:
>> On 15/12/06, Pete Robbins <ro...@googlemail.com> wrote:
>>>
>>>
>>>
>>> On 15/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>> >
>>> > Pete Robbins wrote:
>>> > > On 14/12/06, Pete Robbins <robbinspg@googlemail.com > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] The saga of writing xml element namespace prefixes ...
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Pete Robbins wrote:
> On 15/12/06, Pete Robbins <ro...@googlemail.com> wrote:
>>
>>
>>
>> On 15/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> >
>> > Pete Robbins wrote:
>> > > On 14/12/06, Pete Robbins <robbinspg@googlemail.com > 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
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] The saga of writing xml element namespace prefixes ...
Posted by Pete Robbins <ro...@googlemail.com>.
On 15/12/06, Pete Robbins <ro...@googlemail.com> wrote:
>
>
>
> On 15/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > Pete Robbins wrote:
> > > On 14/12/06, Pete Robbins <robbinspg@googlemail.com > 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
Re: [C++] The saga of writing xml element namespace prefixes ...
Posted by Pete Robbins <ro...@googlemail.com>.
On 15/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Pete Robbins wrote:
> > On 14/12/06, Pete Robbins <ro...@googlemail.com> 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
Re: [C++] The saga of writing xml element namespace prefixes ...
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Pete Robbins wrote:
> On 14/12/06, Pete Robbins <ro...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] The saga of writing xml element namespace prefixes ...
Posted by Pete Robbins <ro...@googlemail.com>.
On 14/12/06, Pete Robbins <ro...@googlemail.com> 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