[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Full agenda for WSRM TC teleconf 8/3/04
Tom, We generally need an "AOB" item on the agenda ;) I am not sure if this is any other business or should be handled as 5.5 but, with apologies to Iwasa (who said he would not be connected again until this call), I attach an off-list thread about a couple of relatively minor inconsistencies between the specification and the core schema. The main questions for TC consideration are: 1. What to do about InvalidMessageHeader, which appears in the schema but not the specification? 2. What name should we use for the fault called NotSupportedFeature in the schema (matching a few issue resolutions) and NonSupportedFeature in the specification (possibly a typographic error)? From my perspective, I do not understand (1) and would appreciate someone posting or explaining during the call why this was removed from the specification in the first place. I guess InvalidRequest and InvalidPollRequest cover every invalid message header in WS-Reliability that might result in an RM Fault (since the Response element has no associated faults)... On (2), I lean toward going with NotSupportedFeature as I see no earlier discussion about changing its name since that was chosen. If we do need a new name for some reason, my favourite would be FeatureNotSupported. thanx, doug On 03-Aug-04 12:39, Tom Rutt wrote: > The full agenda with links to email and documents for discussion is > attached. > > Tom Rutt > WSRM TC Chair
--- Begin Message ---
- From: Doug Bunting <Doug.Bunting@Sun.COM>
- To: iwasa <kiwasa@jp.fujitsu.com>
- Date: Tue, 03 Aug 2004 10:54:25 -0700
Iwasa, Thank you for a detailed check of the issues here. I have a couple of questions for this group and a few suggestions. 1. I just checked and see no issue which mentions the InvalidMessageHeader fault. Why was it removed from the specification? Should it be replaced rather than following through with the removal in the schema? 2. Our issues about *SupportedFeature make no mention of "NonSupportedFeature" but do change the name (from notSupportedFeature to NotSupportedFeature. The specification seems to be in error. I see no reason to change the name again and recommend changing the specification rather than the schema. Actually, my naming preference would have been "Not..." anyhow though "Un..." might be a bit better and "FeatureNotSupported" even better ;) 3. We need 4 globally declared (top level w.r.t. the schema) elements and ReplyTo is not among them. I would agree with limiting the initial list to the 3 header elements and declaring the ReplyTo element locally within PollRequestType and ReplyPatternType. This requires a bit more than 'add type="ref:ServiceRefType"' since 'ref="wsrm:ReplyTo"' should be 'name="ReplyTo" if we make this change. The fourth element which must be global is BareURI. I wonder a bit about highlighting its xsd:element. Thoughts? 4. The points on 1 and 2 above should probably be discussed in the group at large. Since Iwasa found the issues and should clearly be given credit though he may presently be disconnected, I could forward his original email. If someone from Fujitsu could do that first, even better. Please. thanx, doug On 03-Aug-04 01:23, iwasa wrote: > Here are three proposed changes to the schema. > > I did review to find inconsistencies between > schema and spec in terms of: > - element name > - attribute name > - fault name > And I have found the following two inconsistencies: > 1) Schema has "InvalidMessageHeader" fault, > but the spec has removed it to resolve some issue. > 2) Schema uses "NotSupportedFeature" for some fault, > but the spec uses "NonSupportedFeature" for it. > The spec uses the terminology three times, but > all of them uses "NonSupportedFeature". > > Proposed resolution: > 1) Remove the "InvalidMessageHeader" fault from a schema. > 2) Replace "NotSupportedFeature" fault with > "NonSupportedFeature" fault in the schema. > > For proposed resolution for 2) above, I do not have strong > opinion. So if we like to replace the terminology in spec, > that is also fine with me. > > And I have one question to the schema. > There are four elements listed in the portion > of " <!-- 4WSRM Headers-- >" as follows: > > <!-- 4WSRM Headers --> > <xsd:element name="Request" type="wsrm:RequestType"/> > <xsd:element name="Response" type="wsrm:ResponseType"/> > <xsd:element name="PollRequest" type="wsrm:PollRequestType"/> > <xsd:element name="ReplyTo" type="ref:ServiceRefType"/> > > However it looks like to me it is not appropriate to list > "ReplyTo" element here, since we have only three child > elements under soap:Header elements as follows: > - wsrm:Request > - wsrm:PollRequest > - wsrm:Response > > Should we remove the "ReplyTo" element from here? > If we do so, should we add: > type="ref:ServiceRefType" > to the ReplyTo element in the following two portion? > > -- > <xsd:complexType name="ReplyPatternType"> > <xsd:sequence> > <xsd:element name="Value" type="wsrm:ReplyPatterTypeValues"/> > <xsd:element ref="wsrm:ReplyTo" minOccurs="0"/> > </xsd:sequence> > </xsd:complexType> > -- > and > -- > <!-- Poll Request Header Type --> > <xsd:complexType name="PollRequestType"> > <xsd:complexContent> > <xsd:extension base="wsrm:HeaderBaseType"> > <xsd:sequence> > <xsd:element name="RefToMessageIds" type="wsrm:RefToMessageIdsType" > maxOccurs="unbounded"/> > <xsd:element ref="wsrm:ReplyTo" minOccurs="0"/> > </xsd:sequence> > </xsd:extension> > </xsd:complexContent> > </xsd:complexType> > -- > > In other word, replace > <xsd:element ref="wsrm:ReplyTo" minOccurs="0"/> > > with > <xsd:element ref="wsrm:ReplyTo" type="ref:ServiceRefType" > minOccurs="0"/> > in the above two portions. > > > Since I won't be able to check the e-mail > before telecon tomorrow, please free to > post appropriate comments to the mailing > list regarding this comments, if you believe > it is appropriate to do so. > > I still do not believe this makes our spec > being made substantial change. > These are minor editorial fix to resolve > inconsistencies between schema and the spec. > > Thanks, > > Iwasa > > ----- Original Message ----- > From: "Doug Bunting" <Doug.Bunting@sun.com> > To: "Iwasa" <kiwasa@jp.fujitsu.com>; "Tom Rutt" <tom@coastin.com>; "Mark > Peel" <mpeel@novell.com>; "Jacques Durand" <JDurand@fsw.fujitsu.com>; "Anish > Karmarkar" <Anish.Karmarkar@oracle.com>; "Sunil Kunisetty" > <Sunil.Kunisetty@oracle.com> > Sent: Thursday, July 29, 2004 2:03 PM > Subject: Schema / Spec inconsistencies > > > >>!! >> >>I do not have time to check all element names against their equivalents in >>the schema. While I am aware of the "reference-scheme" (correct) versus >>"reference-schema" (just removed by another search and replace) issue, >>other discrepancies likely exist. Could someone please check? >> >>The main reason for my call? Is "SequenceNumRange" or >>"SequenceNumberRange" correct? Both are in the specification while only >>the second appears in the schema. >> >>thanx, >>doug >> >> > >--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]