1) In section 3.1, bullet 3.1 (for service) says:
"... and references a wsdl:service element, then use the URI indicated
by each contained wsdl:port element"
In section 3.1, bullet 3 (for reference) says:
"If the @wsdlElement attribute is present and references a wsdl:service
element, use the URI indicated by any contained wsdl:port element that
satisfies runtime policies and constraints"
Any particular reason runtime policy and constraints are important for
reference but not for service?
We also say in the explanation of @wsdlElement that only those ports in
the WSDL service element that have equivalent portType are made available.
2) We don't require that when endpointReference and @wsdlElement are
both used the wsdlElement MUST reference only a WSDL binding. If this is
true when @URI is specified, it should be true for endpointReference as
well. Both are a way to specify uris.
As a side, an EPR can contain WSDL metadata. What happens if the EPR
points to a WSDL binding in its metadata section. Can it be different
from the one pointed to by @wsdlElement? I would like to suggest that it
be a "compatible super/subset".
3) For reference (in bullet 5) it says:
"Otherwise, the URI for the reference is determined by the binding it is
wired to, or by deployment"
Isn't it always determined by the binding it is wired to?
4) A very minor editorial comment. It would nice if the algorithms for
service and ref were structured (wrt bullets) similarly.
-Anish
--
Eric Johnson wrote:
> Attached as revisions to CD02.
>
> I did my best to capture many of the points raised in the calls in which
> we talked about this, but I suspect I missed something.
>
> If you review before next call, and have comments, I'll do my best to
> integrate those comments before then.
>
> Please excuse the fact that OpenOffice completely mangled the table of
> contents. If you don't update the TOC before saving, it sometimes gets
> confused. No changes intended there.
>
> -Eric.
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
