OASIS Charter Submission Discuss

  • 1.  Comments on proposed charter for OASIS Web Services Federation

    Posted 04-02-2007 18:14
    
    
    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
    
    
    
    


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

    Posted 04-03-2007 01:07
    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