Hi, With respect to submitting it as patch for the SDO XSDHelper.generate(Types), yes that is what I plan to do ultimately. Though my objective is to bring in SDO type support into the java2WSDL tool, I wish to be able to abstract this out in a way that it contributes to the SDO XSDHelper and also integrates with the tool. But then, in the generated xsds to not compare well with the ones that I originally used to generate the SDOs. So if I go ahead, then it must be with an assumption that the SDO code gen is going to be fixed or the specs itself is going to be updated. I will probably come up with a set of assumptions and get it validated by the community.
With respect to the mapping of the simple data types, I have been able to manage it as you might observe from the outputs that I have attached in JIRA-120. The same goes with the annotations, I have been able to add annotations with the sdo and sdoJava namespaces as mentioned in the specs. I did not find any 'ecore' qualified annotations in the specs. So I seem to have the mechanisms for xsd generation in place (atleast to some extent). It is now a question of how the SDO metadata is interpretted. Thanks Venkat On 6/23/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, Please see my comments below. Thanks, Raymond ----- Original Message ----- From: "Venkatakrishnan (JIRA)" <tuscany-dev@ws.apache.org> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 21, 2006 7:04 PM Subject: [jira] Updated: (TUSCANY-120) Axis2 WS binding support for entryPoint without pre-existing WSDL > [ http://issues.apache.org/jira/browse/TUSCANY-120?page=all ] > > Venkatakrishnan updated TUSCANY-120: > ------------------------------------ > > Attachment: xsdgen.zip > > Hi, > To address this, I have started with generation of XSDs from static SDOs > for now. If this part is thro, I suppose integrating it with WSDL > generation can be managed. > > Before I go futher I want to do a sanity check over what I have > implemented here on whether it is the right approach, on whether I have > done the right things upto now... hence I am attaching whatever I have > done for inputs / comments from the community. > > Here is what I did ... > - Firstly I have assumed that the user will be able to input the SDO > Factory class and obviously the classnames of the static SDOs for which > xsds are to be generated Ideally, we should be able to figure out the SDO factory from the generated SDO classes. If not, it could be a requirement for the SDO code-gen. > - I followed the specifications the SDO v2.0.1 specs document - section > titled Generation of XSD from SDO Type and Property (Page 107) > - I have implemented for most basic rules specified therein but have quite > some yet to be addressed. Why don't you submit them as patches to SDO XSDHelperImpl? I know there are some grey areas in the spec, for example, all simple XSD types are mapped into commonj.sdo namespace by SDO and a straght code-gen can produce a XSD as follows. <xsd:complexType ecore:instanceClass="org.example.creditscore.doclit.Customer" name="Customer"> <xsd:sequence> <xsd:element name="ssn" type="sdo:String"/> <xsd:element name="firstName" type="sdo:String"/> <xsd:element name="lastName" type="sdo:String"/> </xsd:sequence> </xsd:complexType> How do we deal with SDO annotations here? Do we expect the following one instead? I'm not sure if XSD --> SDO --> XSD roundtrip is supported per SDO spec. <xsd:complexType ecore:instanceClass="org.example.creditscore.doclit.Customer" name="Customer"> <xsd:sequence> <xsd:element name="ssn" type="xsd:String"/> <xsd:element name="firstName" type="xsd:String"/> <xsd:element name="lastName" type="xsd:String"/> </xsd:sequence> </xsd:complexType> > - I have tested with two sets of SDOs 1) that Raymond had attached > previous in this JIRA (CreditReport classes) and 2) SDOs generated using > the Tuscany - XSD2JavaGenerator tool from the sequences.xsd (an xsd that I > picked up from the sdo-tools project) > > Here are my findings with the outputs generated: - > - the outputs generated for the CreditReport sample is ok. > - the outputs generated for sequences.xsd has quite a few discrepencies > when compared with the original one. I'd like to have comments on > whether I have interpretted the specs properly or is it something we must > start fixing with annotations (additional information) appended to the > generated SDOs. > > I have attached my entire eclipse project directory with all relevant > classes and outputs. I have also attached the .classpath and .project > files just in case any of you would like to import this project into your > eclipse IDEs and try. > > Thanks. > >> Axis2 WS binding support for entryPoint without pre-existing WSDL >> ------------------------------------------------------------------ >> >> Key: TUSCANY-120 >> URL: http://issues.apache.org/jira/browse/TUSCANY-120 >> Project: Tuscany >> Type: Bug > >> Components: Java SCA Axis Binding >> Versions: Java-Mx >> Reporter: ant elder >> Assignee: Raymond Feng >> Fix For: Java-Mx >> Attachments: java2wsdl-codegen.zip, xsdgen.zip >> >> Where the entryPoint doesn't use interface.wsdl then the pre-existing >> WSDL document shouldn't be required. Axis2 can generate WSDL at runtime >> based on the service interface so the Axis2 binding can use that to >> support the following: >> <entryPoint name="AccountService"> >> <interface.java >> interface=" org.apache.tuscany.binding.axis2.assembly.tests.bigbank.account.services.account.AccountService "/> >> <binding.ws/> >> <reference>AccountServiceComponent</reference> >> </entryPoint> >> See ML discussion: >> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/[EMAIL PROTECTED] > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: > http://www.atlassian.com/software/jira > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
