Hi,
Alex Yiu wrote:
There is
no default addressing scheme intended.
The addressing scheme is derived from the namespace of QName of the
child EII.
The optional reference-schema attribute will be used ONLY when the
QNAME of child EII is ambiguous.
I think this is putting too much of expectation on the level of
knowledge on the BPEL engine / processor.
I certainly hope there would only be one addressing scheme and this
would be a moot issue eventually but,
I am not comfortable with requiring the the BPEL processor / engine to
understand and deduce all possible
addressing schemes based on the QName. Capturing the scheme globally as
a default if the referece-scheme @ is
not specified allowing it to be optional or making it a required would
be the right approach IMO.
Regards, Prasad
E.g. two
different addressing scheme is trying to use wsdl:service as
the child EII as the EPR.
The reference-schema attribute can be provided to remove the ambiguity.
I hope I have answered your question.
Thanks!
Regards,
Alex Yiu
Prasad Yendluri wrote:
Alex,
>I would suggest a change to the schema of the proposal in Issue 34:
making that attribute optional.
>
>If it is clear that the QName of the child EII of the addressing
container (eg , somens:BareURI) will not conflict with any other
addressing >scheme, then the user certainly has the choice of not
using
the 'reference-scheme' attribute.
Did you really mean "any other addressing scheme" above? That
implies to me a there a default (assumed) addressing scheme. If that is
really the case how is that determined? Derived from the QName of the
child EII somehow? Can you clarify?
Thanks, Prasad
------- Original Message --------
Hi, all TC members,
After talking to some more people at Oracle, here is a
clarification on how 'reference-scheme' attribute can be used.
For example, a service reference scheme (e.g. WSMD) uses WSDL 1.1/20
service element as a reference. It is possible that some other
reference scheme (e.g. a future addressing group) may use
wsdl11:service/wsdl20:service element as a reference but in a slightly
different way. In such a case this attribute will be helpful to
disambiguate the scheme and its semantics.
I would suggest a change to the schema of the proposal in Issue 34:
making that attribute optional.
If it is clear that the QName of the child EII of the addressing
container (eg , somens:BareURI) will not conflict with any other
addressing scheme, then the user certainly has the choice of not using
the 'reference-scheme' attribute.
Regarding to the mixed="true" suggestion, making it mixed will require
us to specify what happens if the content is indeed mixed -- i.e. has
both CII and EII. It may unnecessarily complicate the picture.
Defining the new element/type for bare URI just seems simpler.
The schema would look like this after the change:
----------------------------------------------------
<xs:element name="service-ref" type="tns:ServiceRefType" />
<xs:complexType name="ServiceRefType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="1"
maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="reference-scheme" type="xs:anyURI" use="optional"/>
</xs:complexType>
----------------------------------------------------
I hope this make sense to you guys!
Thanks!
Regards,
Alex Yiu
|