Re: [C++] SDO can't load an XML doc with no namespace
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 [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/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] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/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]
Re: [C++] SDO can't load an XML doc with no namespace
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: customerfirstNameJane/firstNamelastNameDoe/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
Re: [C++] SDO can't load an XML doc with no namespace
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: customerfirstNameJane/firstNamelastNameDoe/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
Re: [C++] SDO can't load an XML doc with no namespace
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: customerfirstNameJane/firstNamelastNameDoe/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
Re: [C++] SDO can't load an XML doc with no namespace
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: customerfirstNameJane/firstNamelastNameDoe/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
Re: [C++] SDO can't load an XML doc with no namespace
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: customerfirstNameJane/firstNamelastNameDoe/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
Re: [C++] SDO can't load an XML doc with no namespace
On 10/9/06, Pete Robbins [EMAIL PROTECTED] 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 [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: customerfirstNameJane/firstNamelastNameDoe/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 =
Re: [C++] SDO can't load an XML doc with no namespace
We'd be interested to make use of this feature in the PHP SDO project, too. 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] SDO can't load an XML doc with no namespace
I won't be able to do anything about this until the week after next at the earliest (ie early October) - but even then I have other commitments. I'll try to find some time to look at it then. Regards, Geoff. On 21/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Geoffrey Winn wrote: I spoke to Ed about this and it seems that when there is no type information available, the XML parser makes a series of assumptions about the structure of the incoming data (for example all elements are assumed to be repeating). Of course, these assumptions are not always correct. It also means that, for example, things that you think of as single valued or simple can be represented as multi-valued or by a data object. The implementation _is_ flawed but it shouldn't be as bad as your example suggests. So yes it is a bug, although even when fixed it may not give quite what you want/expect. On 07/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/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] Do you guys have any update on this one? What would it take to fix it? As Simon said earlier in this thread, getting open content to work would be really handy for script based applications where interfaces and operations are not always known in advance. Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] SDO can't load an XML doc with no namespace
On 9/21/06, Geoffrey Winn [EMAIL PROTECTED] wrote: I won't be able to do anything about this until the week after next at the earliest (ie early October) - but even then I have other commitments. I'll try to find some time to look at it then. Regards, Geoff. On 21/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Geoffrey Winn wrote: I spoke to Ed about this and it seems that when there is no type information available, the XML parser makes a series of assumptions about the structure of the incoming data (for example all elements are assumed to be repeating). Of course, these assumptions are not always correct. It also means that, for example, things that you think of as single valued or simple can be represented as multi-valued or by a data object. The implementation _is_ flawed but it shouldn't be as bad as your example suggests. So yes it is a bug, although even when fixed it may not give quite what you want/expect. On 07/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/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] Do you guys have any update on this one? What would it take to fix it? As Simon said earlier in this thread, getting open content to work would be really handy for script based applications where interfaces and operations are not always known in advance. Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I forgot to come back on this one. Sorry about that. What I found was confirmed by Geoff so I cheated to get round it. For a sample I needed to do (Implementing a simple JSON DAS) I defined a single type in the model that had open content and then read in each element in the JSON tree in turn giving it this type in order to create an SDO. I didn't try reading in an XML file using this approach but it would be interesting to see if you can make it work somehow. Of course you end up with an SDO with no useful type information but for my purposes that was OK. I have to get on a train in a bit so I'll give it a go S
Re: [C++] SDO can't load an XML doc with no namespace
On 9/7/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/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] We don't have support for schema free loads in PHP SDO which is based directly on C++ SDO and I have assumed to date that that was because C++ SDO doesn't support it. I may be wrong and if C++ SDO does support it it would be really handy for us so I'll see if I can find out.
Re: [C++] SDO can't load an XML doc with no namespace
I spoke to Ed about this and it seems that when there is no type information available, the XML parser makes a series of assumptions about the structure of the incoming data (for example all elements are assumed to be repeating). Of course, these assumptions are not always correct. It also means that, for example, things that you think of as single valued or simple can be represented as multi-valued or by a data object. The implementation _is_ flawed but it shouldn't be as bad as your example suggests. So yes it is a bug, although even when fixed it may not give quite what you want/expect. On 07/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/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]
[C++] SDO can't load an XML doc with no namespace
Well, I can load it, but it's desperately empty :) Given the following XML: customerfirstNameJane/firstNamelastNameDoe/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]
