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 ...
/////////////////////////////////
<xs:schema xmlns:xs=" http://www.w3.org/2001/XMLSchema"; xmlns:sdo="
commonj.sdo" xmlns:sdoJava="commonj.sdo/java" xmlns:stn_1="
http://www.example.com/dynamic"; attributeFormDefault="qualified"
elementFormDefault="qualified" targetNamespace="
http://www.example.com/dynamic";>
<xs:complexType abstract="false" name="DynamicQuote">
<xs:sequence/>
<xs:attribute name="symbol" type="xs:string"/>
<xs:attribute name="price" type="xs:decimal"/>
<xs:attribute default="0.0" name="volume" type="xs:double"/>
</xs:complexType>
<xs:element name="dynamicQuote" type="stn_1:DynamicQuote"/>
</xs:schema>
/////////////////////////////////
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 ...
/////////////////////////
<?xml version="1.0" encoding="ASCII"?>
<dynamic:fred xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
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(<namespace_uri>), 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
