----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, September 07, 2006 11:47 AM
Subject: Re: Update on the databinding integration and open issues for
discussion
On Sep 7, 2006, at 11:26 AM, Raymond Feng wrote:
I propose that we change the Operation model as follows:
Operation
--- name (Name of the operation)
--- inputType (For java, it's a DataType representing the Object [].
For WSDL, it could be a DataType representing the top-level request
element using Axiom or other databindings)
--- outputType (For java, it's a DataType representing the
returnType. For WSDL, it could be a DataType representing the top- level
response element using Axiom or other databindings)
--- faultTypes (A list of DataTypes representing the faults/
exceptions)
OK
DataType
--- databinding
--- phsicalType
--- logicalType
--- properties (A list of DataProperty(s) for the DataType to
represent the visible children)
Why properties? For example, a Java argument list does not have named
parameters (in the source yes but not in the public contract).
Can we just use:
physicaltype: Object[].class
logicalType: Class[]{Customer.class, String.class}
It works for java.
and
physicalType: OMElement.class
logicalType: QName{http://example.com, order}
When we try to populate the OMElement for "order" with Customer and String,
we have to create child OMElements under "order" and the child elements
requires QNames. Where can we get the corresponding child element QNames?
Axiom doesn't provide access to the XSD model and we cannot look them up by
the order QName.
And for WSDL, do we only support single-part messages? If not, the inputType
for WSDL could be Object[] as well.
DataProperty
--- name (QName of the property)
--- type (DataType for the property)
QName only makes sense for XML - what would that be in the Java case?
I was thinking of either dummy names such as {java:interfaceName#methodName,
argX} or null.
For the DataType/DataProperty recursion, we don't have to go too deep.
For example, we may only require a list of properties for the DataType
for the inputType.
There's something fishy here if the properties only apply in certain use
cases.
I agree it's not ideal but it seems to be the gap among IDLs.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
