You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Geoffrey Winn <ge...@googlemail.com> on 2006/10/09 10:10:24 UTC
Re: [C++] SDO can't load an XML doc with no namespace
Sebastian,
I looked into this a bit more and it may not be as bad as it appears.
Currently, when the XML parser encounters an element for which there is no
type defined, it ignores that element and all of its content, resuming the
parse once that unknown element has ended. The exception to this is when the
element is a member of a parent that is defined to have open content. In
your example, the root element has no type definition and, of course, it
can't have a parent with open content, so it and all of its contents are
ignored, which explains the output that you see.
I can see one possible workaround and one possible fix for this.
The workaround is that you provide an xsd that defines just the root element
giving it open content. In your case that would be something like
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="customer" type="customerType"/>
<xsd:complexType name="customerType">
<xsd:sequence>
<xsd:any namespace="##other" processContents="lax"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
Then the root element has a type and will be processed normally, and
everything it contains will be processed as open content. I tried this and
it seems to work.
The fix would be for me to hack the code so that when we find that a root
element has no corresponding type (or possibly when there are no user
defined types at all) then I could automagically create an open type for it.
This would give the same behaviour as the previous case but spare you the
need to provide the .xsd
I'm inclined to just go ahead and do that since its not obviously any worse
than the current behaviour but I'm open to other ideas.
Regards,
Geoff.
On 07/09/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Well, I can load it, but it's desperately empty :)
>
> Given the following XML:
> <customer><firstName>Jane</firstName><lastName>Doe</lastName></customer>
>
> I have no XSD for this document, and don't want to have one or have to
> define specific SDO types for it. I just want to load this XML into an
> SDO DataObject.
>
> XMLDocumentPtr doc = XMLHelper::load(xml);
> gives me an XMLDocumentPtr with no root DataObject.
>
> char* xml = XMLHelper::save(doc);
> gives me this:
> <?xml version="1.0" encoding="UTF-8"?>
>
> Is this supported by our SDO/C++ implementation? or is it a bug?
>
> --
> 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++] SDO can't load an XML doc with no namespace
Posted by Simon Laws <si...@googlemail.com>.
On 10/9/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> You are assuming the state of the DataFactory that is passed in when
> loading
> the xml.
>
> XMLHelperptr xmlH = HelperProvider::getXMLHelper(); // returns "clean" XML
> helper with virgin DataFactory
> XMLDocumentPtr xmlD = xmlH->load("mySchemaless.xml"); // your fix would
> make
> this work BUT the DataFactory is now "frozen"
> XMLDocumentPtr xmlD = xmlH->load("anotherSchemaless.xml"); // Bang! -
> can't
> add a new open type as DF is frozen
>
> I would look at always defining an open type e.g. commonj/sdo#AnyOpenType
> in
> a DataFactory. When loading the schemaless xml you create one of these
> then
> create the DO's from the xml with this as the root (pseudo-root). The
> XMLDocument returned would have the first DO defined from the xml as the
> rootDataObject, not the pseudo-root.
>
> Cheers,
>
> On 09/10/06, Geoffrey Winn <ge...@googlemail.com> wrote:
> >
> > That is still a separate issue from the one Sebastian raised.
> >
> > Sebastian specifically stated that he did not have an xsd and didn't
> want
> > one. Loading an XML instance without type information in that situation
> > can
> > be done, via a small xsd file immediately (as a workaround), and via
> small
> > code change soon. The issue of frozen type systems affects other things
> > besides this one. It needs to be fixed, but it's still a separate
> > question.
> >
> > Geoff.
> >
> > On 09/10/06, Pete Robbins <ro...@googlemail.com> wrote:
> > >
> > > Well it depends on which DataFactory you are using during the loading
> of
> > > the
> > > xml. I would usually create an XSDHelper and load a schema. I'd then
> > > create
> > > an XMLHelper using the DataFactory from the XSDHelper. I then load my
> > xml.
> > > If I now load a "schemaless" xml using that XMLHelper how do you
> create
> > > the
> > > new Open Type?
> > >
> > > Cheers,
> > >
> > >
> > > On 09/10/06, Geoffrey Winn <ge...@googlemail.com> wrote:
> > > >
> > > > That's a different question.
> > > >
> > > > As I understand it, Sebastian (and others) were asking about loading
> > an
> > > > XML
> > > > instance document without a corresponding xsd (or any other type
> > > > information) and as above there is a way to do that and I can hack
> it
> > to
> > > > make it a little easier.
> > > >
> > > > As you say, you cannot create any type at all after the first data
> > > object
> > > > is
> > > > created. I'm looking into relaxing that too, but it is a separate
> > issue
> > > > from
> > > > processing XML without a schema.
> > > >
> > > > Regards,
> > > >
> > > > Geoff.
> > > >
> > > > On 09/10/06, Pete Robbins <ro...@googlemail.com> wrote:
> > > > >
> > > > > Can you create an open type on the fly? Is the datafactory not
> > > "locked"
> > > > > once
> > > > > the first DO is created?
> > > > >
> > > > > Cheers,
> > > > >
> > > > >
> > > > > On 09/10/06, Geoffrey Winn <ge...@googlemail.com> wrote:
> > > > > >
> > > > > > Sebastian,
> > > > > >
> > > > > > I looked into this a bit more and it may not be as bad as it
> > > appears.
> > > > > >
> > > > > > Currently, when the XML parser encounters an element for which
> > there
> > > > is
> > > > > no
> > > > > > type defined, it ignores that element and all of its content,
> > > resuming
> > > > > the
> > > > > > parse once that unknown element has ended. The exception to this
> > is
> > > > when
> > > > > > the
> > > > > > element is a member of a parent that is defined to have open
> > > content.
> > > > In
> > > > > > your example, the root element has no type definition and, of
> > > course,
> > > > it
> > > > > > can't have a parent with open content, so it and all of its
> > contents
> > > > are
> > > > > > ignored, which explains the output that you see.
> > > > > >
> > > > > > I can see one possible workaround and one possible fix for this.
> > > > > >
> > > > > > The workaround is that you provide an xsd that defines just the
> > root
> > > > > > element
> > > > > > giving it open content. In your case that would be something
> like
> > > > > >
> > > > > > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> > > > > > <xsd:element name="customer" type="customerType"/>
> > > > > > <xsd:complexType name="customerType">
> > > > > > <xsd:sequence>
> > > > > > <xsd:any namespace="##other" processContents="lax"/>
> > > > > > </xsd:sequence>
> > > > > > </xsd:complexType>
> > > > > > </xsd:schema>
> > > > > >
> > > > > > Then the root element has a type and will be processed normally,
> > and
> > > > > > everything it contains will be processed as open content. I
> tried
> > > this
> > > > > and
> > > > > > it seems to work.
> > > > > >
> > > > > > The fix would be for me to hack the code so that when we find
> that
> > a
> > > > > root
> > > > > > element has no corresponding type (or possibly when there are no
> > > user
> > > > > > defined types at all) then I could automagically create an open
> > type
> > > > for
> > > > > > it.
> > > > > > This would give the same behaviour as the previous case but
> spare
> > > you
> > > > > the
> > > > > > need to provide the .xsd
> > > > > >
> > > > > > I'm inclined to just go ahead and do that since its not
> obviously
> > > any
> > > > > > worse
> > > > > > than the current behaviour but I'm open to other ideas.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Geoff.
> > > > > >
> > > > > > On 07/09/06, Jean-Sebastien Delfino <js...@apache.org>
> wrote:
> > > > > > >
> > > > > > > Well, I can load it, but it's desperately empty :)
> > > > > > >
> > > > > > > Given the following XML:
> > > > > > >
> > > > >
> > >
> <customer><firstName>Jane</firstName><lastName>Doe</lastName></customer>
> > > > > > >
> > > > > > > I have no XSD for this document, and don't want to have one or
> > > have
> > > > to
> > > > > > > define specific SDO types for it. I just want to load this XML
> > > into
> > > > an
> > > > > > > SDO DataObject.
> > > > > > >
> > > > > > > XMLDocumentPtr doc = XMLHelper::load(xml);
> > > > > > > gives me an XMLDocumentPtr with no root DataObject.
> > > > > > >
> > > > > > > char* xml = XMLHelper::save(doc);
> > > > > > > gives me this:
> > > > > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > > > >
> > > > > > > Is this supported by our SDO/C++ implementation? or is it a
> bug?
> > > > > > >
> > > > > > > --
> > > > > > > Jean-Sebastien
> > > > > > >
> > > > > > >
> > > > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail:
> tuscany-dev-help@ws.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Pete
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Pete
> > >
> > >
> >
> >
>
>
> --
> Pete
This is the one I'm using in the PHP JSON DAS. Not tested to the extreme yet
but this is the way I'm going.
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/schemafree"
xmlns:tns="http://www.example.org/schemafree">
<complexType name="GenericType">
<sequence>
<any namespace="##any" minOccurs="1" maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="SchemaFree" type="tns:GenericType"/>
</schema>
Simon
Re: [C++] SDO can't load an XML doc with no namespace
Posted by Pete Robbins <ro...@googlemail.com>.
You are assuming the state of the DataFactory that is passed in when loading
the xml.
XMLHelperptr xmlH = HelperProvider::getXMLHelper(); // returns "clean" XML
helper with virgin DataFactory
XMLDocumentPtr xmlD = xmlH->load("mySchemaless.xml"); // your fix would make
this work BUT the DataFactory is now "frozen"
XMLDocumentPtr xmlD = xmlH->load("anotherSchemaless.xml"); // Bang! - can't
add a new open type as DF is frozen
I would look at always defining an open type e.g. commonj/sdo#AnyOpenType in
a DataFactory. When loading the schemaless xml you create one of these then
create the DO's from the xml with this as the root (pseudo-root). The
XMLDocument returned would have the first DO defined from the xml as the
rootDataObject, not the pseudo-root.
Cheers,
On 09/10/06, Geoffrey Winn <ge...@googlemail.com> wrote:
>
> That is still a separate issue from the one Sebastian raised.
>
> Sebastian specifically stated that he did not have an xsd and didn't want
> one. Loading an XML instance without type information in that situation
> can
> be done, via a small xsd file immediately (as a workaround), and via small
> code change soon. The issue of frozen type systems affects other things
> besides this one. It needs to be fixed, but it's still a separate
> question.
>
> Geoff.
>
> On 09/10/06, Pete Robbins <ro...@googlemail.com> wrote:
> >
> > Well it depends on which DataFactory you are using during the loading of
> > the
> > xml. I would usually create an XSDHelper and load a schema. I'd then
> > create
> > an XMLHelper using the DataFactory from the XSDHelper. I then load my
> xml.
> > If I now load a "schemaless" xml using that XMLHelper how do you create
> > the
> > new Open Type?
> >
> > Cheers,
> >
> >
> > On 09/10/06, Geoffrey Winn <ge...@googlemail.com> wrote:
> > >
> > > That's a different question.
> > >
> > > As I understand it, Sebastian (and others) were asking about loading
> an
> > > XML
> > > instance document without a corresponding xsd (or any other type
> > > information) and as above there is a way to do that and I can hack it
> to
> > > make it a little easier.
> > >
> > > As you say, you cannot create any type at all after the first data
> > object
> > > is
> > > created. I'm looking into relaxing that too, but it is a separate
> issue
> > > from
> > > processing XML without a schema.
> > >
> > > Regards,
> > >
> > > Geoff.
> > >
> > > On 09/10/06, Pete Robbins <ro...@googlemail.com> wrote:
> > > >
> > > > Can you create an open type on the fly? Is the datafactory not
> > "locked"
> > > > once
> > > > the first DO is created?
> > > >
> > > > Cheers,
> > > >
> > > >
> > > > On 09/10/06, Geoffrey Winn <ge...@googlemail.com> wrote:
> > > > >
> > > > > Sebastian,
> > > > >
> > > > > I looked into this a bit more and it may not be as bad as it
> > appears.
> > > > >
> > > > > Currently, when the XML parser encounters an element for which
> there
> > > is
> > > > no
> > > > > type defined, it ignores that element and all of its content,
> > resuming
> > > > the
> > > > > parse once that unknown element has ended. The exception to this
> is
> > > when
> > > > > the
> > > > > element is a member of a parent that is defined to have open
> > content.
> > > In
> > > > > your example, the root element has no type definition and, of
> > course,
> > > it
> > > > > can't have a parent with open content, so it and all of its
> contents
> > > are
> > > > > ignored, which explains the output that you see.
> > > > >
> > > > > I can see one possible workaround and one possible fix for this.
> > > > >
> > > > > The workaround is that you provide an xsd that defines just the
> root
> > > > > element
> > > > > giving it open content. In your case that would be something like
> > > > >
> > > > > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> > > > > <xsd:element name="customer" type="customerType"/>
> > > > > <xsd:complexType name="customerType">
> > > > > <xsd:sequence>
> > > > > <xsd:any namespace="##other" processContents="lax"/>
> > > > > </xsd:sequence>
> > > > > </xsd:complexType>
> > > > > </xsd:schema>
> > > > >
> > > > > Then the root element has a type and will be processed normally,
> and
> > > > > everything it contains will be processed as open content. I tried
> > this
> > > > and
> > > > > it seems to work.
> > > > >
> > > > > The fix would be for me to hack the code so that when we find that
> a
> > > > root
> > > > > element has no corresponding type (or possibly when there are no
> > user
> > > > > defined types at all) then I could automagically create an open
> type
> > > for
> > > > > it.
> > > > > This would give the same behaviour as the previous case but spare
> > you
> > > > the
> > > > > need to provide the .xsd
> > > > >
> > > > > I'm inclined to just go ahead and do that since its not obviously
> > any
> > > > > worse
> > > > > than the current behaviour but I'm open to other ideas.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Geoff.
> > > > >
> > > > > On 07/09/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > > > > >
> > > > > > Well, I can load it, but it's desperately empty :)
> > > > > >
> > > > > > Given the following XML:
> > > > > >
> > > >
> > <customer><firstName>Jane</firstName><lastName>Doe</lastName></customer>
> > > > > >
> > > > > > I have no XSD for this document, and don't want to have one or
> > have
> > > to
> > > > > > define specific SDO types for it. I just want to load this XML
> > into
> > > an
> > > > > > SDO DataObject.
> > > > > >
> > > > > > XMLDocumentPtr doc = XMLHelper::load(xml);
> > > > > > gives me an XMLDocumentPtr with no root DataObject.
> > > > > >
> > > > > > char* xml = XMLHelper::save(doc);
> > > > > > gives me this:
> > > > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > > >
> > > > > > Is this supported by our SDO/C++ implementation? or is it a bug?
> > > > > >
> > > > > > --
> > > > > > Jean-Sebastien
> > > > > >
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Pete
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Pete
> >
> >
>
>
--
Pete
Re: [C++] SDO can't load an XML doc with no namespace
Posted by Geoffrey Winn <ge...@googlemail.com>.
That is still a separate issue from the one Sebastian raised.
Sebastian specifically stated that he did not have an xsd and didn't want
one. Loading an XML instance without type information in that situation can
be done, via a small xsd file immediately (as a workaround), and via small
code change soon. The issue of frozen type systems affects other things
besides this one. It needs to be fixed, but it's still a separate question.
Geoff.
On 09/10/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> Well it depends on which DataFactory you are using during the loading of
> the
> xml. I would usually create an XSDHelper and load a schema. I'd then
> create
> an XMLHelper using the DataFactory from the XSDHelper. I then load my xml.
> If I now load a "schemaless" xml using that XMLHelper how do you create
> the
> new Open Type?
>
> Cheers,
>
>
> On 09/10/06, Geoffrey Winn <ge...@googlemail.com> wrote:
> >
> > That's a different question.
> >
> > As I understand it, Sebastian (and others) were asking about loading an
> > XML
> > instance document without a corresponding xsd (or any other type
> > information) and as above there is a way to do that and I can hack it to
> > make it a little easier.
> >
> > As you say, you cannot create any type at all after the first data
> object
> > is
> > created. I'm looking into relaxing that too, but it is a separate issue
> > from
> > processing XML without a schema.
> >
> > Regards,
> >
> > Geoff.
> >
> > On 09/10/06, Pete Robbins <ro...@googlemail.com> wrote:
> > >
> > > Can you create an open type on the fly? Is the datafactory not
> "locked"
> > > once
> > > the first DO is created?
> > >
> > > Cheers,
> > >
> > >
> > > On 09/10/06, Geoffrey Winn <ge...@googlemail.com> wrote:
> > > >
> > > > Sebastian,
> > > >
> > > > I looked into this a bit more and it may not be as bad as it
> appears.
> > > >
> > > > Currently, when the XML parser encounters an element for which there
> > is
> > > no
> > > > type defined, it ignores that element and all of its content,
> resuming
> > > the
> > > > parse once that unknown element has ended. The exception to this is
> > when
> > > > the
> > > > element is a member of a parent that is defined to have open
> content.
> > In
> > > > your example, the root element has no type definition and, of
> course,
> > it
> > > > can't have a parent with open content, so it and all of its contents
> > are
> > > > ignored, which explains the output that you see.
> > > >
> > > > I can see one possible workaround and one possible fix for this.
> > > >
> > > > The workaround is that you provide an xsd that defines just the root
> > > > element
> > > > giving it open content. In your case that would be something like
> > > >
> > > > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> > > > <xsd:element name="customer" type="customerType"/>
> > > > <xsd:complexType name="customerType">
> > > > <xsd:sequence>
> > > > <xsd:any namespace="##other" processContents="lax"/>
> > > > </xsd:sequence>
> > > > </xsd:complexType>
> > > > </xsd:schema>
> > > >
> > > > Then the root element has a type and will be processed normally, and
> > > > everything it contains will be processed as open content. I tried
> this
> > > and
> > > > it seems to work.
> > > >
> > > > The fix would be for me to hack the code so that when we find that a
> > > root
> > > > element has no corresponding type (or possibly when there are no
> user
> > > > defined types at all) then I could automagically create an open type
> > for
> > > > it.
> > > > This would give the same behaviour as the previous case but spare
> you
> > > the
> > > > need to provide the .xsd
> > > >
> > > > I'm inclined to just go ahead and do that since its not obviously
> any
> > > > worse
> > > > than the current behaviour but I'm open to other ideas.
> > > >
> > > > Regards,
> > > >
> > > > Geoff.
> > > >
> > > > On 07/09/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > > > >
> > > > > Well, I can load it, but it's desperately empty :)
> > > > >
> > > > > Given the following XML:
> > > > >
> > >
> <customer><firstName>Jane</firstName><lastName>Doe</lastName></customer>
> > > > >
> > > > > I have no XSD for this document, and don't want to have one or
> have
> > to
> > > > > define specific SDO types for it. I just want to load this XML
> into
> > an
> > > > > SDO DataObject.
> > > > >
> > > > > XMLDocumentPtr doc = XMLHelper::load(xml);
> > > > > gives me an XMLDocumentPtr with no root DataObject.
> > > > >
> > > > > char* xml = XMLHelper::save(doc);
> > > > > gives me this:
> > > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > >
> > > > > Is this supported by our SDO/C++ implementation? or is it a bug?
> > > > >
> > > > > --
> > > > > Jean-Sebastien
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Pete
> > >
> > >
> >
> >
>
>
> --
> Pete
>
>
Re: [C++] SDO can't load an XML doc with no namespace
Posted by Pete Robbins <ro...@googlemail.com>.
Well it depends on which DataFactory you are using during the loading of the
xml. I would usually create an XSDHelper and load a schema. I'd then create
an XMLHelper using the DataFactory from the XSDHelper. I then load my xml.
If I now load a "schemaless" xml using that XMLHelper how do you create the
new Open Type?
Cheers,
On 09/10/06, Geoffrey Winn <ge...@googlemail.com> wrote:
>
> That's a different question.
>
> As I understand it, Sebastian (and others) were asking about loading an
> XML
> instance document without a corresponding xsd (or any other type
> information) and as above there is a way to do that and I can hack it to
> make it a little easier.
>
> As you say, you cannot create any type at all after the first data object
> is
> created. I'm looking into relaxing that too, but it is a separate issue
> from
> processing XML without a schema.
>
> Regards,
>
> Geoff.
>
> On 09/10/06, Pete Robbins <ro...@googlemail.com> wrote:
> >
> > Can you create an open type on the fly? Is the datafactory not "locked"
> > once
> > the first DO is created?
> >
> > Cheers,
> >
> >
> > On 09/10/06, Geoffrey Winn <ge...@googlemail.com> wrote:
> > >
> > > Sebastian,
> > >
> > > I looked into this a bit more and it may not be as bad as it appears.
> > >
> > > Currently, when the XML parser encounters an element for which there
> is
> > no
> > > type defined, it ignores that element and all of its content, resuming
> > the
> > > parse once that unknown element has ended. The exception to this is
> when
> > > the
> > > element is a member of a parent that is defined to have open content.
> In
> > > your example, the root element has no type definition and, of course,
> it
> > > can't have a parent with open content, so it and all of its contents
> are
> > > ignored, which explains the output that you see.
> > >
> > > I can see one possible workaround and one possible fix for this.
> > >
> > > The workaround is that you provide an xsd that defines just the root
> > > element
> > > giving it open content. In your case that would be something like
> > >
> > > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> > > <xsd:element name="customer" type="customerType"/>
> > > <xsd:complexType name="customerType">
> > > <xsd:sequence>
> > > <xsd:any namespace="##other" processContents="lax"/>
> > > </xsd:sequence>
> > > </xsd:complexType>
> > > </xsd:schema>
> > >
> > > Then the root element has a type and will be processed normally, and
> > > everything it contains will be processed as open content. I tried this
> > and
> > > it seems to work.
> > >
> > > The fix would be for me to hack the code so that when we find that a
> > root
> > > element has no corresponding type (or possibly when there are no user
> > > defined types at all) then I could automagically create an open type
> for
> > > it.
> > > This would give the same behaviour as the previous case but spare you
> > the
> > > need to provide the .xsd
> > >
> > > I'm inclined to just go ahead and do that since its not obviously any
> > > worse
> > > than the current behaviour but I'm open to other ideas.
> > >
> > > Regards,
> > >
> > > Geoff.
> > >
> > > On 07/09/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > > >
> > > > Well, I can load it, but it's desperately empty :)
> > > >
> > > > Given the following XML:
> > > >
> > <customer><firstName>Jane</firstName><lastName>Doe</lastName></customer>
> > > >
> > > > I have no XSD for this document, and don't want to have one or have
> to
> > > > define specific SDO types for it. I just want to load this XML into
> an
> > > > SDO DataObject.
> > > >
> > > > XMLDocumentPtr doc = XMLHelper::load(xml);
> > > > gives me an XMLDocumentPtr with no root DataObject.
> > > >
> > > > char* xml = XMLHelper::save(doc);
> > > > gives me this:
> > > > <?xml version="1.0" encoding="UTF-8"?>
> > > >
> > > > Is this supported by our SDO/C++ implementation? or is it a bug?
> > > >
> > > > --
> > > > Jean-Sebastien
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Pete
> >
> >
>
>
--
Pete
Re: [C++] SDO can't load an XML doc with no namespace
Posted by Geoffrey Winn <ge...@googlemail.com>.
That's a different question.
As I understand it, Sebastian (and others) were asking about loading an XML
instance document without a corresponding xsd (or any other type
information) and as above there is a way to do that and I can hack it to
make it a little easier.
As you say, you cannot create any type at all after the first data object is
created. I'm looking into relaxing that too, but it is a separate issue from
processing XML without a schema.
Regards,
Geoff.
On 09/10/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> Can you create an open type on the fly? Is the datafactory not "locked"
> once
> the first DO is created?
>
> Cheers,
>
>
> On 09/10/06, Geoffrey Winn <ge...@googlemail.com> wrote:
> >
> > Sebastian,
> >
> > I looked into this a bit more and it may not be as bad as it appears.
> >
> > Currently, when the XML parser encounters an element for which there is
> no
> > type defined, it ignores that element and all of its content, resuming
> the
> > parse once that unknown element has ended. The exception to this is when
> > the
> > element is a member of a parent that is defined to have open content. In
> > your example, the root element has no type definition and, of course, it
> > can't have a parent with open content, so it and all of its contents are
> > ignored, which explains the output that you see.
> >
> > I can see one possible workaround and one possible fix for this.
> >
> > The workaround is that you provide an xsd that defines just the root
> > element
> > giving it open content. In your case that would be something like
> >
> > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> > <xsd:element name="customer" type="customerType"/>
> > <xsd:complexType name="customerType">
> > <xsd:sequence>
> > <xsd:any namespace="##other" processContents="lax"/>
> > </xsd:sequence>
> > </xsd:complexType>
> > </xsd:schema>
> >
> > Then the root element has a type and will be processed normally, and
> > everything it contains will be processed as open content. I tried this
> and
> > it seems to work.
> >
> > The fix would be for me to hack the code so that when we find that a
> root
> > element has no corresponding type (or possibly when there are no user
> > defined types at all) then I could automagically create an open type for
> > it.
> > This would give the same behaviour as the previous case but spare you
> the
> > need to provide the .xsd
> >
> > I'm inclined to just go ahead and do that since its not obviously any
> > worse
> > than the current behaviour but I'm open to other ideas.
> >
> > Regards,
> >
> > Geoff.
> >
> > On 07/09/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > >
> > > Well, I can load it, but it's desperately empty :)
> > >
> > > Given the following XML:
> > >
> <customer><firstName>Jane</firstName><lastName>Doe</lastName></customer>
> > >
> > > I have no XSD for this document, and don't want to have one or have to
> > > define specific SDO types for it. I just want to load this XML into an
> > > SDO DataObject.
> > >
> > > XMLDocumentPtr doc = XMLHelper::load(xml);
> > > gives me an XMLDocumentPtr with no root DataObject.
> > >
> > > char* xml = XMLHelper::save(doc);
> > > gives me this:
> > > <?xml version="1.0" encoding="UTF-8"?>
> > >
> > > Is this supported by our SDO/C++ implementation? or is it a bug?
> > >
> > > --
> > > Jean-Sebastien
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> >
>
>
> --
> Pete
>
>
Re: [C++] SDO can't load an XML doc with no namespace
Posted by Pete Robbins <ro...@googlemail.com>.
Can you create an open type on the fly? Is the datafactory not "locked" once
the first DO is created?
Cheers,
On 09/10/06, Geoffrey Winn <ge...@googlemail.com> wrote:
>
> Sebastian,
>
> I looked into this a bit more and it may not be as bad as it appears.
>
> Currently, when the XML parser encounters an element for which there is no
> type defined, it ignores that element and all of its content, resuming the
> parse once that unknown element has ended. The exception to this is when
> the
> element is a member of a parent that is defined to have open content. In
> your example, the root element has no type definition and, of course, it
> can't have a parent with open content, so it and all of its contents are
> ignored, which explains the output that you see.
>
> I can see one possible workaround and one possible fix for this.
>
> The workaround is that you provide an xsd that defines just the root
> element
> giving it open content. In your case that would be something like
>
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> <xsd:element name="customer" type="customerType"/>
> <xsd:complexType name="customerType">
> <xsd:sequence>
> <xsd:any namespace="##other" processContents="lax"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:schema>
>
> Then the root element has a type and will be processed normally, and
> everything it contains will be processed as open content. I tried this and
> it seems to work.
>
> The fix would be for me to hack the code so that when we find that a root
> element has no corresponding type (or possibly when there are no user
> defined types at all) then I could automagically create an open type for
> it.
> This would give the same behaviour as the previous case but spare you the
> need to provide the .xsd
>
> I'm inclined to just go ahead and do that since its not obviously any
> worse
> than the current behaviour but I'm open to other ideas.
>
> Regards,
>
> Geoff.
>
> On 07/09/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > Well, I can load it, but it's desperately empty :)
> >
> > Given the following XML:
> > <customer><firstName>Jane</firstName><lastName>Doe</lastName></customer>
> >
> > I have no XSD for this document, and don't want to have one or have to
> > define specific SDO types for it. I just want to load this XML into an
> > SDO DataObject.
> >
> > XMLDocumentPtr doc = XMLHelper::load(xml);
> > gives me an XMLDocumentPtr with no root DataObject.
> >
> > char* xml = XMLHelper::save(doc);
> > gives me this:
> > <?xml version="1.0" encoding="UTF-8"?>
> >
> > Is this supported by our SDO/C++ implementation? or is it a bug?
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
--
Pete
Re: [C++] SDO can't load an XML doc with no namespace
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Geoffrey Winn wrote:
> Sebastian,
>
> I looked into this a bit more and it may not be as bad as it appears.
>
> Currently, when the XML parser encounters an element for which there
> is no
> type defined, it ignores that element and all of its content, resuming
> the
> parse once that unknown element has ended. The exception to this is
> when the
> element is a member of a parent that is defined to have open content. In
> your example, the root element has no type definition and, of course, it
> can't have a parent with open content, so it and all of its contents are
> ignored, which explains the output that you see.
>
> I can see one possible workaround and one possible fix for this.
>
> The workaround is that you provide an xsd that defines just the root
> element
> giving it open content. In your case that would be something like
>
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> <xsd:element name="customer" type="customerType"/>
> <xsd:complexType name="customerType">
> <xsd:sequence>
> <xsd:any namespace="##other" processContents="lax"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:schema>
>
> Then the root element has a type and will be processed normally, and
> everything it contains will be processed as open content. I tried this
> and
> it seems to work.
>
Good, that's the workaround I'm currently using in the WS binding
extension :) Basically instead of just deserializing a SOAP Body part
(which won't work in the type of the part is not known, as you explain),
I deserialize the SOAP body, which is defined pretty much like you show
here.
> The fix would be for me to hack the code so that when we find that a root
> element has no corresponding type (or possibly when there are no user
> defined types at all) then I could automagically create an open type
> for it.
> This would give the same behaviour as the previous case but spare you the
> need to provide the .xsd
>
> I'm inclined to just go ahead and do that since its not obviously any
> worse
> than the current behaviour but I'm open to other ideas.
>
Yes, that's the behavior I was expecting in the first place. This will
give us consistent behavior for top level and nested elements with
unknown types, they just turn into OpenDataObjects.
> Regards,
>
> Geoff.
>
> On 07/09/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> Well, I can load it, but it's desperately empty :)
>>
>> Given the following XML:
>> <customer><firstName>Jane</firstName><lastName>Doe</lastName></customer>
>>
>> I have no XSD for this document, and don't want to have one or have to
>> define specific SDO types for it. I just want to load this XML into an
>> SDO DataObject.
>>
>> XMLDocumentPtr doc = XMLHelper::load(xml);
>> gives me an XMLDocumentPtr with no root DataObject.
>>
>> char* xml = XMLHelper::save(doc);
>> gives me this:
>> <?xml version="1.0" encoding="UTF-8"?>
>>
>> Is this supported by our SDO/C++ implementation? or is it a bug?
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org