Re: [oasis-charter-discuss] Comments on proposed charter for OASIS Web Services Federation

[NISHIMURA Toshihiro <nishimura.toshi@jp.fujitsu.com>]

I fully support Tom's comments, and I have a comment in conjunction
with Tom's Comment 1.

I propose to add following sentense in the section "General Notes on
Scope" and in the paragraph before d) deliverables for clarification:

| Just being a submission to some standardization body does not mean
| it is inside of a standardization process.

---
NISHIMURA Toshihiro (FAMILY Given)
nishimura.toshi@jp.fujitsu.com
STRATEGY AND TECHNOLOGY DIV., SOFTWARE UNIT, FUJITSU LIMITED


At Mon, 02 Apr 2007 14:13:59 -0400,
Tom Rutt wrote:
> Regarding the Proposed charter for OASIS Web Services Federation TC
> http://lists.oasis-open.org/archives/members/200703/msg00018.html
> I have the following comments for discussion.
> 
> 
> Comment 1)
> 
> The text regarding normative references needs to be strengthened in 
> light of recent
> experience within ws-rx, sx and tx TCs on their references to WS-Policy:
> 
> The term "far enough along" is ambiguous and should be replaced with a 
> definitive
> Requirement that normative references only be to fully approved 
> standards or
> Recommendations.
> 
> Proposed Changes:
> 
> In the section "General Notes on Scope": change the following paragraph:
> "
> 
> If any of the above specifications is outside of a standardization 
> process at the time
> this TC moves to ratify its deliverables, or is not far enough along in 
> the standardization
> process, any normative references to it in the TC output will be 
> expressed in an abstract manner,
> and the incarnation will be left at that time as an exercise in 
> interoperability.
> "
> 
> To the following:
> "
> If any of the above specifications is outside of a standardization 
> process at the time this TC moves
> to ratify any CS version of its deliverables, or has not yet progressed 
> to the
> status of full standard or recommendation , any normative references to 
> it in the TC output will be e
> xpressed in an abstract manner, and the incarnation will be left at that 
> time as an exercise in interoperability.
> "
> 
> Along the same lines, the paragraph before d) deliverables should be 
> changed from:
> �
> The TC will not attempt to define functionality duplicating that of any
> normatively referenced specification in the input WS-Federation Version 1.1
> [1]. If the referenced specification is outside of a standardization 
> process at
> the time this TC moves to ratify its deliverables, or is not far along 
> enough
> in the standardization process, any normative references to it in the TC 
> output
> will be expressed in an abstract manner, and the incarnation will be 
> left at
> that time as an exercise in interoperability.
> �
> 
> To the following:
> �
> The TC will not attempt to define functionality duplicating that of any
> normatively referenced specification in the input WS-Federation Version 1.1
> [1]. If the referenced specification is outside of a standardization 
> process at
> the time this TC moves to ratify any CS version of its deliverables,
> or has not yet progressed to the status of full standard or recommendation,
> any normative references to it in the TC output
> will be expressed in an abstract manner, and the incarnation will be 
> left at
> that time as an exercise in interoperability.
> �
> 
> 
> Comment 2) There is no good reason why WS-Federation should not be 
> composable with
> Web services specs approved before WS-Addressing (e.g., WS-Reliability) 
> This may be
> especially in cases of migration toward use of WS-Addressing.
> 
> Proposed Change:
> 
> Add Reference (N) to OASIS Standard WS-Reliability.
> 
> Change first sentence to General Notes on Scope, from:
> �
> The output specifications will uphold the basic principles of other Web
> services specifications of independence and composition and be 
> composable with
> the other specifications in the Web services architecture, such as the
> specifications listed in the References section, numbers 1-18, 24-26.
> �
> 
> To:
> �
> The output specifications will uphold the basic principles of other Web
> services specifications of independence and composition and be 
> composable with
> the other specifications in the Web services architecture, such as the
> specifications listed in the References section, numbers 1-18, N, 24-26.
> �
> 
> Thank you
> 
> Tom Rutt
> Fuijitsu
> 
> -- 
> ----------------------------------------------------
> Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133