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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrf message

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


Subject: RE: [wsrf] Groups - DerivedFrom portType extension.doc uploaded






-1 to the "complied-to" transitive closure

The process you describe for a consumer determining the transitive closure
of portTypes/interfaces
is exactly the process that would be used in WSDL2.0.  Further, it is not
at all clear that every consumer
would need to do this; I can envision "registries" that would expose the
transitive closure of a
portType's  "derivedFrom" attribute.  Additionally, I can think of no
programming model paradigm that
uses such a "non-normalized" view of  "derivation" or "extension" in the
language itself.  In essence you
are arguing for a restricted model that only allows for a 2 level
hierarchy.  I can think of no architectural
premise for such a restriction.

For me the question is what would become of the "derivedFrom" attribute in
a WSDL2.0 component
model?

Tom


"Vambenepe, William N" <vbp@hp.com> wrote on 09/22/2004 08:12:34 PM:

>
> Hi Steve,
>
> Why not put in the "derivedFrom" attribute the Qnames of all the
> portTypes with which this portType is compliant (i.e. the content of the
> {extendedPortType} property that you define as the transitive closure of
> all portTypes with which this portType is compliant).
>
> For example, if my program is written to know what to do with
> implementations of the portType foo:bar, with your current proposal I
> Can't just look at the Qname of a portType and at the Qnames in its
> "derivedFrom" attribute to know whether or not I can invoke the service.
> I need to retrieve the portType definition for each of the portTypes in
> the "derivedFrom" attribute and recursively introspect what is in their
> "derivedFrom" until I put together a list of "atomic" portTypes (those
> that don't derive from anything). And this is true for every consumer.
> We can simplify this task a lot by providing a complete list of
> "complied-to" portTypes in "derivedFrom".
>
> Regards,
>
> William
>
>
> -----Original Message-----
> From: sggraham@us.ibm.com [mailto:sggraham@us.ibm.com]
> Sent: Tuesday, September 07, 2004 7:16 AM
> To: wsrf@lists.oasis-open.org
> Subject: [wsrf] Groups - DerivedFrom portType extension.doc uploaded
>
> The document DerivedFrom portType extension.doc has been submitted by
> Stephen Graham (sggraham@us.ibm.com) to the OASIS Web Services Resource
> Framework TC document repository.
>
> Document Description:
> Per Action Item I took on Aug 23 telecon, this document is a proposed
> resolution to issue WSRF1.
>
> Download Document:
> http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/9079/Deri
> vedFrom%20portType%20extension.doc
>
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/wsrf/document.php?document_
> id=9079
>
>
> PLEASE NOTE:  If the above links do not work for you, your email
> application may be breaking the link into two pieces.  You may be able
> to copy and paste the entire link address into the address field of your
> web browser.
>
>



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