I think that both load() and save() should demand-create the global
property if necessary. I would suggest that we wait until we get all the
SDO 2.1 open content properties support working, and then we can fix this
using it.
Frank.
Fuhwei Lwo <[EMAIL PROTECTED]> wrote on 09/27/2006 11:43:00 AM:
> Hi Kelvin,
>
> Based on your experiment, that means XMLHelper.save() did not
> automatically add the "fred" as a new global element to the type
> registry. That's why it cannot be recognized during loading.
>
> In this case, I suggest XMLHelper.save() throws an exception to
> indicate "fred" is not a defined global property. What do you think?
>
> Fuhwei
>
> kelvin goodson <[EMAIL PROTECTED]> wrote: Hi Fuhwei,
> sorry to take so long to get this, but I needed to experiment. I've
been
> adapting XSDHelperTestCase to see what we have, and I think that with
the
> current state of the implementation for your scenario a regeneration of
the
> XSD after a save would not help in being able to load the saved XML
> document. Here's some code to show the point ...
>
> some basic Type creation stuff taken directly frorm the test case ...
> =====
>
> TypeHelper typeHelper = SDOUtil.createTypeHelper();
> XSDHelper xsdHelper = SDOUtil.createXSDHelper(typeHelper);
> DataObject quoteType = DataFactory.INSTANCE.create("commonj.sdo",
> "Type");
> quoteType.set("uri", " http://www.example.com/dynamic";);
> quoteType.set("name", "DynamicQuote");
>
> DataObject aProperty = quoteType.createDataObject("property");
> aProperty.set("name", "symbol");
> aProperty.set("type", TypeHelper.INSTANCE.getType("commonj.sdo",
> "String"));
>
> aProperty = quoteType.createDataObject("property");
> aProperty.set("name", "price");
> aProperty.set("type", TypeHelper.INSTANCE.getType ("commonj.sdo",
> "Decimal"));
>
> aProperty = quoteType.createDataObject("property");
> aProperty.set("name", "volume");
> aProperty.set("type", TypeHelper.INSTANCE.getType("commonj.sdo",
> "Double"));
>
> typeHelper.define (quoteType);
>
> String xsd = xsdHelper.generate(types);
> System.out.println(xsd);
> =====
>
> for which the output is ...
>
> /////////////////////////////////
>
> elementFormDefault="qualified" targetNamespace="
> http://www.example.com/dynamic";>
>
>
>
>
>
>
>
>
> /////////////////////////////////
> so we see our one type, but in the serialized schema there is a global
> property with name derived from the Type.
> So lets see if we can find that global property ...
> ==========
> Property autoGlobal = xsdHelper.getGlobalProperty("
> http://www.example.com/dynamic";, "dynamicQuote", true);
> assertNull(autoGlobal);
> ==========
> the assertions in this code and all that follows have been coded to make
the
> test pass, i.e. they represent ground truth with the implementation. We
> may want to question whether these should be as they are. So you can
see
> here that the implicit "dynamicQuote" global element is not available to
the
> program.
>
> So now lets create an instance and serialize it with a document root
element
> name other than dynamicQuote
> ===========
> DataObject dynQuote = df.create(typeHelper.getType ("
> http://www.example.com/dynamic";, "DynamicQuote"));
> dynQuote.setString("symbol", "fbnt");
>
> XMLHelper xmlHelper = SDOUtil.createXMLHelper(typeHelper);
> xmlHelper.save(dynQuote, "http://www.example.com/dynamic";, "fred",
> System.out);
> ===========
> this works fine ...
> /////////////////////////
>
>
> xmlns:dynamic=" http://www.example.com/dynamic";
> xsi:type="dynamic:DynamicQuote"
> symbol="fbnt"/>
> /////////////////////////
> but note that you can't read this back, even in the same program, and
if
> you were to regenerate the schema after the use of the "fred" global
> element, it would be exactly as we saw before, with the one global
element
> "dynamicQuote".
> ===========
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> xmlHelper.save(dynQuote, "http://www.example.com/dynamic";, "fred",
> baos);
> ByteArrayInputStream bais = new
ByteArrayInputStream(baos.toByteArray
> ());
> try {
> xmlHelper.load(bais);
> assertFalse(true);
> }
> catch (Exception e) {
> // expected path
> }
> ==========
> So the load operation fails to recognise the type of the global element
> "fred"
>
> In fact the same failure occurs if you use "dynamicQuote" for the global
> element name. The only advantage would be if you had taken the
generated
> XSD and used it as input to XSDHelper.define then using "dynamicQuote"
as
> the global element name for the instance document creation would have
> created a document that could be loaded, whereas using "fred" would not.
>
> I can't see a way that you can influence the global elements of the
> generated XSD, not even with our tuscany specific extensions of
> SDOUtil.createType() and SDOUtil.createProperty(). These methods
provide
> for creating a type in a namespace with a null name, which is considered
to
> be a place to collect global properties. I experimented with creating a
> global property in this way, then regenerating the XSD by retrieving the
> full set of types by passing in SDOUtil.getTypes(), but my
> global properties did not appear in the generated XSD. I guess this is
to
> be expected, since that would probably be a violation of the spec.
>
> So the upshot I think is that you are restricted to using a global
element
> name derived from the Type name when saving an instance document, or to
> tweaking the XSD to match the name you used.
>
> Regards, Kelvin.
>
> On 22/09/06, Fuhwei Lwo < [EMAIL PROTECTED] > wrote:
> >
> > Concerned API: XMLHelper.save(DataObject dataObject, String
> > rootElementURI, String rootElementName, OutputStream outputStream)
> >
> > My observation is the current implementation of this method
> > would automatically add the rootElementName to the namespace if it
does
> > not exist and serialize the new global element. The problem with
> > this approach is that the users may not be aware they need to
generate
> > and use the new XSD to load the document they just serialized
> > otherwise loading would fail.
> >
> > I am questioning whether this implicit add is necessary. Is there
any
> > benefit by doing that? Thanks.
> >
> > Sincerely,
> >
> > Fuhwei Lwo
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
