[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Proposal 01 for Issue 54
Eric, Here are my comments on proposal 02: 1. The order of the steps in section 2.1 should be a MUST. How the resulting URI relates to the runtime endpoint should be a SHOULD. 2. (editorial) change sub-items under point 1 for service to bullets, as they are not order-dependent. 3. Do we need "absolute URI" in point 2 for service? The corresponding wording for reference just says "URI". 4. (editorial) change sub-items under point 3 for service to top-level items, to align with the corresponding items in the reference section. 5. In sub-point 1 of point 3 for service, what happens if all the port elements are not consistent with runtime policies and constraints? I think this SHOULD (or MUST) cause an error to be raised. 6. In sub-point 2 of point 3 for service, what happens if the port element is not consistent with runtime policies and constraints? I think this SHOULD (or MUST) cause an error to be raised. 7. Split point 5 for reference into two points: one if the reference is wired, and another if it isn't (Mike's "intent" case). Simon Eric Johnson wrote: > Hi Anish, > > Anish Karmarkar wrote: >> 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. > I updated the wording on the (for service) section. >> >> 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. > We do have precisely the constraint you state here that we don't have: > "When this element is present along with the @wsdlElement attribute on > the parent element, the @wsdlElement attribute value MUST be of the > ‘Binding’ form as specified above" >> 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". > Wow. The insanity. How about we leave it undefined? >> >> 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? > Is it an error if you have <binding.ws /> but no target specified? If > you haven't specified a target, then you can wire this at deployment. >> >> 4) A very minor editorial comment. It would nice if the algorithms for >> service and ref were structured (wrt bullets) similarly. > I'm not sure what you mean by this. Perhaps we can discuss during the > call. At a guess, I moved the last "otherwise" into a fifth bullet point. > > Revised version attached. > > >> >> -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 > > ------------------------------------------------------------------------ > > --------------------------------------------------------------------- > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]