Alex,
May be we are not understanding each other very well. Going back to
your original email (this thread), you say:
"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."
In the schema you supply (reproduced below) there is nothing
specifically called addressing container. And you are talking
of QName of the child EII of that container. It is not at all clear to
me what you mean.
<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>
Taking WS-Adressing as an example, say I have a reference like
<wsa:Address>http:://mycomany.com/blah</wsa:Address>. So
the addressing container is <wsa:Address>. It has no child EII
but a content URI. So I don't see the somens:bareURI you describe
there. I am sure you don't mean http URI.
I could minimally use a concrete example.
Regards, Prasad
------- Original Message --------
Hi Prasad,
Sorry for replying your email relatively late.
Regarding to the schema design of the wrapper, I still tend to believe
making the reference-schema attribute optional is a right approach.
Especially, after I re-visiting the design pattern of
XSD/annotation/appInfo pattern.
http://www.w3.org/TR/xmlschema-1/#element-appinfo
<appInfo> also acts as a wrapper of an open model content. It
also has an optional URI-based attribute called "source".
And, peeking into the namespace-URI of a QNAME within the wrapper is
actually quite easy to implement.
I hope I have convinced you here. :-)
Side Issue: Speaking of XSD/annotation pattern, I am thinking out loud
here. We may want to add a similar <documentation> pattern to
BPEL process. After more thinking and discussion, I may file a new
issue for that.
Thanks!
Regards,
Alex Yiu
Prasad Yendluri wrote:
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
|