OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Re: Issue 34 - some schema followup


Alex,

Yup it is clear now and no issue from me on the optionality of the @. Thanks Ron from me as well.

Alex, I suggest that we drop the use of the term 'address container' here and perhaps use something like 'reference-container' (?), when we incorporate this in the spec (I know you have the action). I suggest that, as you very well would know an EPR can contain many other things besides the EP address. Also can we change the tag name to service-reference (ref spelled out)?

Regards, Prasad

-------- Original Message --------
Subject: Re: [wsbpel] Re: Issue 34 - some schema followup
Date: Wed, 14 Jul 2004 19:35:03 -0700
From: Alex Yiu <alex.yiu@oracle.com>
To: Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>
CC: Prasad Yendluri <pyendluri@webmethods.com>, wsbpel@lists.oasis-open.org, Alex Yiu <alex.yiu@oracle.com>

Thanks Ron for providing example.

Let me try to supplement more info here (hopefully it will not confuse more):
(1) Yes, the <service-ref> element is an address container. And, the child EII of the <service-ref> in the Ron's example is the <wsa:Address> element.

(2) When the interpretation of the child EII is un-ambigous, the reference-scheme attribute at the <service-ref> container can be dropped. Continue using the same example:

------------------------
<process xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
    ....
    <service-ref><wsa:Address>http://mycompany.com/blah</wsa:Address></service-ref>
</process>
------------------------

Prasad, I hope emails from Ron and me answer your questions.
Thanks!


Regards,
Alex Yiu


Ron Ten-Hove wrote:
Your WS-Addressing example would look like this:

<service-ref reference-scheme="http://schemas.xmlsoap.org/ws/2004/03/addressing">
    <wsa:Address>http:://mycomany.com/blah</wsa:Address>
</service-ref>

The <service-ref> element functions as an addressing container. Obviously we need to be more explicit when introducing a new term.

-Ron
Prasad Yendluri wrote:
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 --------
Subject: Re: [wsbpel] Re: Issue 34 - some schema followup
Date: Wed, 14 Jul 2004 12:57:09 -0700
From: Alex Yiu <alex.yiu@oracle.com>
To: Prasad Yendluri <pyendluri@webmethods.com>
CC: Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>, wsbpel@lists.oasis-open.org, ygoland@bea.com, Satish Thatte <satisht@microsoft.com>, Martin Chapman <martin.chapman@oracle.com>, "Monica J. Martin" <Monica.Martin@Sun.COM>, Francisco Curbera <curbera@us.ibm.com>, Alex Yiu <alex.yiu@oracle.com>

 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 --------
Subject: Re: [wsbpel] Re: Issue 34 - some schema followup
Date: Wed, 30 Jun 2004 12:01:07 -0700
From: Alex Yiu <alex.yiu@oracle.com>
To: Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>, wsbpel@lists.oasis-open.org
CC: ygoland@bea.com, Satish Thatte <satisht@microsoft.com>, Martin Chapman <martin.chapman@oracle.com>, "Monica J. Martin" <Monica.Martin@Sun.COM>, Francisco Curbera <curbera@us.ibm.com>, Alex Yiu <alex.yiu@oracle.com>
References: <D78C42C1ADD5CF41AE3B60B03C39D1CD024E28F0@RED-MSG-52.redmond.corp.microsoft.com> <40D75D20.4060403@bea.com> <40D7991C.80101@sun.com>

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]