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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Pete
> > >
> > >
> >
> >
>
>
> --
> Pete
>
>
--
Pete
