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}
and
physicalType: OMElement.class
logicalType: QName{http://example.com, order}
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?
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.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
