Re: [wsrm] Full agenda for WSRM TC teleconf 8/3/04

[Doug Bunting <Doug.Bunting@Sun.COM>]

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 ---