Hi Sebastian,
I forgot to mention a weird issue I found when I making attempts. Here
is the generated schema again:
<xs:schema xmlns:sdo="commonj.sdo" xmlns:sdoJava="commonj.sdo/java"
xmlns:stn_1="http://example.com/IPO"; <http://example.com/IPO>
xmlns:xs="http://www.w3.org/2001/XMLSchema";
<http://www.w3.org/2001/XMLSchema>
attributeFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="http://example.com/IPO"; <http://example.com/IPO>>
*<xs:complexType abstract="false" name="PurchaseOrder">*
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="items"/>
</xs:sequence>
<xs:attribute name="shipTo" type="xs:string"/>
<xs:attribute name="billTo" type="xs:string"/>
</xs:complexType>
*<xs:element name="purchaseOrder" type="stn_1:PurchaseOrder"/>*
</xs:schema>
As we can see, the generated schema in accordance with a pattern. A
pattern that defines a complexType with the name supplied in code first,
and then defines an element with a bit different name from the
complexType. The initial of the elment's name is lowercase. The naming
rulecause DataObject instantiation incosistency. Here is the code
snippet about instantiation incosistency:
HelperContext helperContext = SDOUtil.createHelperContext();
DataFactory df = helperContext.getDataFactory();
String uri = "http://example.com/IPO";;
String typeName = "PurchaseOrder";
String typeNameLowercaseIntial = "purchaseOrder";
//create type
DataObject typeDef = df.create("commonj.sdo", "Type");
typeDef.set("uri", uri);
typeDef.set("name", typeName);
//add first property
DataObject propDef = typeDef.createDataObject("property");
propDef.set("name", "shipTo");
propDef.set("type",
helperContext.getTypeHelper().getType("commonj.sdo", "String"));
//add second property
propDef = typeDef.createDataObject("property");
propDef.set("name", "billTo");
propDef.set("type",
helperContext.getTypeHelper().getType("commonj.sdo", "String"));
//add third property
propDef = typeDef.createDataObject("property");
propDef.set("name", "items");
propDef.set("type",
helperContext.getTypeHelper().getType("commonj.sdo", "String"));
propDef.set("many", true);
//define type and generate xsd
Type type = helperContext.getTypeHelper().define(typeDef);
List types = new ArrayList<Type>();
types.add(type);
System.out.println(helperContext.getXSDHelper().generate(types));
//it's *OK* to instantiate DataObject in this way
DataObject obj2 = df.create(uri, typeName);
//*NOT OK*
DataObject obj1 = df.create(uri, typeNameLowercaseIntial);
//*OK*
String datastrLowercase =""
+ "<"+typeNameLowercaseIntial+"
xmlns=\"http://example.com/IPO\";>"
+ " <shipTo>Beijing</shipTo>"
+ " <billTo>Shanghai</billTo>"
+ " <items>one</items><items>two</items>"
+ "</"+typeNameLowercaseIntial+">";
DataObject dataobj1 =
helperContext.getXMLHelper().load(datastrLowercase).getRootObject();
//*NOT OK*
String datastr =""
+ "<"+typeName+" xmlns=\"http://example.com/IPO\";>"
+ " <shipTo>Beijing</shipTo>"
+ " <billTo>Shanghai</billTo>"
+ " <items>one</items><items>two</items>"
+ "</"+typeName+">";
DataObject dataobj2 =
helperContext.getXMLHelper().load(datastr).getRootObject();
The snippet presents four ways to instantiate the DataObject, two ways
OK, two ways NOT. That is the incosistency.
Best,
Grovecai
At 2013/5/15 9:34, grovecai wrote:
Hi Sebastian,
I don't have any special solution, but I did make some attempts. I
instantiate two DataObjects with type of "PurchaseOrder" from the two
schema mentioned before, one for each. When using the getter and
setter accessories to access the DataObjects, I found they are
compatible. Thus, it satisfies my requirement, I don't need to stuck
at mapping to early xml schema.
Best,
Grovecai
At 2013/5/14 19:38, Millies, Sebastian wrote:
Hi grovecai,
Here's another quote from section "9.7 XSD Mapping Details":
"Model Groups (sequence, all, choice, group) do not contribute to the
mapping
except for maxOccurs>1 results in Properties with many=true"
I'd be interested to know what your solution looks like now. Can you
share?
The disappearance of the type attribute is mysterious. In section
"9.4 Mapping of XSD Built in Data Types" the spec says:
"If the XSD type of the instance value cannot be determined, or the
SDO Type's instance class is java.lang.Object or null,
the value is read as a String." So this could perhaps be a bug.
Best,
Sebastian
*From:*grovecai [mailto:grove...@gmail.com]
*Sent:* Tuesday, May 14, 2013 10:10 AM
*To:* user@tuscany.apache.org
*Subject:* Re: About dynamically create Type mapping to xml schema
Hi Sebastian,
Thank you for your reply.
I know how it works now. Have you notice that the /element "items"/in
the schema generated by my code lost its/type attribute/. Is this a bug?
Best,
Grovecai
At 2013/5/14 14:58, Millies, Sebastian wrote:
Hello grovecai,
XSD sequences are model groups that may be flattened in the
resulting SDO model.
Look at section "9.3.2 Mapping of XSD Elements" of the SDO 2.1.0
spec. It says:
Element in all, choice, or sequence
<[GROUP] maxOccurs=[G_MAX]>
<element name=[NAME]
type=[TYPE]
maxOccurs=[E_MAX] />
</[GROUP] >
where
[GROUP] = all, choice, sequence
. Element groups and model
groups are treated as if they
were expanded in place.
. A property is created for every element
many=true when E_MAX or G_MAX
is > 1
So I believe the result you're getting is in accordance with the
SDO spec, at least that's how
I read the spec.
Best,
Sebastian
*From:*grovecai [mailto:grove...@gmail.com]
*Sent:* Tuesday, May 14, 2013 5:09 AM
*To:* user@tuscany.apache.org <mailto:user@tuscany.apache.org>
*Subject:* About dynamically create Type mapping to xml schema
Hi, guys
I need to dynamically create type mapping to the below schema:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";
<http://www.w3.org/2001/XMLSchema>
xmlns="http://example.com/IPO"; <http://example.com/IPO>
targetNamespace="http://example.com/IPO"; <http://example.com/IPO>>
<xsd:element name="purchaseOrder" type="PurchaseOrder"/>
<xsd:complexType name="PurchaseOrder">
<xsd:sequence>
<xsd:element name="shipTo" type="xsd:string"
minOccurs="0"/>
<xsd:element name="billTo" type="xsd:string"
minOccurs="0"/>
<xsd:element name="items" type="xsd:string"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
Here is my code:
HelperContext helperContext = SDOUtil.createHelperContext();
DataFactory df = helperContext.getDataFactory();
DataObject typeDef = df.create("commonj.sdo", "Type");
typeDef.set("uri", "http://example.com/IPO";
<http://example.com/IPO>);
typeDef.set("name", "PurchaseOrder");
DataObject propDef = typeDef.createDataObject("property");
propDef.set("name", "shipTo");
propDef.set("type",
helperContext.getTypeHelper().getType("commonj.sdo", "String"));
propDef = typeDef.createDataObject("property");
propDef.set("name", "billTo");
propDef.set("type",
helperContext.getTypeHelper().getType("commonj.sdo", "String"));
propDef = typeDef.createDataObject("property");
propDef.set("name", "items");
propDef.set("type",
helperContext.getTypeHelper().getType("commonj.sdo", "String"));
propDef.set("many", true);
Type type = helperContext.getTypeHelper().define(typeDef);
List types = new ArrayList<Type>();
types.add(type);
System.out.println(helperContext.getXSDHelper().generate(types));
The created type actually map to the below schema:
<xs:schema xmlns:sdo="commonj.sdo" xmlns:sdoJava="commonj.sdo/java"
xmlns:stn_1="http://example.com/IPO"; <http://example.com/IPO>
xmlns:xs="http://www.w3.org/2001/XMLSchema";
<http://www.w3.org/2001/XMLSchema>
attributeFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="http://example.com/IPO"; <http://example.com/IPO>>
<xs:complexType abstract="false" name="PurchaseOrder">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="items"/>
</xs:sequence>
<xs:attribute name="shipTo" type="xs:string"/>
<xs:attribute name="billTo" type="xs:string"/>
</xs:complexType>
<xs:element name="purchaseOrder" type="stn_1:PurchaseOrder"/>
</xs:schema>
What did I missed? I want "shipTo" and "billTo" to be elements
contained in sequence, not as attribute contained directly in
complexType. Any hint may be helpful. Thank you!
Regards,
Grovecai
Software AG -- Sitz/Registered office: Uhlandstraße 12, 64297
Darmstadt, Germany -- Registergericht/Commercial register:
Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz
Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd
Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the
Supervisory Board: Dr. Andreas Bereczky - *http://www.softwareag.com*
