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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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

Subject: Re: [wsrp] Groups - wsrp-pfb-ebxml-tn-draft-04.doc uploaded

Thanks Andre for the thorough review and feedback on the ebXML Registry 
TN. My apologies for having been slow in response time.

Here is the consolidated response to both sets of comments you provided. 
Note that any issue you sent that is not mentioned here has been 
addressed just as you had suggested. What is left in this email are 
those issues for which I have followup questions or have a difference of 
opinion from your suggestion.

Please see inline below... Thanks again for the valuable comments.


Andre Kramer wrote:

> Some minor suggestions:
> 118, 147 - we never say WSDL 1.0 (rather than WSDL 2.0). Important as 
> portTypes are about to be renamed (to Interfaces I think).
Not sure what above means. What change are you suggesting?

> 170 - Defined by ... Imports -> consider dropping as this level of 
> detail is too sketchy to add much value.
It seems to me that it is useful to know where to find the WSRP WSDLS 
when we introduce them. I suggest we keep these references. No action 
taken yet. Please advice.

> ~209 - diagram has a box around "Association" that I don't understand.

It is notation used Together UML modeling tool for showing the 
relationship class. Cant change that as it is hardwired in the tool. No 
action taken.

> 289 - " " "

Not sure what above meant. The ebRR specs require all repository items 
MUST have an ExtrinsicObject.

Andre Kramer wrote:

> Further to the 278 below and yesterdays discussion, the abstract 
> model, derived from consensus reached by TC discussion, makes a WSRP 
> producer's service wsdl document authoritative for discovery of 
> protocol addressing information. This is what I interpreted is meant 
> by lines 283 to 292.
> UDDI does not rule out such an approach to web Service discovery. I do 
> not want to revisit all the reasons for this decision but would note 
> that the standards have multiple potentially inconsistent ways of 
> specifying service endpoints.
> Once tools support catches up with the evolving best practices we may 
> want to strengthen our publishing of individual "portTypes" (WSDL 2.0 
> Interfaces?). The WS-I.org best practice only really seeks to prevent 
> potential problems with multiple inconsistent direct publishing of 
> endpoints (i.e. avoid use of hostingRedirector).
> I now see that we may need to move 283-292 up before the general 
> per-port type advice, as well as change the 276-282 MUSTs to MAY.
Changed MUST to MAY. The order is left the same because ServiceBinding 
must be described before SpecificationLink since it is the parent 
(container) of the SpecificationLink.


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