OpenCSA Liaison Subcommittee

As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs

I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not.

Sanjay



Original Message-----
From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ]
Sent: Tuesday, August 02, 2011 9:22 AM
To: OASIS Liaison
Subject: [opencsa-liaison] Reference dependencies in various SCA specs

As we all know, specs in all the SCA TCs have dependencies on each
other. For example, Assembly has a normative reference to Policy and
WS-Binding. To conform to Assembly one has to conform to Policy and
WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on
Assembly/Policy. The dependency graph is cyclic.

A similar problem exists in SCA-J TC but without any cycles [1].

OASIS TC process solves this problem of cyclic references by using
designated cross references [2]. Unfortunately, CSDs cannot use this
mechanism as the process explicitly excludes it. So, two specs A and B
that depend on each other, will be in an infinite loop wrt updating
their normative references. Further compounding the problem (but is an
independent issue) is the fact that the new process requires at least
15-days PR for any change (except the changes on the front page). So any
time spec A or B is updated to update its normative reference it has to
be PRed.

I see three possible solutions to this:
1) Fix the process to allow DCRs for CSDs (this is the only long term
solution, I think).
2) Use the solution in [1] where spec A instead of using WDXX reference
of B, uses the CSDYY reference of B. Where CSDYY is the what will happen
to WDXX when the TC Admin processes the request for WDXX to be published
as CSD. This means that the CSDs of A and B should be coordinated to go
in the TC Admin queue around the same time.
3) Get TC admin to update normative references when there is no material
change. For example, in (2) above, WDXX and CSDYY are going to be
identical specs except for the front page. If spec A references WDXX,
the TC admin should be able to update that reference to CSDYY. A similar
update would have to be done to spec B.

-Anish
--

[1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html
[2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" <sanjay.patil@sap.com> To: Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa-liaison@lists.oasis-open.org> Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" <sanjay.patil@sap.com> To: Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa-liaison@lists.oasis-open.org> Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Looks like this will become a larger conversation <grin> ---------- Forwarded message ---------- From: Patil, Sanjay < sanjay.patil@sap.com > Date: Mon, Aug 8, 2011 at 5:05 PM Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs To: Mike Edwards < mike_edwards@uk.ibm.com > Cc: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org >, Chet Ensign < chet.ensign@oasis-open.org >   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

Are the OpenCSA TCs aware that the DCR process means NOTHING CAN PROCEED UNTIL ALL CROSS-REFERENCED SPECS ARE SUBMITTED AND PROCESSED? We cannot accept ANY updates or changes to any of the submissions involved in the DCR process until they are ALL submitted and processed.  (Otherwise we cannot do any processing as they are received.. we would have to just hold them until all are received, if we have to worry about repeating everything every time one of the TCs makes a change to one of the "waiting" specs. That means even more total delay.) I would think the TCs would be able to coordinate among themselves without having TC Administration force coordination by bringing all activity to a halt.  I guess I'm suggesting the TCs should apply Anish's suggestion (2), using their foreknowledge of the planned CSD/CSPRD numbers. Having TC Administration do what the TCs should be able to coordinate among themselves sure sounds like a recipe for ensuring customer UNhappiness.  Unless I'm missing something here... (Another possibility which would solve many ills would be to allow CSDs/CSPRDs to reference the "Latest version" URI as the normative reference, but require this to be updated as an allowable change (same as DCR) during the final stages. Not sure how this would play with the interrelated schemas and namespaces, however.) Regards, Paul On Mon, Aug 8, 2011 at 6:15 PM, Chet Ensign < chet.ensign@oasis-open.org > wrote: Looks like this will become a larger conversation <grin> ---------- Forwarded message ---------- From: Patil, Sanjay < sanjay.patil@sap.com > Date: Mon, Aug 8, 2011 at 5:05 PM Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs To: Mike Edwards < mike_edwards@uk.ibm.com > Cc: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org >, Chet Ensign < chet.ensign@oasis-open.org >   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst

Paul is way ahead of me here, having read all the (apparently) available threads in which the problems have been articulated. I'll search for that content, and will try to grok it before saying much more, but I am concerned about some of the assumptions that appear to underlie the conversation in tidbits I've seen.  It does include the reality that DCRs cannot be used to solve a problem that these TCs have gotten into by deferring their alignment issues until the (very ?) end of the spec development cycle. I have worked on some problems with spec part-whole and so forth, but gained the impression that not all the TCs were on the same page as presented to me by Martin. Etc.  More later after I locate and study the available documentation.  Chet: please make sure we have all the relevant bits that may have been sent just to you where statements/claims/questions are relevant to understanding the problems faced by the parties. Thanks -rcc On Mon, Aug 8, 2011 at 6:11 PM, Paul Knight < paul.knight@oasis-open.org > wrote: Are the OpenCSA TCs aware that the DCR process means NOTHING CAN PROCEED UNTIL ALL CROSS-REFERENCED SPECS ARE SUBMITTED AND PROCESSED? We cannot accept ANY updates or changes to any of the submissions involved in the DCR process until they are ALL submitted and processed.  (Otherwise we cannot do any processing as they are received.. we would have to just hold them until all are received, if we have to worry about repeating everything every time one of the TCs makes a change to one of the "waiting" specs. That means even more total delay.) I would think the TCs would be able to coordinate among themselves without having TC Administration force coordination by bringing all activity to a halt.  I guess I'm suggesting the TCs should apply Anish's suggestion (2), using their foreknowledge of the planned CSD/CSPRD numbers. Having TC Administration do what the TCs should be able to coordinate among themselves sure sounds like a recipe for ensuring customer UNhappiness.  Unless I'm missing something here... (Another possibility which would solve many ills would be to allow CSDs/CSPRDs to reference the "Latest version" URI as the normative reference, but require this to be updated as an allowable change (same as DCR) during the final stages. Not sure how this would play with the interrelated schemas and namespaces, however.) Regards, Paul On Mon, Aug 8, 2011 at 6:15 PM, Chet Ensign < chet.ensign@oasis-open.org > wrote: Looks like this will become a larger conversation <grin> ---------- Forwarded message ---------- From: Patil, Sanjay < sanjay.patil@sap.com > Date: Mon, Aug 8, 2011 at 5:05 PM Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs To: Mike Edwards < mike_edwards@uk.ibm.com > Cc: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org >, Chet Ensign < chet.ensign@oasis-open.org >   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783

I will wind my way up through this thread in a bit.  Paul, you shouldn't bother with a meeting. I will follow up with Mike & Sanjay to organize this. Rather than ask them to write something - which will be basically a wish list on their part - I will write something, which will frame the discussion in terms the way they need to be set - and then they can debate what is missing from the problem statement.  This is as much an educational problem as it is anything else - both ways; us educating them and them educating us. There may be more to this problem than the realize.  On Mon, Aug 8, 2011 at 7:29 PM, Robin Cover < robin@oasis-open.org > wrote: Paul is way ahead of me here, having read all the (apparently) available threads in which the problems have been articulated. I'll search for that content, and will try to grok it before saying much more, but I am concerned about some of the assumptions that appear to underlie the conversation in tidbits I've seen.  It does include the reality that DCRs cannot be used to solve a problem that these TCs have gotten into by deferring their alignment issues until the (very ?) end of the spec development cycle. I have worked on some problems with spec part-whole and so forth, but gained the impression that not all the TCs were on the same page as presented to me by Martin. Etc.  More later after I locate and study the available documentation.  Chet: please make sure we have all the relevant bits that may have been sent just to you where statements/claims/questions are relevant to understanding the problems faced by the parties. Thanks -rcc On Mon, Aug 8, 2011 at 6:11 PM, Paul Knight < paul.knight@oasis-open.org > wrote: Are the OpenCSA TCs aware that the DCR process means NOTHING CAN PROCEED UNTIL ALL CROSS-REFERENCED SPECS ARE SUBMITTED AND PROCESSED? We cannot accept ANY updates or changes to any of the submissions involved in the DCR process until they are ALL submitted and processed.  (Otherwise we cannot do any processing as they are received.. we would have to just hold them until all are received, if we have to worry about repeating everything every time one of the TCs makes a change to one of the "waiting" specs. That means even more total delay.) I would think the TCs would be able to coordinate among themselves without having TC Administration force coordination by bringing all activity to a halt.  I guess I'm suggesting the TCs should apply Anish's suggestion (2), using their foreknowledge of the planned CSD/CSPRD numbers. Having TC Administration do what the TCs should be able to coordinate among themselves sure sounds like a recipe for ensuring customer UNhappiness.  Unless I'm missing something here... (Another possibility which would solve many ills would be to allow CSDs/CSPRDs to reference the "Latest version" URI as the normative reference, but require this to be updated as an allowable change (same as DCR) during the final stages. Not sure how this would play with the interrelated schemas and namespaces, however.) Regards, Paul On Mon, Aug 8, 2011 at 6:15 PM, Chet Ensign < chet.ensign@oasis-open.org > wrote: Looks like this will become a larger conversation <grin> ---------- Forwarded message ---------- From: Patil, Sanjay < sanjay.patil@sap.com > Date: Mon, Aug 8, 2011 at 5:05 PM Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs To: Mike Edwards < mike_edwards@uk.ibm.com > Cc: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org >, Chet Ensign < chet.ensign@oasis-open.org >   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783 -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

On Mon, Aug 8, 2011 at 7:29 PM, Robin Cover < robin@oasis-open.org > wrote: Paul is way ahead of me here, having read all the (apparently) available threads in which the problems have been articulated. I'll search for that content, and will try to grok it before saying much more, but I am concerned about some of the assumptions that appear to underlie the conversation in tidbits I've seen.  It does include the reality that DCRs cannot be used to solve a problem that these TCs have gotten into by deferring their alignment issues until the (very ?) end of the spec development cycle. Bingo - that's what we need to help them understand...    I have worked on some problems with spec part-whole and so forth, but gained the impression that not all the TCs were on the same page as presented to me by Martin. Etc.  More later after I locate and study the available documentation.  Chet: please make sure we have all the relevant bits that may have been sent just to you where statements/claims/questions are relevant to understanding the problems faced by the parties. Thanks -rcc On Mon, Aug 8, 2011 at 6:11 PM, Paul Knight < paul.knight@oasis-open.org > wrote: Are the OpenCSA TCs aware that the DCR process means NOTHING CAN PROCEED UNTIL ALL CROSS-REFERENCED SPECS ARE SUBMITTED AND PROCESSED? We cannot accept ANY updates or changes to any of the submissions involved in the DCR process until they are ALL submitted and processed.  (Otherwise we cannot do any processing as they are received.. we would have to just hold them until all are received, if we have to worry about repeating everything every time one of the TCs makes a change to one of the "waiting" specs. That means even more total delay.) I would think the TCs would be able to coordinate among themselves without having TC Administration force coordination by bringing all activity to a halt.  I guess I'm suggesting the TCs should apply Anish's suggestion (2), using their foreknowledge of the planned CSD/CSPRD numbers. Having TC Administration do what the TCs should be able to coordinate among themselves sure sounds like a recipe for ensuring customer UNhappiness.  Unless I'm missing something here... (Another possibility which would solve many ills would be to allow CSDs/CSPRDs to reference the "Latest version" URI as the normative reference, but require this to be updated as an allowable change (same as DCR) during the final stages. Not sure how this would play with the interrelated schemas and namespaces, however.) Regards, Paul On Mon, Aug 8, 2011 at 6:15 PM, Chet Ensign < chet.ensign@oasis-open.org > wrote: Looks like this will become a larger conversation <grin> ---------- Forwarded message ---------- From: Patil, Sanjay < sanjay.patil@sap.com > Date: Mon, Aug 8, 2011 at 5:05 PM Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs To: Mike Edwards < mike_edwards@uk.ibm.com > Cc: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org >, Chet Ensign < chet.ensign@oasis-open.org >   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783 -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

I doubt I'm "way ahead" of Robin, just shooting from the hip rather than ... otherwise. Anyway, this approach sounds good.   Another point:  Looking back over some of the early statements in this thread, I see Anish asserting:  " the new process requires at least  15-days PR for any change (except the changes on the front page). So any  time spec A or B is updated to update its normative reference it has to  be PRed. 15-days PR for any change (except the changes on the front page). So any  time spec A or B is updated to update its normative reference it has to  be PRed. " But this is not true in general.  A PR is really needed only before moving to Committee spec or higher.  The TCs can produce as many CSDs as they want without a PR.  In fact, they may be better off doing that, so they will have a very clear target (the known CSPRDXX) to use as the normative reference points for cross-references. Regards, Paul On Mon, Aug 8, 2011 at 8:18 PM, Chet Ensign < chet.ensign@oasis-open.org > wrote: On Mon, Aug 8, 2011 at 7:29 PM, Robin Cover < robin@oasis-open.org > wrote: Paul is way ahead of me here, having read all the (apparently) available threads in which the problems have been articulated. I'll search for that content, and will try to grok it before saying much more, but I am concerned about some of the assumptions that appear to underlie the conversation in tidbits I've seen.  It does include the reality that DCRs cannot be used to solve a problem that these TCs have gotten into by deferring their alignment issues until the (very ?) end of the spec development cycle. Bingo - that's what we need to help them understand...    I have worked on some problems with spec part-whole and so forth, but gained the impression that not all the TCs were on the same page as presented to me by Martin. Etc.  More later after I locate and study the available documentation.  Chet: please make sure we have all the relevant bits that may have been sent just to you where statements/claims/questions are relevant to understanding the problems faced by the parties. Thanks -rcc On Mon, Aug 8, 2011 at 6:11 PM, Paul Knight < paul.knight@oasis-open.org > wrote: Are the OpenCSA TCs aware that the DCR process means NOTHING CAN PROCEED UNTIL ALL CROSS-REFERENCED SPECS ARE SUBMITTED AND PROCESSED? We cannot accept ANY updates or changes to any of the submissions involved in the DCR process until they are ALL submitted and processed.  (Otherwise we cannot do any processing as they are received.. we would have to just hold them until all are received, if we have to worry about repeating everything every time one of the TCs makes a change to one of the "waiting" specs. That means even more total delay.) I would think the TCs would be able to coordinate among themselves without having TC Administration force coordination by bringing all activity to a halt.  I guess I'm suggesting the TCs should apply Anish's suggestion (2), using their foreknowledge of the planned CSD/CSPRD numbers. Having TC Administration do what the TCs should be able to coordinate among themselves sure sounds like a recipe for ensuring customer UNhappiness.  Unless I'm missing something here... (Another possibility which would solve many ills would be to allow CSDs/CSPRDs to reference the "Latest version" URI as the normative reference, but require this to be updated as an allowable change (same as DCR) during the final stages. Not sure how this would play with the interrelated schemas and namespaces, however.) Regards, Paul On Mon, Aug 8, 2011 at 6:15 PM, Chet Ensign < chet.ensign@oasis-open.org > wrote: Looks like this will become a larger conversation <grin> ---------- Forwarded message ---------- From: Patil, Sanjay < sanjay.patil@sap.com > Date: Mon, Aug 8, 2011 at 5:05 PM Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs To: Mike Edwards < mike_edwards@uk.ibm.com > Cc: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org >, Chet Ensign < chet.ensign@oasis-open.org >   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783 -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst

Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ...  - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin>  - Discuss what limitations of the current process / rules contribute to the problem(s)  - Brainstorm possible modifications that could resolve the problem(s)  Is that something you all are interested in doing?  Best,  /chet  On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote:   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ...  - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin>  - Discuss what limitations of the current process / rules contribute to the problem(s)  - Brainstorm possible modifications that could resolve the problem(s)  Is that something you all are interested in doing?  Best,  /chet  On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote:   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard?   Sanjay   From: Chet Ensign [mailto:chet.ensign@oasis-open.org] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ...    - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin>  - Discuss what limitations of the current process / rules contribute to the problem(s)  - Brainstorm possible modifications that could resolve the problem(s)    Is that something you all are interested in doing?  Best,    /chet  On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote:   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard?   Sanjay   From: Chet Ensign [mailto:chet.ensign@oasis-open.org] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ...    - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin>  - Discuss what limitations of the current process / rules contribute to the problem(s)  - Brainstorm possible modifications that could resolve the problem(s)    Is that something you all are interested in doing?  Best,    /chet  On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote:   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

That approach certainly works for me. I can adjust my schedule to suit the TC's. -- /chet On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard?   Sanjay   From: Chet Ensign [mailto: chet.ensign@oasis-open.org ] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ...    - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin>  - Discuss what limitations of the current process / rules contribute to the problem(s)  - Brainstorm possible modifications that could resolve the problem(s)    Is that something you all are interested in doing?  Best,    /chet  On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote:   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

That approach certainly works for me. I can adjust my schedule to suit the TC's. -- /chet On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard?   Sanjay   From: Chet Ensign [mailto: chet.ensign@oasis-open.org ] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ...    - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin>  - Discuss what limitations of the current process / rules contribute to the problem(s)  - Brainstorm possible modifications that could resolve the problem(s)    Is that something you all are interested in doing?  Best,    /chet  On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote:   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

Mike, Sanjay - Actually, before launching on a broad chat, I think it would make more sense for us to talk and frame the problem to be solved so that conversation can be productive. Can I set up a call with both of you, maybe for Wednesday or Thursday? That will give me some time to draft a first pass at a problem statement that we can use to set up productive discussion with others.  /chet On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard?   Sanjay   From: Chet Ensign [mailto: chet.ensign@oasis-open.org ] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ...    - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin>  - Discuss what limitations of the current process / rules contribute to the problem(s)  - Brainstorm possible modifications that could resolve the problem(s)    Is that something you all are interested in doing?  Best,    /chet  On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote:   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

Mike, Sanjay - Actually, before launching on a broad chat, I think it would make more sense for us to talk and frame the problem to be solved so that conversation can be productive. Can I set up a call with both of you, maybe for Wednesday or Thursday? That will give me some time to draft a first pass at a problem statement that we can use to set up productive discussion with others.  /chet On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard?   Sanjay   From: Chet Ensign [mailto: chet.ensign@oasis-open.org ] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ...    - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin>  - Discuss what limitations of the current process / rules contribute to the problem(s)  - Brainstorm possible modifications that could resolve the problem(s)    Is that something you all are interested in doing?  Best,    /chet  On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote:   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

we can also allocate some time in Process Committee if that would be desireable/easier. FWIW I think the problem is that the SCA TCs are not really completely independent of each other. (I think of them as "almost separable".) When we were first developing SCA we discussed whether we should have one big TC or break things up to make development more manageable realizing that the trade-off was that we would have mutual dependencies. That said i'm not sure the real issue is independent TCs. The mutual dependencies would exist even if there was one TC. Having multiple TCs makes it more complicated because its harder to coordinate simultaneous votes on mutually dependent specs across TCs. I'm trying to remember why we don't allow DCR's for CSD's. I *think* it might be because we thought that since these were "only drafts", it was ok if there were some inconsistencies/bugs and not worth the effort to allow DCR's. The suggestion to allow TC's to decide if a change is not "substantive enough" is that we were never able to agree on a definition of what "enough" meant and TCs will almost always declare a change to be non- substantive, regardless. Actually we already have that issue on the Process Committee's agenda as part of figuring out if the requirement of new PRs for any change is creating too many PRs. cheers, jeff On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: > Mike, Sanjay - Actually, before launching on a broad chat, I think > it would make more sense for us to talk and frame the problem to be > solved so that conversation can be productive. Can I set up a call > with both of you, maybe for Wednesday or Thursday? That will give me > some time to draft a first pass at a problem statement that we can > use to set up productive discussion with others. > > /chet > > On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay <sanjay.patil@sap.com> > wrote: > I think it makes a lot of sense to have a conference call to jointly > define the problem and brainstorm the potentially solutions. > However, scheduling a call with the many interested parties from the > various time zones might become tricky. One option may be to check > with the SCA Assembly TC chairs if they would be ok to allocate some > of their weekly meeting time (Tue 8 AM PST) for this topic (assuming > that Chet and other concerned OASIS staff / TAB members can make > it). I believe that most of the SCA TC chairs are also members of > the SCA Assembly TC and moreover the SCA TCs typically look forward > to the SCA Assembly TC to resolve such cross-cutting issues and set > the precedent. Mike/Martin, any thoughts in this regard? > > > > Sanjay > > > > From: Chet Ensign [ mailto:chet.ensign@oasis-open.org ] > Sent: Monday, August 08, 2011 3:20 PM > To: Patil, Sanjay > Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul > Knight; Robin Cover > Subject: Re: [opencsa-liaison] Reference dependencies in various SCA > specs > > > > Sanjay, Mike et al - We started a discussion on this subject at the > TAB F2F and it is on our agenda. If you all would like, I would like > to schedule a conference call so that we can discuss together and ... > > > > - Jointly define the problem(s) - typically the most difficult part > of any of these conversations <grin> > > - Discuss what limitations of the current process / rules contribute > to the problem(s) > > - Brainstorm possible modifications that could resolve the problem(s) > > > > Is that something you all are interested in doing? > > Best, > > > > /chet > > On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay <sanjay.patil@sap.com> > wrote: > > > > Do other TC chairs have any further viewpoints on this topic? > > > > Since the resolution of this issue may involve changes to procedures > involving the TC Admin (and potentially the TC process!), we need to > decide how to take this issue forward. At the minimum, I think we > should inform the TC Admin about our opinions and start the > discussion. I am taking the liberty to copy Chet Ensign on this > email thread to set the ball rolling. > > > > Best wishes, > > Sanjay > > > > From: Mike Edwards [ mailto:mike_edwards@uk.ibm.com ] > Sent: Wednesday, August 03, 2011 1:33 AM > To: Patil, Sanjay > Cc: Anish Karmarkar; OASIS Liaison > Subject: RE: [opencsa-liaison] Reference dependencies in various SCA > specs > > > > > Sanjay, > > I agree with your views. > > In the latest round of changes, for example, I think that Assembly > is not affected by the changes to the > other specifications (Policy, WS-Binding, Java...), even though > those changes are normative. > > As a result, in my opinion, updating the Assembly spec to reference > the latest CSDs of the other specs > is a purely editorial process. > > Each TC may need to take a vote that agrees this for any particular > spec, but once that vote has > taken place, the update should be purely mechanical. No new public > reviews are required. > > > Yours, Mike > > Dr Mike Edwards > > Mail Point 137, Hursley Park > > <image001.gif> > > STSM > > Winchester, Hants SO21 2JN > > SCA, Cloud Computing & Services Standards > > United Kingdom > > Co-Chair OASIS SCA Assembly TC > > > > Chair UK ISO SC38 mirror committee (Cloud & SOA) > > > > IBM Software Group > > > > Phone: > > +44-1962 818014 > > > > Mobile: > > +44-7802-467431 (274097) > > > > e-mail: > > mike_edwards@uk.ibm.com > > > > > > > > > > > From: > > "Patil, Sanjay" <sanjay.patil@sap.com> > > To: > > Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa-liaison@lists.oasis-open.org > > > > Date: > > 02/08/2011 17:56 > > Subject: > > RE: [opencsa-liaison] Reference dependencies in various SCA specs > > > > > > > > I think the option 3 provides the required solution while retaining > the independence for the TCs to decide and follow their own > schedule. During CSD publication and PR, specs can make references > to the existing source material as of that time. Later, it should be > allowed to update the references without having to go for another > round of PR. I think it is reasonable to trust the TCs in making a > determination about whether a change in a reference is significant > enough to require another round of PR or not. > > Sanjay > > >
Original Message----- > From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] > Sent: Tuesday, August 02, 2011 9:22 AM > To: OASIS Liaison > Subject: [opencsa-liaison] Reference dependencies in various SCA specs > > As we all know, specs in all the SCA TCs have dependencies on each > other. For example, Assembly has a normative reference to Policy and > WS-Binding. To conform to Assembly one has to conform to Policy and > WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on > Assembly/Policy. The dependency graph is cyclic. > > A similar problem exists in SCA-J TC but without any cycles [1]. > > OASIS TC process solves this problem of cyclic references by using > designated cross references [2]. Unfortunately, CSDs cannot use this > mechanism as the process explicitly excludes it. So, two specs A and B > that depend on each other, will be in an infinite loop wrt updating > their normative references. Further compounding the problem (but is an > independent issue) is the fact that the new process requires at least > 15-days PR for any change (except the changes on the front page). So > any > time spec A or B is updated to update its normative reference it has > to > be PRed. > > I see three possible solutions to this: > 1) Fix the process to allow DCRs for CSDs (this is the only long term > solution, I think). > 2) Use the solution in [1] where spec A instead of using WDXX > reference > of B, uses the CSDYY reference of B. Where CSDYY is the what will > happen > to WDXX when the TC Admin processes the request for WDXX to be > published > as CSD. This means that the CSDs of A and B should be coordinated to > go > in the TC Admin queue around the same time. > 3) Get TC admin to update normative references when there is no > material > change. For example, in (2) above, WDXX and CSDYY are going to be > identical specs except for the front page. If spec A references WDXX, > the TC admin should be able to update that reference to CSDYY. A > similar > update would have to be done to spec B. > > -Anish > -- > > [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html > [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > > > > > > > > -- > > /chet > ---------------- > Chet Ensign > Director of Standards Development and TC Administration > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-378-3472 > Mobile: +1 201-341-1393 > > Follow OASIS on: > LinkedIn: http://linkd.in/OASISopen > Twitter: http://twitter.com/OASISopen > Facebook: http://facebook.com/oasis.open > > > > > -- > > /chet > ---------------- > Chet Ensign > Director of Standards Development and TC Administration > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-378-3472 > Mobile: +1 201-341-1393 > > Follow OASIS on: > LinkedIn: http://linkd.in/OASISopen > Twitter: http://twitter.com/OASISopen > Facebook: http://facebook.com/oasis.open > -- Jeff Mischkinsky jeff.mischkinsky@oracle.com Sr. Director, Oracle Fusion Middleware +1(650)506-1975 and Web Services Standards 500 Oracle Parkway, M/S 2OP9 Oracle Redwood Shores, CA 94065

Hi all, A point which I think may be misquoted and/or misunderstood: "   the requirement of new PRs for any change" mentioned by both Jeff and Anish is not  a "requirement". A PR is needed ONLY if the immediately following step is a vote for making the Work Product a Committee Specification (or Note).  TCs should not believe that they have to do a new PR every time they produce a CSD.   In fact, avoiding doing the PR until all the cross-referenced Work Products are at stable CSD states may provide a known and fairly stable target URI (i.e, the upcoming PR version), which may allow some efficiencies for everyone. However, in any case, Chet is setting up a process to get concerns and approaches clarified. Best regards, Paul On Mon, Aug 8, 2011 at 10:01 PM, Jeff Mischkinsky < jeff.mischkinsky@oracle.com > wrote: we can also allocate some time in Process Committee if that would be desireable/easier. FWIW I think the problem is that the SCA TCs are not really completely independent of each other. (I think of them as "almost separable".) When we were first developing SCA we discussed whether we should have one big TC or break things up to make development more manageable realizing that the trade-off was that we would have mutual dependencies. That said i'm not sure the real issue is independent TCs. The mutual dependencies would exist even if there was one TC. Having multiple TCs makes it more complicated because its harder to coordinate simultaneous votes on mutually dependent specs across TCs. I'm trying to remember why we don't allow DCR's for CSD's. I *think* it might be because we thought that since these were "only drafts", it was ok if there were some inconsistencies/bugs and not worth the effort to allow DCR's. The suggestion to allow TC's to decide if a change is not "substantive enough" is that we were never able to agree on a definition of what "enough" meant and TCs will almost always declare a change to be non-substantive, regardless. Actually we already have that issue on the Process Committee's agenda as part of figuring out if the requirement of new PRs for any change is creating too many PRs. cheers,  jeff On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: Mike, Sanjay - Actually, before launching on a broad chat, I think it would make more sense for us to talk and frame the problem to be solved so that conversation can be productive. Can I set up a call with both of you, maybe for Wednesday or Thursday? That will give me some time to draft a first pass at a problem statement that we can use to set up productive discussion with others. /chet On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard? Sanjay From: Chet Ensign [mailto: chet.ensign@oasis- open.org ] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ... - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin> - Discuss what limitations of the current process / rules contribute to the problem(s) - Brainstorm possible modifications that could resolve the problem(s) Is that something you all are interested in doing? Best, /chet On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: Do other TC chairs have any further viewpoints on this topic? Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling. Best wishes, Sanjay From: Mike Edwards [mailto: mike_edwards@uk.ibm. com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process. Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park <image001.gif> STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC Chair UK ISO SC38 mirror committee (Cloud & SOA) IBM Software Group Phone: +44-1962 818014 Mobile: +44-7802-467431  (274097) e-mail: mike_edwards@uk.ibm.com From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis- open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [mailto: Anish.Karmarkar@ oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/ archives/sca-j/201107/ msg00028.html [2] http://www.oasis-open.org/ policies-guidelines/tc- process#crossRefs ------------------------------ ------------------------------ --------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- Jeff Mischkinsky                                                 jeff.mischkinsky@oracle.com Sr. Director, Oracle Fusion Middleware                           +1(650)506-1975        and Web Services Standards                              500 Oracle Parkway, M/S 2OP9 Oracle                                                          Redwood Shores, CA 94065 -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst

Paul, On 8/8/2011 10:37 PM, Paul Knight wrote: CADgeAH-kdA+5Cd5F2T-DM8x1Yn7_-hCxwBpfahQ2Y9TEP5BsoA@mail.gmail.com type= cite >Hi all, A point which I think may be misquoted and/or misunderstood:   the requirement of new PRs for any change mentioned by both Jeff and Anish is not  a requirement . A very good point that deserves emphasis. Many CSDs -> show incrementing of CSD numbers CSD *immediately* prior to Committee Specification/Note -> Public Review CSD *immediately* prior to Committee Specification/Note - target of Designated Cross-Reference -> Note that the updated reference is to the Committee Specification/Note *after* resolution of any comments Back to the DCR containing document - update when CS/N is at final state. A graphic would be helpful but I don't do graphics. Sorry. Hope you are having a great day! Patrick PS: Thanks for all the hard work! CADgeAH-kdA+5Cd5F2T-DM8x1Yn7_-hCxwBpfahQ2Y9TEP5BsoA@mail.gmail.com type= cite > A PR is needed ONLY if the immediately following step is a vote for making the Work Product a Committee Specification (or Note).  TCs should not believe that they have to do a new PR every time they produce a CSD.   In fact, avoiding doing the PR until all the cross-referenced Work Products are at stable CSD states may provide a known and fairly stable target URI (i.e, the upcoming PR version), which may allow some efficiencies for everyone. However, in any case, Chet is setting up a process to get concerns and approaches clarified. Best regards, Paul On Mon, Aug 8, 2011 at 10:01 PM, Jeff Mischkinsky < jeff.mischkinsky@oracle.com > wrote: we can also allocate some time in Process Committee if that would be desireable/easier. FWIW I think the problem is that the SCA TCs are not really completely independent of each other. (I think of them as almost separable .) When we were first developing SCA we discussed whether we should have one big TC or break things up to make development more manageable realizing that the trade-off was that we would have mutual dependencies. That said i'm not sure the real issue is independent TCs. The mutual dependencies would exist even if there was one TC. Having multiple TCs makes it more complicated because its harder to coordinate simultaneous votes on mutually dependent specs across TCs. I'm trying to remember why we don't allow DCR's for CSD's. I *think* it might be because we thought that since these were only drafts , it was ok if there were some inconsistencies/bugs and not worth the effort to allow DCR's. The suggestion to allow TC's to decide if a change is not substantive enough is that we were never able to agree on a definition of what enough meant and TCs will almost always declare a change to be non-substantive, regardless. Actually we already have that issue on the Process Committee's agenda as part of figuring out if the requirement of new PRs for any change is creating too many PRs. cheers,  jeff On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: Mike, Sanjay - Actually, before launching on a broad chat, I think it would make more sense for us to talk and frame the problem to be solved so that conversation can be productive. Can I set up a call with both of you, maybe for Wednesday or Thursday? That will give me some time to draft a first pass at a problem statement that we can use to set up productive discussion with others. /chet On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard? Sanjay From: Chet Ensign [mailto: chet.ensign@oasis-open.org ] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ... - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin> - Discuss what limitations of the current process / rules contribute to the problem(s) - Brainstorm possible modifications that could resolve the problem(s) Is that something you all are interested in doing? Best, /chet On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: Do other TC chairs have any further viewpoints on this topic? Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling. Best wishes, Sanjay From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process. Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park <image001.gif> STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC Chair UK ISO SC38 mirror committee (Cloud & SOA) IBM Software Group Phone: +44-1962 818014 Mobile: +44-7802-467431  (274097) e-mail: mike_edwards@uk.ibm.com From: Patil, Sanjay < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [mailto: Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- Jeff Mischkinsky                                                 jeff.mischkinsky@oracle.com Sr. Director, Oracle Fusion Middleware                           +1(650)506-1975        and Web Services Standards                              500 Oracle Parkway, M/S 2OP9 Oracle                                                          Redwood Shores, CA 94065 -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau

Paul, Thanks for correcting that. Should have been more precise in my email. But in the context of the current discussion, the SCA TCs are looking to go to CS soon. The problem they face is that to go to CS, the current rules will require infinite number of CSDs and PRs because of the cross-dependencies, unless we find a way to break the cycle. I have proposed three different ways to move this forward. Perhaps there are more. -Anish -- On 8/8/2011 7:37 PM, Paul Knight wrote: > Hi all, > > A point which I think may be misquoted and/or misunderstood: > > "the requirement of new PRs for any change" > > mentioned by both Jeff and Anish is not a "requirement". > > A PR is needed ONLY if the immediately following step is a vote for > making the Work Product a Committee Specification (or Note). TCs should > not believe that they have to do a new PR every time they produce a CSD. > > In fact, avoiding doing the PR until all the cross-referenced Work > Products are at stable CSD states may provide a known and fairly stable > target URI (i.e, the upcoming PR version), which may allow some > efficiencies for everyone. > > However, in any case, Chet is setting up a process to get concerns and > approaches clarified. > > Best regards, > Paul > > On Mon, Aug 8, 2011 at 10:01 PM, Jeff Mischkinsky > <jeff.mischkinsky@oracle.com < mailto:jeff.mischkinsky@oracle.com >> wrote: > > we can also allocate some time in Process Committee if that would be > desireable/easier. > > FWIW I think the problem is that the SCA TCs are not really > completely independent of each other. (I think of them as "almost > separable".) When we were first developing SCA we discussed whether > we should have one big TC or break things up to make development > more manageable realizing that the trade-off was that we would have > mutual dependencies. > > That said i'm not sure the real issue is independent TCs. The mutual > dependencies would exist even if there was one TC. Having multiple > TCs makes it more complicated because its harder to coordinate > simultaneous votes on mutually dependent specs across TCs. I'm > trying to remember why we don't allow DCR's for CSD's. I *think* it > might be because we thought that since these were "only drafts", it > was ok if there were some inconsistencies/bugs and not worth the > effort to allow DCR's. > > The suggestion to allow TC's to decide if a change is not > "substantive enough" is that we were never able to agree on a > definition of what "enough" meant and TCs will almost always declare > a change to be non-substantive, regardless. > > Actually we already have that issue on the Process Committee's > agenda as part of figuring out if the requirement of new PRs for any > change is creating too many PRs. > > cheers, > jeff > > > On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: > > Mike, Sanjay - Actually, before launching on a broad chat, I > think it would make more sense for us to talk and frame the > problem to be solved so that conversation can be productive. Can > I set up a call with both of you, maybe for Wednesday or > Thursday? That will give me some time to draft a first pass at a > problem statement that we can use to set up productive > discussion with others. > > /chet > > On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay > <sanjay.patil@sap.com < mailto:sanjay.patil@sap.com >> wrote: > I think it makes a lot of sense to have a conference call to > jointly define the problem and brainstorm the potentially > solutions. However, scheduling a call with the many interested > parties from the various time zones might become tricky. One > option may be to check with the SCA Assembly TC chairs if they > would be ok to allocate some of their weekly meeting time (Tue 8 > AM PST) for this topic (assuming that Chet and other concerned > OASIS staff / TAB members can make it). I believe that most of > the SCA TC chairs are also members of the SCA Assembly TC and > moreover the SCA TCs typically look forward to the SCA Assembly > TC to resolve such cross-cutting issues and set the precedent. > Mike/Martin, any thoughts in this regard? > > > > Sanjay > > > > From: Chet Ensign [ mailto:chet.ensign@oasis-__open.org > < mailto:chet.ensign@oasis-open.org >] > Sent: Monday, August 08, 2011 3:20 PM > To: Patil, Sanjay > Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; > Paul Knight; Robin Cover > Subject: Re: [opencsa-liaison] Reference dependencies in various > SCA specs > > > > Sanjay, Mike et al - We started a discussion on this subject at > the TAB F2F and it is on our agenda. If you all would like, I > would like to schedule a conference call so that we can discuss > together and ... > > > > - Jointly define the problem(s) - typically the most difficult > part of any of these conversations <grin> > > - Discuss what limitations of the current process / rules > contribute to the problem(s) > > - Brainstorm possible modifications that could resolve the > problem(s) > > > > Is that something you all are interested in doing? > > Best, > > > > /chet > > On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay > <sanjay.patil@sap.com < mailto:sanjay.patil@sap.com >> wrote: > > > > Do other TC chairs have any further viewpoints on this topic? > > > > Since the resolution of this issue may involve changes to > procedures involving the TC Admin (and potentially the TC > process!), we need to decide how to take this issue forward. At > the minimum, I think we should inform the TC Admin about our > opinions and start the discussion. I am taking the liberty to > copy Chet Ensign on this email thread to set the ball rolling. > > > > Best wishes, > > Sanjay > > > > From: Mike Edwards [ mailto:mike_edwards@uk.ibm.__com > < mailto:mike_edwards@uk.ibm.com >] > Sent: Wednesday, August 03, 2011 1:33 AM > To: Patil, Sanjay > Cc: Anish Karmarkar; OASIS Liaison > Subject: RE: [opencsa-liaison] Reference dependencies in various > SCA specs > > > > > Sanjay, > > I agree with your views. > > In the latest round of changes, for example, I think that > Assembly is not affected by the changes to the > other specifications (Policy, WS-Binding, Java...), even though > those changes are normative. > > As a result, in my opinion, updating the Assembly spec to > reference the latest CSDs of the other specs > is a purely editorial process. > > Each TC may need to take a vote that agrees this for any > particular spec, but once that vote has > taken place, the update should be purely mechanical. No new > public reviews are required. > > > Yours, Mike > > Dr Mike Edwards > > Mail Point 137, Hursley Park > > <image001.gif> > > > STSM > > Winchester, Hants SO21 2JN > > SCA, Cloud Computing & Services Standards > > United Kingdom > > Co-Chair OASIS SCA Assembly TC > > > > Chair UK ISO SC38 mirror committee (Cloud & SOA) > > > > IBM Software Group > > > > Phone: > > +44-1962 818014 <tel:%2B44-1962%20818014> > > > > Mobile: > > +44-7802-467431 <tel:%2B44-7802-467431> (274097) > > > > e-mail: > > mike_edwards@uk.ibm.com < mailto:mike_edwards@uk.ibm.com > > > > > > > > > > > > From: > > "Patil, Sanjay" <sanjay.patil@sap.com < mailto:sanjay.patil@sap.com >> > > To: > > Anish Karmarkar <Anish.Karmarkar@oracle.com > < mailto:Anish.Karmarkar@oracle.com >>, OASIS Liaison > <opencsa-liaison@lists.oasis-__open.org > < mailto:opencsa-liaison@lists.oasis-open.org >> > > Date: > > 02/08/2011 17:56 > > Subject: > > RE: [opencsa-liaison] Reference dependencies in various SCA specs > > > > > > > > I think the option 3 provides the required solution while > retaining the independence for the TCs to decide and follow > their own schedule. During CSD publication and PR, specs can > make references to the existing source material as of that time. > Later, it should be allowed to update the references without > having to go for another round of PR. I think it is reasonable > to trust the TCs in making a determination about whether a > change in a reference is significant enough to require another > round of PR or not. > > Sanjay > > >
Original Message----- > From: Anish Karmarkar [ mailto:Anish.Karmarkar@__oracle.com > < mailto:Anish.Karmarkar@oracle.com >] > Sent: Tuesday, August 02, 2011 9:22 AM > To: OASIS Liaison > Subject: [opencsa-liaison] Reference dependencies in various SCA > specs > > As we all know, specs in all the SCA TCs have dependencies on each > other. For example, Assembly has a normative reference to Policy and > WS-Binding. To conform to Assembly one has to conform to Policy and > WS-Binding. Policy in turn depends on Assembly. WS-Binding > depends on > Assembly/Policy. The dependency graph is cyclic. > > A similar problem exists in SCA-J TC but without any cycles [1]. > > OASIS TC process solves this problem of cyclic references by using > designated cross references [2]. Unfortunately, CSDs cannot use this > mechanism as the process explicitly excludes it. So, two specs A > and B > that depend on each other, will be in an infinite loop wrt updating > their normative references. Further compounding the problem (but > is an > independent issue) is the fact that the new process requires at > least > 15-days PR for any change (except the changes on the front > page). So any > time spec A or B is updated to update its normative reference it > has to > be PRed. > > I see three possible solutions to this: > 1) Fix the process to allow DCRs for CSDs (this is the only long > term > solution, I think). > 2) Use the solution in [1] where spec A instead of using WDXX > reference > of B, uses the CSDYY reference of B. Where CSDYY is the what > will happen > to WDXX when the TC Admin processes the request for WDXX to be > published > as CSD. This means that the CSDs of A and B should be > coordinated to go > in the TC Admin queue around the same time. > 3) Get TC admin to update normative references when there is no > material > change. For example, in (2) above, WDXX and CSDYY are going to be > identical specs except for the front page. If spec A references > WDXX, > the TC admin should be able to update that reference to CSDYY. A > similar > update would have to be done to spec B. > > -Anish > -- > > [1] > http://lists.oasis-open.org/__archives/sca-j/201107/__msg00028.html > < http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html > > [2] > http://www.oasis-open.org/__policies-guidelines/tc-__process#crossRefs > < http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs > > > ------------------------------__------------------------------__--------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/__apps/org/workgroup/portal/my___workgroups.php > < https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales > with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, > Hampshire PO6 3AU > > > > > > > > > -- > > /chet > ---------------- > Chet Ensign > Director of Standards Development and TC Administration > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-378-3472 <tel:%2B1%20973-378-3472> > Mobile: +1 201-341-1393 <tel:%2B1%20201-341-1393> > > Follow OASIS on: > LinkedIn: http://linkd.in/OASISopen > Twitter: http://twitter.com/OASISopen > Facebook: http://facebook.com/oasis.open > > > > > -- > > /chet > ---------------- > Chet Ensign > Director of Standards Development and TC Administration > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-378-3472 <tel:%2B1%20973-378-3472> > Mobile: +1 201-341-1393 <tel:%2B1%20201-341-1393> > > Follow OASIS on: > LinkedIn: http://linkd.in/OASISopen > Twitter: http://twitter.com/OASISopen > Facebook: http://facebook.com/oasis.open > > > -- > Jeff Mischkinsky jeff.mischkinsky@oracle.com > < mailto:jeff.mischkinsky@oracle.com > > Sr. Director, Oracle Fusion Middleware +1(650)506-1975 > <tel:%2B1%28650%29506-1975> > and Web Services Standards 500 > Oracle Parkway, M/S 2OP9 > Oracle > Redwood Shores, CA 94065 > > > > > > > > > > > > > -- > Paul Knight < mailto:paul.knight@oasis-open.org > - Tel: +1 781-861-1013 > OASIS < http://www.oasis-open.org/ > - Advancing open standards for the > information society > Document Process Analyst > < http://www.oasis-open.org/people/staff/paul-knight > > >

Anish, can we spell out those solutions? - Allow 2.19 to apply at the CSD level - Have TC Admin provide the future URI's for the referenced CSD's to the editors for use when they approve their WD for CSD - ? I'm not sure I saw the third ... Also, another possible solution: Where a published CSD## already exists and the WD will result in publication of CSD##+1, use the "Latest Version" URL in the cross-reference. That will always resolve to the latest CSD for the referenced specification. I'll add the proposals to my write up... /chet On Tue, Aug 9, 2011 at 11:09 AM, Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote: > Paul, > > Thanks for correcting that. Should have been more precise in my email. > But in the context of the current discussion, the SCA TCs are looking to go > to CS soon. The problem they face is that to go to CS, the current rules > will require infinite number of CSDs and PRs because of the > cross-dependencies, unless we find a way to break the cycle. I have proposed > three different ways to move this forward. Perhaps there are more. > > -Anish > -- > > On 8/8/2011 7:37 PM, Paul Knight wrote: >> >> Hi all, >> >> A point which I think may be misquoted and/or misunderstood: >> >> "the requirement of new PRs for any change" >> >> mentioned by both Jeff and Anish is not  a "requirement". >> >> A PR is needed ONLY if the immediately following step is a vote for >> making the Work Product a Committee Specification (or Note).  TCs should >> not believe that they have to do a new PR every time they produce a CSD. >> >> In fact, avoiding doing the PR until all the cross-referenced Work >> Products are at stable CSD states may provide a known and fairly stable >> target URI (i.e, the upcoming PR version), which may allow some >> efficiencies for everyone. >> >> However, in any case, Chet is setting up a process to get concerns and >> approaches clarified. >> >> Best regards, >> Paul >> >> On Mon, Aug 8, 2011 at 10:01 PM, Jeff Mischkinsky >> <jeff.mischkinsky@oracle.com < mailto:jeff.mischkinsky@oracle.com >> wrote: >> >>    we can also allocate some time in Process Committee if that would be >>    desireable/easier. >> >>    FWIW I think the problem is that the SCA TCs are not really >>    completely independent of each other. (I think of them as "almost >>    separable".) When we were first developing SCA we discussed whether >>    we should have one big TC or break things up to make development >>    more manageable realizing that the trade-off was that we would have >>    mutual dependencies. >> >>    That said i'm not sure the real issue is independent TCs. The mutual >>    dependencies would exist even if there was one TC. Having multiple >>    TCs makes it more complicated because its harder to coordinate >>    simultaneous votes on mutually dependent specs across TCs. I'm >>    trying to remember why we don't allow DCR's for CSD's. I *think* it >>    might be because we thought that since these were "only drafts", it >>    was ok if there were some inconsistencies/bugs and not worth the >>    effort to allow DCR's. >> >>    The suggestion to allow TC's to decide if a change is not >>    "substantive enough" is that we were never able to agree on a >>    definition of what "enough" meant and TCs will almost always declare >>    a change to be non-substantive, regardless. >> >>    Actually we already have that issue on the Process Committee's >>    agenda as part of figuring out if the requirement of new PRs for any >>    change is creating too many PRs. >> >>    cheers, >>      jeff >> >> >>    On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: >> >>        Mike, Sanjay - Actually, before launching on a broad chat, I >>        think it would make more sense for us to talk and frame the >>        problem to be solved so that conversation can be productive. Can >>        I set up a call with both of you, maybe for Wednesday or >>        Thursday? That will give me some time to draft a first pass at a >>        problem statement that we can use to set up productive >>        discussion with others. >> >>        /chet >> >>        On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay >>        <sanjay.patil@sap.com < mailto:sanjay.patil@sap.com >> wrote: >>        I think it makes a lot of sense to have a conference call to >>        jointly define the problem and brainstorm the potentially >>        solutions. However, scheduling a call with the many interested >>        parties from the various time zones might become tricky. One >>        option may be to check with the SCA Assembly TC chairs if they >>        would be ok to allocate some of their weekly meeting time (Tue 8 >>        AM PST) for this topic (assuming that Chet and other concerned >>        OASIS staff / TAB members can make it). I believe that most of >>        the SCA TC chairs are also members of the SCA Assembly TC and >>        moreover the SCA TCs typically look forward to the SCA Assembly >>        TC to resolve such cross-cutting issues and set the precedent. >>        Mike/Martin, any thoughts in this regard? >> >> >> >>        Sanjay >> >> >> >>        From: Chet Ensign [ mailto:chet.ensign@oasis-__open.org >>        < mailto:chet.ensign@oasis-open.org >] >>        Sent: Monday, August 08, 2011 3:20 PM >>        To: Patil, Sanjay >>        Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; >>        Paul Knight; Robin Cover >>        Subject: Re: [opencsa-liaison] Reference dependencies in various >>        SCA specs >> >> >> >>        Sanjay, Mike et al - We started a discussion on this subject at >>        the TAB F2F and it is on our agenda. If you all would like, I >>        would like to schedule a conference call so that we can discuss >>        together and ... >> >> >> >>        - Jointly define the problem(s) - typically the most difficult >>        part of any of these conversations <grin> >> >>        - Discuss what limitations of the current process / rules >>        contribute to the problem(s) >> >>        - Brainstorm possible modifications that could resolve the >>        problem(s) >> >> >> >>        Is that something you all are interested in doing? >> >>        Best, >> >> >> >>        /chet >> >>        On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay >>        <sanjay.patil@sap.com < mailto:sanjay.patil@sap.com >> wrote: >> >> >> >>        Do other TC chairs have any further viewpoints on this topic? >> >> >> >>        Since the resolution of this issue may involve changes to >>        procedures involving the TC Admin (and potentially the TC >>        process!), we need to decide how to take this issue forward. At >>        the minimum, I think we should inform the TC Admin about our >>        opinions and start the discussion. I am taking the liberty to >>        copy Chet Ensign on this email thread to set the ball rolling. >> >> >> >>        Best wishes, >> >>        Sanjay >> >> >> >>        From: Mike Edwards [ mailto:mike_edwards@uk.ibm.__com >>        < mailto:mike_edwards@uk.ibm.com >] >>        Sent: Wednesday, August 03, 2011 1:33 AM >>        To: Patil, Sanjay >>        Cc: Anish Karmarkar; OASIS Liaison >>        Subject: RE: [opencsa-liaison] Reference dependencies in various >>        SCA specs >> >> >> >> >>        Sanjay, >> >>        I agree with your views. >> >>        In the latest round of changes, for example, I think that >>        Assembly is not affected by the changes to the >>        other specifications (Policy, WS-Binding, Java...), even though >>        those changes are normative. >> >>        As a result, in my opinion, updating the Assembly spec to >>        reference the latest CSDs of the other specs >>        is a purely editorial process. >> >>        Each TC may need to take a vote that agrees this for any >>        particular spec, but once that vote has >>        taken place, the update should be purely mechanical.  No new >>        public reviews are required. >> >> >>        Yours, Mike >> >>        Dr Mike Edwards >> >>          Mail Point 137, Hursley Park >> >>        <image001.gif> >> >> >>        STSM >> >>          Winchester, Hants SO21 2JN >> >>        SCA, Cloud Computing & Services Standards >> >>          United Kingdom >> >>        Co-Chair OASIS SCA Assembly TC >> >> >> >>        Chair UK ISO SC38 mirror committee (Cloud & SOA) >> >> >> >>        IBM Software Group >> >> >> >>        Phone: >> >>        +44-1962 818014 <tel:%2B44-1962%20818014> >> >> >> >>        Mobile: >> >>        +44-7802-467431 <tel:%2B44-7802-467431> (274097) >> >> >> >>        e-mail: >> >>        mike_edwards@uk.ibm.com < mailto:mike_edwards@uk.ibm.com > >> >> >> >> >> >> >> >> >> >> >>        From: >> >>        "Patil, Sanjay" <sanjay.patil@sap.com >> < mailto:sanjay.patil@sap.com >> >> >>        To: >> >>        Anish Karmarkar <Anish.Karmarkar@oracle.com >>        < mailto:Anish.Karmarkar@oracle.com >>, OASIS Liaison >>        <opencsa-liaison@lists.oasis-__open.org >>        < mailto:opencsa-liaison@lists.oasis-open.org >> >> >>        Date: >> >>        02/08/2011 17:56 >> >>        Subject: >> >>        RE: [opencsa-liaison] Reference dependencies in various SCA specs >> >> >> >> >> >> >> >>        I think the option 3 provides the required solution while >>        retaining the independence for the TCs to decide and follow >>        their own schedule. During CSD publication and PR, specs can >>        make references to the existing source material as of that time. >>        Later, it should be allowed to update the references without >>        having to go for another round of PR. I think it is reasonable >>        to trust the TCs in making a determination about whether a >>        change in a reference is significant enough to require another >>        round of PR or not. >> >>        Sanjay >> >> >>        
Original Message----- >>        From: Anish Karmarkar [ mailto:Anish.Karmarkar@__oracle.com >>        < mailto:Anish.Karmarkar@oracle.com >] >>        Sent: Tuesday, August 02, 2011 9:22 AM >>        To: OASIS Liaison >>        Subject: [opencsa-liaison] Reference dependencies in various SCA >>        specs >> >>        As we all know, specs in all the SCA TCs have dependencies on each >>        other. For example, Assembly has a normative reference to Policy >> and >>        WS-Binding. To conform to Assembly one has to conform to Policy and >>        WS-Binding. Policy in turn depends on Assembly. WS-Binding >>        depends on >>        Assembly/Policy. The dependency graph is cyclic. >> >>        A similar problem exists in SCA-J TC but without any cycles [1]. >> >>        OASIS TC process solves this problem of cyclic references by using >>        designated cross references [2]. Unfortunately, CSDs cannot use >> this >>        mechanism as the process explicitly excludes it. So, two specs A >>        and B >>        that depend on each other, will be in an infinite loop wrt updating >>        their normative references. Further compounding the problem (but >>        is an >>        independent issue) is the fact that the new process requires at >>        least >>        15-days PR for any change (except the changes on the front >>        page). So any >>        time spec A or B is updated to update its normative reference it >>        has to >>        be PRed. >> >>        I see three possible solutions to this: >>        1) Fix the process to allow DCRs for CSDs (this is the only long >>        term >>        solution, I think). >>        2) Use the solution in [1] where spec A instead of using WDXX >>        reference >>        of B, uses the CSDYY reference of B. Where CSDYY is the what >>        will happen >>        to WDXX when the TC Admin processes the request for WDXX to be >>        published >>        as CSD. This means that the CSDs of A and B should be >>        coordinated to go >>        in the TC Admin queue around the same time. >>        3) Get TC admin to update normative references when there is no >>        material >>        change. For example, in (2) above, WDXX and CSDYY are going to be >>        identical specs except for the front page. If spec A references >>        WDXX, >>        the TC admin should be able to update that reference to CSDYY. A >>        similar >>        update would have to be done to spec B. >> >>        -Anish >>        -- >> >>        [1] >>         http://lists.oasis-open.org/__archives/sca-j/201107/__msg00028.html >>        < http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html > >>        [2] >> >>   http://www.oasis-open.org/__policies-guidelines/tc-__process#crossRefs >> >>  < http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs > >> >> >>  ------------------------------__------------------------------__--------- >>        To unsubscribe from this mail list, you must leave the OASIS TC >> that >>        generates this mail.  Follow this link to all your TCs in OASIS at: >> >>   https://www.oasis-open.org/__apps/org/workgroup/portal/my___workgroups.php >> >>  < https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >> >> >> >> >> >> >> >>        Unless stated otherwise above: >>        IBM United Kingdom Limited - Registered in England and Wales >>        with number 741598. >>        Registered office: PO Box 41, North Harbour, Portsmouth, >>        Hampshire PO6 3AU >> >> >> >> >> >> >> >> >>        -- >> >>        /chet >>        ---------------- >>        Chet Ensign >>        Director of Standards Development and TC Administration >>        OASIS: Advancing open standards for the information society >>         http://www.oasis-open.org >> >>        Primary: +1 973-378-3472 <tel:%2B1%20973-378-3472> >>        Mobile: +1 201-341-1393 <tel:%2B1%20201-341-1393> >> >>        Follow OASIS on: >>        LinkedIn: http://linkd.in/OASISopen >>        Twitter: http://twitter.com/OASISopen >>        Facebook: http://facebook.com/oasis.open >> >> >> >> >>        -- >> >>        /chet >>        ---------------- >>        Chet Ensign >>        Director of Standards Development and TC Administration >>        OASIS: Advancing open standards for the information society >>         http://www.oasis-open.org >> >>        Primary: +1 973-378-3472 <tel:%2B1%20973-378-3472> >>        Mobile: +1 201-341-1393 <tel:%2B1%20201-341-1393> >> >>        Follow OASIS on: >>        LinkedIn: http://linkd.in/OASISopen >>        Twitter: http://twitter.com/OASISopen >>        Facebook: http://facebook.com/oasis.open >> >> >>    -- >>    Jeff Mischkinsky jeff.mischkinsky@oracle.com >>    < mailto:jeff.mischkinsky@oracle.com > >>    Sr. Director, Oracle Fusion Middleware +1(650)506-1975 >>    <tel:%2B1%28650%29506-1975> >>            and Web Services Standards                              500 >>    Oracle Parkway, M/S 2OP9 >>    Oracle >>      Redwood Shores, CA 94065 >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> Paul Knight < mailto:paul.knight@oasis-open.org >  - Tel: +1 781-861-1013 >> OASIS < http://www.oasis-open.org/ > - Advancing open standards for the >> information society >> Document Process Analyst >> < http://www.oasis-open.org/people/staff/paul-knight > >> >> > -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

Anish, can we spell out those solutions? - Allow 2.19 to apply at the CSD level - Have TC Admin provide the future URI's for the referenced CSD's to the editors for use when they approve their WD for CSD - ? I'm not sure I saw the third ... Also, another possible solution: Where a published CSD## already exists and the WD will result in publication of CSD##+1, use the "Latest Version" URL in the cross-reference. That will always resolve to the latest CSD for the referenced specification. I'll add the proposals to my write up... /chet On Tue, Aug 9, 2011 at 11:09 AM, Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote: > Paul, > > Thanks for correcting that. Should have been more precise in my email. > But in the context of the current discussion, the SCA TCs are looking to go > to CS soon. The problem they face is that to go to CS, the current rules > will require infinite number of CSDs and PRs because of the > cross-dependencies, unless we find a way to break the cycle. I have proposed > three different ways to move this forward. Perhaps there are more. > > -Anish > -- > > On 8/8/2011 7:37 PM, Paul Knight wrote: >> >> Hi all, >> >> A point which I think may be misquoted and/or misunderstood: >> >> "the requirement of new PRs for any change" >> >> mentioned by both Jeff and Anish is not  a "requirement". >> >> A PR is needed ONLY if the immediately following step is a vote for >> making the Work Product a Committee Specification (or Note).  TCs should >> not believe that they have to do a new PR every time they produce a CSD. >> >> In fact, avoiding doing the PR until all the cross-referenced Work >> Products are at stable CSD states may provide a known and fairly stable >> target URI (i.e, the upcoming PR version), which may allow some >> efficiencies for everyone. >> >> However, in any case, Chet is setting up a process to get concerns and >> approaches clarified. >> >> Best regards, >> Paul >> >> On Mon, Aug 8, 2011 at 10:01 PM, Jeff Mischkinsky >> <jeff.mischkinsky@oracle.com < mailto:jeff.mischkinsky@oracle.com >> wrote: >> >>    we can also allocate some time in Process Committee if that would be >>    desireable/easier. >> >>    FWIW I think the problem is that the SCA TCs are not really >>    completely independent of each other. (I think of them as "almost >>    separable".) When we were first developing SCA we discussed whether >>    we should have one big TC or break things up to make development >>    more manageable realizing that the trade-off was that we would have >>    mutual dependencies. >> >>    That said i'm not sure the real issue is independent TCs. The mutual >>    dependencies would exist even if there was one TC. Having multiple >>    TCs makes it more complicated because its harder to coordinate >>    simultaneous votes on mutually dependent specs across TCs. I'm >>    trying to remember why we don't allow DCR's for CSD's. I *think* it >>    might be because we thought that since these were "only drafts", it >>    was ok if there were some inconsistencies/bugs and not worth the >>    effort to allow DCR's. >> >>    The suggestion to allow TC's to decide if a change is not >>    "substantive enough" is that we were never able to agree on a >>    definition of what "enough" meant and TCs will almost always declare >>    a change to be non-substantive, regardless. >> >>    Actually we already have that issue on the Process Committee's >>    agenda as part of figuring out if the requirement of new PRs for any >>    change is creating too many PRs. >> >>    cheers, >>      jeff >> >> >>    On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: >> >>        Mike, Sanjay - Actually, before launching on a broad chat, I >>        think it would make more sense for us to talk and frame the >>        problem to be solved so that conversation can be productive. Can >>        I set up a call with both of you, maybe for Wednesday or >>        Thursday? That will give me some time to draft a first pass at a >>        problem statement that we can use to set up productive >>        discussion with others. >> >>        /chet >> >>        On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay >>        <sanjay.patil@sap.com < mailto:sanjay.patil@sap.com >> wrote: >>        I think it makes a lot of sense to have a conference call to >>        jointly define the problem and brainstorm the potentially >>        solutions. However, scheduling a call with the many interested >>        parties from the various time zones might become tricky. One >>        option may be to check with the SCA Assembly TC chairs if they >>        would be ok to allocate some of their weekly meeting time (Tue 8 >>        AM PST) for this topic (assuming that Chet and other concerned >>        OASIS staff / TAB members can make it). I believe that most of >>        the SCA TC chairs are also members of the SCA Assembly TC and >>        moreover the SCA TCs typically look forward to the SCA Assembly >>        TC to resolve such cross-cutting issues and set the precedent. >>        Mike/Martin, any thoughts in this regard? >> >> >> >>        Sanjay >> >> >> >>        From: Chet Ensign [ mailto:chet.ensign@oasis-__open.org >>        < mailto:chet.ensign@oasis-open.org >] >>        Sent: Monday, August 08, 2011 3:20 PM >>        To: Patil, Sanjay >>        Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; >>        Paul Knight; Robin Cover >>        Subject: Re: [opencsa-liaison] Reference dependencies in various >>        SCA specs >> >> >> >>        Sanjay, Mike et al - We started a discussion on this subject at >>        the TAB F2F and it is on our agenda. If you all would like, I >>        would like to schedule a conference call so that we can discuss >>        together and ... >> >> >> >>        - Jointly define the problem(s) - typically the most difficult >>        part of any of these conversations <grin> >> >>        - Discuss what limitations of the current process / rules >>        contribute to the problem(s) >> >>        - Brainstorm possible modifications that could resolve the >>        problem(s) >> >> >> >>        Is that something you all are interested in doing? >> >>        Best, >> >> >> >>        /chet >> >>        On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay >>        <sanjay.patil@sap.com < mailto:sanjay.patil@sap.com >> wrote: >> >> >> >>        Do other TC chairs have any further viewpoints on this topic? >> >> >> >>        Since the resolution of this issue may involve changes to >>        procedures involving the TC Admin (and potentially the TC >>        process!), we need to decide how to take this issue forward. At >>        the minimum, I think we should inform the TC Admin about our >>        opinions and start the discussion. I am taking the liberty to >>        copy Chet Ensign on this email thread to set the ball rolling. >> >> >> >>        Best wishes, >> >>        Sanjay >> >> >> >>        From: Mike Edwards [ mailto:mike_edwards@uk.ibm.__com >>        < mailto:mike_edwards@uk.ibm.com >] >>        Sent: Wednesday, August 03, 2011 1:33 AM >>        To: Patil, Sanjay >>        Cc: Anish Karmarkar; OASIS Liaison >>        Subject: RE: [opencsa-liaison] Reference dependencies in various >>        SCA specs >> >> >> >> >>        Sanjay, >> >>        I agree with your views. >> >>        In the latest round of changes, for example, I think that >>        Assembly is not affected by the changes to the >>        other specifications (Policy, WS-Binding, Java...), even though >>        those changes are normative. >> >>        As a result, in my opinion, updating the Assembly spec to >>        reference the latest CSDs of the other specs >>        is a purely editorial process. >> >>        Each TC may need to take a vote that agrees this for any >>        particular spec, but once that vote has >>        taken place, the update should be purely mechanical.  No new >>        public reviews are required. >> >> >>        Yours, Mike >> >>        Dr Mike Edwards >> >>          Mail Point 137, Hursley Park >> >>        <image001.gif> >> >> >>        STSM >> >>          Winchester, Hants SO21 2JN >> >>        SCA, Cloud Computing & Services Standards >> >>          United Kingdom >> >>        Co-Chair OASIS SCA Assembly TC >> >> >> >>        Chair UK ISO SC38 mirror committee (Cloud & SOA) >> >> >> >>        IBM Software Group >> >> >> >>        Phone: >> >>        +44-1962 818014 <tel:%2B44-1962%20818014> >> >> >> >>        Mobile: >> >>        +44-7802-467431 <tel:%2B44-7802-467431> (274097) >> >> >> >>        e-mail: >> >>        mike_edwards@uk.ibm.com < mailto:mike_edwards@uk.ibm.com > >> >> >> >> >> >> >> >> >> >> >>        From: >> >>        "Patil, Sanjay" <sanjay.patil@sap.com >> < mailto:sanjay.patil@sap.com >> >> >>        To: >> >>        Anish Karmarkar <Anish.Karmarkar@oracle.com >>        < mailto:Anish.Karmarkar@oracle.com >>, OASIS Liaison >>        <opencsa-liaison@lists.oasis-__open.org >>        < mailto:opencsa-liaison@lists.oasis-open.org >> >> >>        Date: >> >>        02/08/2011 17:56 >> >>        Subject: >> >>        RE: [opencsa-liaison] Reference dependencies in various SCA specs >> >> >> >> >> >> >> >>        I think the option 3 provides the required solution while >>        retaining the independence for the TCs to decide and follow >>        their own schedule. During CSD publication and PR, specs can >>        make references to the existing source material as of that time. >>        Later, it should be allowed to update the references without >>        having to go for another round of PR. I think it is reasonable >>        to trust the TCs in making a determination about whether a >>        change in a reference is significant enough to require another >>        round of PR or not. >> >>        Sanjay >> >> >>        
Original Message----- >>        From: Anish Karmarkar [ mailto:Anish.Karmarkar@__oracle.com >>        < mailto:Anish.Karmarkar@oracle.com >] >>        Sent: Tuesday, August 02, 2011 9:22 AM >>        To: OASIS Liaison >>        Subject: [opencsa-liaison] Reference dependencies in various SCA >>        specs >> >>        As we all know, specs in all the SCA TCs have dependencies on each >>        other. For example, Assembly has a normative reference to Policy >> and >>        WS-Binding. To conform to Assembly one has to conform to Policy and >>        WS-Binding. Policy in turn depends on Assembly. WS-Binding >>        depends on >>        Assembly/Policy. The dependency graph is cyclic. >> >>        A similar problem exists in SCA-J TC but without any cycles [1]. >> >>        OASIS TC process solves this problem of cyclic references by using >>        designated cross references [2]. Unfortunately, CSDs cannot use >> this >>        mechanism as the process explicitly excludes it. So, two specs A >>        and B >>        that depend on each other, will be in an infinite loop wrt updating >>        their normative references. Further compounding the problem (but >>        is an >>        independent issue) is the fact that the new process requires at >>        least >>        15-days PR for any change (except the changes on the front >>        page). So any >>        time spec A or B is updated to update its normative reference it >>        has to >>        be PRed. >> >>        I see three possible solutions to this: >>        1) Fix the process to allow DCRs for CSDs (this is the only long >>        term >>        solution, I think). >>        2) Use the solution in [1] where spec A instead of using WDXX >>        reference >>        of B, uses the CSDYY reference of B. Where CSDYY is the what >>        will happen >>        to WDXX when the TC Admin processes the request for WDXX to be >>        published >>        as CSD. This means that the CSDs of A and B should be >>        coordinated to go >>        in the TC Admin queue around the same time. >>        3) Get TC admin to update normative references when there is no >>        material >>        change. For example, in (2) above, WDXX and CSDYY are going to be >>        identical specs except for the front page. If spec A references >>        WDXX, >>        the TC admin should be able to update that reference to CSDYY. A >>        similar >>        update would have to be done to spec B. >> >>        -Anish >>        -- >> >>        [1] >>         http://lists.oasis-open.org/__archives/sca-j/201107/__msg00028.html >>        < http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html > >>        [2] >> >>   http://www.oasis-open.org/__policies-guidelines/tc-__process#crossRefs >> >>  < http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs > >> >> >>  ------------------------------__------------------------------__--------- >>        To unsubscribe from this mail list, you must leave the OASIS TC >> that >>        generates this mail.  Follow this link to all your TCs in OASIS at: >> >>   https://www.oasis-open.org/__apps/org/workgroup/portal/my___workgroups.php >> >>  < https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >> >> >> >> >> >> >> >>        Unless stated otherwise above: >>        IBM United Kingdom Limited - Registered in England and Wales >>        with number 741598. >>        Registered office: PO Box 41, North Harbour, Portsmouth, >>        Hampshire PO6 3AU >> >> >> >> >> >> >> >> >>        -- >> >>        /chet >>        ---------------- >>        Chet Ensign >>        Director of Standards Development and TC Administration >>        OASIS: Advancing open standards for the information society >>         http://www.oasis-open.org >> >>        Primary: +1 973-378-3472 <tel:%2B1%20973-378-3472> >>        Mobile: +1 201-341-1393 <tel:%2B1%20201-341-1393> >> >>        Follow OASIS on: >>        LinkedIn: http://linkd.in/OASISopen >>        Twitter: http://twitter.com/OASISopen >>        Facebook: http://facebook.com/oasis.open >> >> >> >> >>        -- >> >>        /chet >>        ---------------- >>        Chet Ensign >>        Director of Standards Development and TC Administration >>        OASIS: Advancing open standards for the information society >>         http://www.oasis-open.org >> >>        Primary: +1 973-378-3472 <tel:%2B1%20973-378-3472> >>        Mobile: +1 201-341-1393 <tel:%2B1%20201-341-1393> >> >>        Follow OASIS on: >>        LinkedIn: http://linkd.in/OASISopen >>        Twitter: http://twitter.com/OASISopen >>        Facebook: http://facebook.com/oasis.open >> >> >>    -- >>    Jeff Mischkinsky jeff.mischkinsky@oracle.com >>    < mailto:jeff.mischkinsky@oracle.com > >>    Sr. Director, Oracle Fusion Middleware +1(650)506-1975 >>    <tel:%2B1%28650%29506-1975> >>            and Web Services Standards                              500 >>    Oracle Parkway, M/S 2OP9 >>    Oracle >>      Redwood Shores, CA 94065 >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> Paul Knight < mailto:paul.knight@oasis-open.org >  - Tel: +1 781-861-1013 >> OASIS < http://www.oasis-open.org/ > - Advancing open standards for the >> information society >> Document Process Analyst >> < http://www.oasis-open.org/people/staff/paul-knight > >> >> > -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

Paul, Thanks for correcting that. Should have been more precise in my email. But in the context of the current discussion, the SCA TCs are looking to go to CS soon. The problem they face is that to go to CS, the current rules will require infinite number of CSDs and PRs because of the cross-dependencies, unless we find a way to break the cycle. I have proposed three different ways to move this forward. Perhaps there are more. -Anish -- On 8/8/2011 7:37 PM, Paul Knight wrote: > Hi all, > > A point which I think may be misquoted and/or misunderstood: > > "the requirement of new PRs for any change" > > mentioned by both Jeff and Anish is not a "requirement". > > A PR is needed ONLY if the immediately following step is a vote for > making the Work Product a Committee Specification (or Note). TCs should > not believe that they have to do a new PR every time they produce a CSD. > > In fact, avoiding doing the PR until all the cross-referenced Work > Products are at stable CSD states may provide a known and fairly stable > target URI (i.e, the upcoming PR version), which may allow some > efficiencies for everyone. > > However, in any case, Chet is setting up a process to get concerns and > approaches clarified. > > Best regards, > Paul > > On Mon, Aug 8, 2011 at 10:01 PM, Jeff Mischkinsky > <jeff.mischkinsky@oracle.com < mailto:jeff.mischkinsky@oracle.com >> wrote: > > we can also allocate some time in Process Committee if that would be > desireable/easier. > > FWIW I think the problem is that the SCA TCs are not really > completely independent of each other. (I think of them as "almost > separable".) When we were first developing SCA we discussed whether > we should have one big TC or break things up to make development > more manageable realizing that the trade-off was that we would have > mutual dependencies. > > That said i'm not sure the real issue is independent TCs. The mutual > dependencies would exist even if there was one TC. Having multiple > TCs makes it more complicated because its harder to coordinate > simultaneous votes on mutually dependent specs across TCs. I'm > trying to remember why we don't allow DCR's for CSD's. I *think* it > might be because we thought that since these were "only drafts", it > was ok if there were some inconsistencies/bugs and not worth the > effort to allow DCR's. > > The suggestion to allow TC's to decide if a change is not > "substantive enough" is that we were never able to agree on a > definition of what "enough" meant and TCs will almost always declare > a change to be non-substantive, regardless. > > Actually we already have that issue on the Process Committee's > agenda as part of figuring out if the requirement of new PRs for any > change is creating too many PRs. > > cheers, > jeff > > > On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: > > Mike, Sanjay - Actually, before launching on a broad chat, I > think it would make more sense for us to talk and frame the > problem to be solved so that conversation can be productive. Can > I set up a call with both of you, maybe for Wednesday or > Thursday? That will give me some time to draft a first pass at a > problem statement that we can use to set up productive > discussion with others. > > /chet > > On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay > <sanjay.patil@sap.com < mailto:sanjay.patil@sap.com >> wrote: > I think it makes a lot of sense to have a conference call to > jointly define the problem and brainstorm the potentially > solutions. However, scheduling a call with the many interested > parties from the various time zones might become tricky. One > option may be to check with the SCA Assembly TC chairs if they > would be ok to allocate some of their weekly meeting time (Tue 8 > AM PST) for this topic (assuming that Chet and other concerned > OASIS staff / TAB members can make it). I believe that most of > the SCA TC chairs are also members of the SCA Assembly TC and > moreover the SCA TCs typically look forward to the SCA Assembly > TC to resolve such cross-cutting issues and set the precedent. > Mike/Martin, any thoughts in this regard? > > > > Sanjay > > > > From: Chet Ensign [ mailto:chet.ensign@oasis-__open.org > < mailto:chet.ensign@oasis-open.org >] > Sent: Monday, August 08, 2011 3:20 PM > To: Patil, Sanjay > Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; > Paul Knight; Robin Cover > Subject: Re: [opencsa-liaison] Reference dependencies in various > SCA specs > > > > Sanjay, Mike et al - We started a discussion on this subject at > the TAB F2F and it is on our agenda. If you all would like, I > would like to schedule a conference call so that we can discuss > together and ... > > > > - Jointly define the problem(s) - typically the most difficult > part of any of these conversations <grin> > > - Discuss what limitations of the current process / rules > contribute to the problem(s) > > - Brainstorm possible modifications that could resolve the > problem(s) > > > > Is that something you all are interested in doing? > > Best, > > > > /chet > > On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay > <sanjay.patil@sap.com < mailto:sanjay.patil@sap.com >> wrote: > > > > Do other TC chairs have any further viewpoints on this topic? > > > > Since the resolution of this issue may involve changes to > procedures involving the TC Admin (and potentially the TC > process!), we need to decide how to take this issue forward. At > the minimum, I think we should inform the TC Admin about our > opinions and start the discussion. I am taking the liberty to > copy Chet Ensign on this email thread to set the ball rolling. > > > > Best wishes, > > Sanjay > > > > From: Mike Edwards [ mailto:mike_edwards@uk.ibm.__com > < mailto:mike_edwards@uk.ibm.com >] > Sent: Wednesday, August 03, 2011 1:33 AM > To: Patil, Sanjay > Cc: Anish Karmarkar; OASIS Liaison > Subject: RE: [opencsa-liaison] Reference dependencies in various > SCA specs > > > > > Sanjay, > > I agree with your views. > > In the latest round of changes, for example, I think that > Assembly is not affected by the changes to the > other specifications (Policy, WS-Binding, Java...), even though > those changes are normative. > > As a result, in my opinion, updating the Assembly spec to > reference the latest CSDs of the other specs > is a purely editorial process. > > Each TC may need to take a vote that agrees this for any > particular spec, but once that vote has > taken place, the update should be purely mechanical. No new > public reviews are required. > > > Yours, Mike > > Dr Mike Edwards > > Mail Point 137, Hursley Park > > <image001.gif> > > > STSM > > Winchester, Hants SO21 2JN > > SCA, Cloud Computing & Services Standards > > United Kingdom > > Co-Chair OASIS SCA Assembly TC > > > > Chair UK ISO SC38 mirror committee (Cloud & SOA) > > > > IBM Software Group > > > > Phone: > > +44-1962 818014 <tel:%2B44-1962%20818014> > > > > Mobile: > > +44-7802-467431 <tel:%2B44-7802-467431> (274097) > > > > e-mail: > > mike_edwards@uk.ibm.com < mailto:mike_edwards@uk.ibm.com > > > > > > > > > > > > From: > > "Patil, Sanjay" <sanjay.patil@sap.com < mailto:sanjay.patil@sap.com >> > > To: > > Anish Karmarkar <Anish.Karmarkar@oracle.com > < mailto:Anish.Karmarkar@oracle.com >>, OASIS Liaison > <opencsa-liaison@lists.oasis-__open.org > < mailto:opencsa-liaison@lists.oasis-open.org >> > > Date: > > 02/08/2011 17:56 > > Subject: > > RE: [opencsa-liaison] Reference dependencies in various SCA specs > > > > > > > > I think the option 3 provides the required solution while > retaining the independence for the TCs to decide and follow > their own schedule. During CSD publication and PR, specs can > make references to the existing source material as of that time. > Later, it should be allowed to update the references without > having to go for another round of PR. I think it is reasonable > to trust the TCs in making a determination about whether a > change in a reference is significant enough to require another > round of PR or not. > > Sanjay > > >
Original Message----- > From: Anish Karmarkar [ mailto:Anish.Karmarkar@__oracle.com > < mailto:Anish.Karmarkar@oracle.com >] > Sent: Tuesday, August 02, 2011 9:22 AM > To: OASIS Liaison > Subject: [opencsa-liaison] Reference dependencies in various SCA > specs > > As we all know, specs in all the SCA TCs have dependencies on each > other. For example, Assembly has a normative reference to Policy and > WS-Binding. To conform to Assembly one has to conform to Policy and > WS-Binding. Policy in turn depends on Assembly. WS-Binding > depends on > Assembly/Policy. The dependency graph is cyclic. > > A similar problem exists in SCA-J TC but without any cycles [1]. > > OASIS TC process solves this problem of cyclic references by using > designated cross references [2]. Unfortunately, CSDs cannot use this > mechanism as the process explicitly excludes it. So, two specs A > and B > that depend on each other, will be in an infinite loop wrt updating > their normative references. Further compounding the problem (but > is an > independent issue) is the fact that the new process requires at > least > 15-days PR for any change (except the changes on the front > page). So any > time spec A or B is updated to update its normative reference it > has to > be PRed. > > I see three possible solutions to this: > 1) Fix the process to allow DCRs for CSDs (this is the only long > term > solution, I think). > 2) Use the solution in [1] where spec A instead of using WDXX > reference > of B, uses the CSDYY reference of B. Where CSDYY is the what > will happen > to WDXX when the TC Admin processes the request for WDXX to be > published > as CSD. This means that the CSDs of A and B should be > coordinated to go > in the TC Admin queue around the same time. > 3) Get TC admin to update normative references when there is no > material > change. For example, in (2) above, WDXX and CSDYY are going to be > identical specs except for the front page. If spec A references > WDXX, > the TC admin should be able to update that reference to CSDYY. A > similar > update would have to be done to spec B. > > -Anish > -- > > [1] > http://lists.oasis-open.org/__archives/sca-j/201107/__msg00028.html > < http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html > > [2] > http://www.oasis-open.org/__policies-guidelines/tc-__process#crossRefs > < http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs > > > ------------------------------__------------------------------__--------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/__apps/org/workgroup/portal/my___workgroups.php > < https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales > with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, > Hampshire PO6 3AU > > > > > > > > > -- > > /chet > ---------------- > Chet Ensign > Director of Standards Development and TC Administration > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-378-3472 <tel:%2B1%20973-378-3472> > Mobile: +1 201-341-1393 <tel:%2B1%20201-341-1393> > > Follow OASIS on: > LinkedIn: http://linkd.in/OASISopen > Twitter: http://twitter.com/OASISopen > Facebook: http://facebook.com/oasis.open > > > > > -- > > /chet > ---------------- > Chet Ensign > Director of Standards Development and TC Administration > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-378-3472 <tel:%2B1%20973-378-3472> > Mobile: +1 201-341-1393 <tel:%2B1%20201-341-1393> > > Follow OASIS on: > LinkedIn: http://linkd.in/OASISopen > Twitter: http://twitter.com/OASISopen > Facebook: http://facebook.com/oasis.open > > > -- > Jeff Mischkinsky jeff.mischkinsky@oracle.com > < mailto:jeff.mischkinsky@oracle.com > > Sr. Director, Oracle Fusion Middleware +1(650)506-1975 > <tel:%2B1%28650%29506-1975> > and Web Services Standards 500 > Oracle Parkway, M/S 2OP9 > Oracle > Redwood Shores, CA 94065 > > > > > > > > > > > > > -- > Paul Knight < mailto:paul.knight@oasis-open.org > - Tel: +1 781-861-1013 > OASIS < http://www.oasis-open.org/ > - Advancing open standards for the > information society > Document Process Analyst > < http://www.oasis-open.org/people/staff/paul-knight > > >

Hi all, A point which I think may be misquoted and/or misunderstood: "   the requirement of new PRs for any change" mentioned by both Jeff and Anish is not  a "requirement". A PR is needed ONLY if the immediately following step is a vote for making the Work Product a Committee Specification (or Note).  TCs should not believe that they have to do a new PR every time they produce a CSD.   In fact, avoiding doing the PR until all the cross-referenced Work Products are at stable CSD states may provide a known and fairly stable target URI (i.e, the upcoming PR version), which may allow some efficiencies for everyone. However, in any case, Chet is setting up a process to get concerns and approaches clarified. Best regards, Paul On Mon, Aug 8, 2011 at 10:01 PM, Jeff Mischkinsky < jeff.mischkinsky@oracle.com > wrote: we can also allocate some time in Process Committee if that would be desireable/easier. FWIW I think the problem is that the SCA TCs are not really completely independent of each other. (I think of them as "almost separable".) When we were first developing SCA we discussed whether we should have one big TC or break things up to make development more manageable realizing that the trade-off was that we would have mutual dependencies. That said i'm not sure the real issue is independent TCs. The mutual dependencies would exist even if there was one TC. Having multiple TCs makes it more complicated because its harder to coordinate simultaneous votes on mutually dependent specs across TCs. I'm trying to remember why we don't allow DCR's for CSD's. I *think* it might be because we thought that since these were "only drafts", it was ok if there were some inconsistencies/bugs and not worth the effort to allow DCR's. The suggestion to allow TC's to decide if a change is not "substantive enough" is that we were never able to agree on a definition of what "enough" meant and TCs will almost always declare a change to be non-substantive, regardless. Actually we already have that issue on the Process Committee's agenda as part of figuring out if the requirement of new PRs for any change is creating too many PRs. cheers,  jeff On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: Mike, Sanjay - Actually, before launching on a broad chat, I think it would make more sense for us to talk and frame the problem to be solved so that conversation can be productive. Can I set up a call with both of you, maybe for Wednesday or Thursday? That will give me some time to draft a first pass at a problem statement that we can use to set up productive discussion with others. /chet On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard? Sanjay From: Chet Ensign [mailto: chet.ensign@oasis- open.org ] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ... - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin> - Discuss what limitations of the current process / rules contribute to the problem(s) - Brainstorm possible modifications that could resolve the problem(s) Is that something you all are interested in doing? Best, /chet On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: Do other TC chairs have any further viewpoints on this topic? Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling. Best wishes, Sanjay From: Mike Edwards [mailto: mike_edwards@uk.ibm. com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process. Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park <image001.gif> STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC Chair UK ISO SC38 mirror committee (Cloud & SOA) IBM Software Group Phone: +44-1962 818014 Mobile: +44-7802-467431  (274097) e-mail: mike_edwards@uk.ibm.com From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis- open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [mailto: Anish.Karmarkar@ oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/ archives/sca-j/201107/ msg00028.html [2] http://www.oasis-open.org/ policies-guidelines/tc- process#crossRefs ------------------------------ ------------------------------ --------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- Jeff Mischkinsky                                                 jeff.mischkinsky@oracle.com Sr. Director, Oracle Fusion Middleware                           +1(650)506-1975        and Web Services Standards                              500 Oracle Parkway, M/S 2OP9 Oracle                                                          Redwood Shores, CA 94065 -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst

We removed C*Ds from the DCR section because we argued that a TC could always produce another draft. However, what we didn't do was to examine the inter-dependency of this rationale with the 15 public review for any change (aside from 2.18(6) changes), and we are seeing some of that interplay here. I think if a TC can show that a normative reference has not been materially changed i.e. only a status change has been made - reflected by the changes permissible in section 2.18(6)- they (or TC Admin) should be able to update the reference to that changed version. It should be easy to track if only 2.18(6) changes have been made. Martin. >
Original Message----- > From: Jeff Mischkinsky > Sent: 09 August 2011 03:01 > To: Chet Ensign > Cc: Patil, Sanjay; Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; > Paul Knight; Robin Cover > Subject: [tab] Re: [opencsa-liaison] Reference dependencies in various SCA > specs > > we can also allocate some time in Process Committee if that would be > desireable/easier. > > FWIW I think the problem is that the SCA TCs are not really completely > independent of each other. (I think of them as "almost separable".) > When we were first developing SCA we discussed whether we should have > one big TC or break things up to make development more manageable > realizing that the trade-off was that we would have mutual dependencies. > > That said i'm not sure the real issue is independent TCs. The mutual > dependencies would exist even if there was one TC. Having multiple TCs > makes it more complicated because its harder to coordinate > simultaneous votes on mutually dependent specs across TCs. I'm trying > to remember why we don't allow DCR's for CSD's. I *think* it might be > because we thought that since these were "only drafts", it was ok if > there were some inconsistencies/bugs and not worth the effort to allow > DCR's. > > The suggestion to allow TC's to decide if a change is not "substantive > enough" is that we were never able to agree on a definition of what > "enough" meant and TCs will almost always declare a change to be non- > substantive, regardless. > > Actually we already have that issue on the Process Committee's agenda > as part of figuring out if the requirement of new PRs for any change > is creating too many PRs. > > cheers, > jeff > > On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: > > > Mike, Sanjay - Actually, before launching on a broad chat, I think > > it would make more sense for us to talk and frame the problem to be > > solved so that conversation can be productive. Can I set up a call > > with both of you, maybe for Wednesday or Thursday? That will give me > > some time to draft a first pass at a problem statement that we can > > use to set up productive discussion with others. > > > > /chet > > > > On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay <sanjay.patil@sap.com> > > wrote: > > I think it makes a lot of sense to have a conference call to jointly > > define the problem and brainstorm the potentially solutions. > > However, scheduling a call with the many interested parties from the > > various time zones might become tricky. One option may be to check > > with the SCA Assembly TC chairs if they would be ok to allocate some > > of their weekly meeting time (Tue 8 AM PST) for this topic (assuming > > that Chet and other concerned OASIS staff / TAB members can make > > it). I believe that most of the SCA TC chairs are also members of > > the SCA Assembly TC and moreover the SCA TCs typically look forward > > to the SCA Assembly TC to resolve such cross-cutting issues and set > > the precedent. Mike/Martin, any thoughts in this regard? > > > > > > > > Sanjay > > > > > > > > From: Chet Ensign [ mailto:chet.ensign@oasis-open.org ] > > Sent: Monday, August 08, 2011 3:20 PM > > To: Patil, Sanjay > > Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul > > Knight; Robin Cover > > Subject: Re: [opencsa-liaison] Reference dependencies in various SCA > > specs > > > > > > > > Sanjay, Mike et al - We started a discussion on this subject at the > > TAB F2F and it is on our agenda. If you all would like, I would like > > to schedule a conference call so that we can discuss together and ... > > > > > > > > - Jointly define the problem(s) - typically the most difficult part > > of any of these conversations <grin> > > > > - Discuss what limitations of the current process / rules contribute > > to the problem(s) > > > > - Brainstorm possible modifications that could resolve the problem(s) > > > > > > > > Is that something you all are interested in doing? > > > > Best, > > > > > > > > /chet > > > > On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay <sanjay.patil@sap.com> > > wrote: > > > > > > > > Do other TC chairs have any further viewpoints on this topic? > > > > > > > > Since the resolution of this issue may involve changes to procedures > > involving the TC Admin (and potentially the TC process!), we need to > > decide how to take this issue forward. At the minimum, I think we > > should inform the TC Admin about our opinions and start the > > discussion. I am taking the liberty to copy Chet Ensign on this > > email thread to set the ball rolling. > > > > > > > > Best wishes, > > > > Sanjay > > > > > > > > From: Mike Edwards [ mailto:mike_edwards@uk.ibm.com ] > > Sent: Wednesday, August 03, 2011 1:33 AM > > To: Patil, Sanjay > > Cc: Anish Karmarkar; OASIS Liaison > > Subject: RE: [opencsa-liaison] Reference dependencies in various SCA > > specs > > > > > > > > > > Sanjay, > > > > I agree with your views. > > > > In the latest round of changes, for example, I think that Assembly > > is not affected by the changes to the > > other specifications (Policy, WS-Binding, Java...), even though > > those changes are normative. > > > > As a result, in my opinion, updating the Assembly spec to reference > > the latest CSDs of the other specs > > is a purely editorial process. > > > > Each TC may need to take a vote that agrees this for any particular > > spec, but once that vote has > > taken place, the update should be purely mechanical. No new public > > reviews are required. > > > > > > Yours, Mike > > > > Dr Mike Edwards > > > > Mail Point 137, Hursley Park > > > > <image001.gif> > > > > STSM > > > > Winchester, Hants SO21 2JN > > > > SCA, Cloud Computing & Services Standards > > > > United Kingdom > > > > Co-Chair OASIS SCA Assembly TC > > > > > > > > Chair UK ISO SC38 mirror committee (Cloud & SOA) > > > > > > > > IBM Software Group > > > > > > > > Phone: > > > > +44-1962 818014 > > > > > > > > Mobile: > > > > +44-7802-467431 (274097) > > > > > > > > e-mail: > > > > mike_edwards@uk.ibm.com > > > > > > > > > > > > > > > > > > > > > > From: > > > > "Patil, Sanjay" <sanjay.patil@sap.com> > > > > To: > > > > Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa- > liaison@lists.oasis-open.org > > > > > > > Date: > > > > 02/08/2011 17:56 > > > > Subject: > > > > RE: [opencsa-liaison] Reference dependencies in various SCA specs > > > > > > > > > > > > > > > > I think the option 3 provides the required solution while retaining > > the independence for the TCs to decide and follow their own > > schedule. During CSD publication and PR, specs can make references > > to the existing source material as of that time. Later, it should be > > allowed to update the references without having to go for another > > round of PR. I think it is reasonable to trust the TCs in making a > > determination about whether a change in a reference is significant > > enough to require another round of PR or not. > > > > Sanjay > > > > > >
Original Message----- > > From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] > > Sent: Tuesday, August 02, 2011 9:22 AM > > To: OASIS Liaison > > Subject: [opencsa-liaison] Reference dependencies in various SCA specs > > > > As we all know, specs in all the SCA TCs have dependencies on each > > other. For example, Assembly has a normative reference to Policy and > > WS-Binding. To conform to Assembly one has to conform to Policy and > > WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on > > Assembly/Policy. The dependency graph is cyclic. > > > > A similar problem exists in SCA-J TC but without any cycles [1]. > > > > OASIS TC process solves this problem of cyclic references by using > > designated cross references [2]. Unfortunately, CSDs cannot use this > > mechanism as the process explicitly excludes it. So, two specs A and B > > that depend on each other, will be in an infinite loop wrt updating > > their normative references. Further compounding the problem (but is an > > independent issue) is the fact that the new process requires at least > > 15-days PR for any change (except the changes on the front page). So > > any > > time spec A or B is updated to update its normative reference it has > > to > > be PRed. > > > > I see three possible solutions to this: > > 1) Fix the process to allow DCRs for CSDs (this is the only long term > > solution, I think). > > 2) Use the solution in [1] where spec A instead of using WDXX > > reference > > of B, uses the CSDYY reference of B. Where CSDYY is the what will > > happen > > to WDXX when the TC Admin processes the request for WDXX to be > > published > > as CSD. This means that the CSDs of A and B should be coordinated to > > go > > in the TC Admin queue around the same time. > > 3) Get TC admin to update normative references when there is no > > material > > change. For example, in (2) above, WDXX and CSDYY are going to be > > identical specs except for the front page. If spec A references WDXX, > > the TC admin should be able to update that reference to CSDYY. A > > similar > > update would have to be done to spec B. > > > > -Anish > > -- > > > > [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html > > [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > > PO6 3AU > > > > > > > > > > > > > > > > > > -- > > > > /chet > > ---------------- > > Chet Ensign > > Director of Standards Development and TC Administration > > OASIS: Advancing open standards for the information society > > http://www.oasis-open.org > > > > Primary: +1 973-378-3472 > > Mobile: +1 201-341-1393 > > > > Follow OASIS on: > > LinkedIn: http://linkd.in/OASISopen > > Twitter: http://twitter.com/OASISopen > > Facebook: http://facebook.com/oasis.open > > > > > > > > > > -- > > > > /chet > > ---------------- > > Chet Ensign > > Director of Standards Development and TC Administration > > OASIS: Advancing open standards for the information society > > http://www.oasis-open.org > > > > Primary: +1 973-378-3472 > > Mobile: +1 201-341-1393 > > > > Follow OASIS on: > > LinkedIn: http://linkd.in/OASISopen > > Twitter: http://twitter.com/OASISopen > > Facebook: http://facebook.com/oasis.open > > > > -- > Jeff Mischkinsky > jeff.mischkinsky@oracle.com > Sr. Director, Oracle Fusion Middleware +1(650)506- > 1975 > and Web Services Standards 500 Oracle > Parkway, M/S 2OP9 > Oracle Redwood Shores, CA 94065 > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >

We removed C*Ds from the DCR section because we argued that a TC could always produce another draft. However, what we didn't do was to examine the inter-dependency of this rationale with the 15 public review for any change (aside from 2.18(6) changes), and we are seeing some of that interplay here. I think if a TC can show that a normative reference has not been materially changed i.e. only a status change has been made - reflected by the changes permissible in section 2.18(6)- they (or TC Admin) should be able to update the reference to that changed version. It should be easy to track if only 2.18(6) changes have been made. Martin. >
Original Message----- > From: Jeff Mischkinsky > Sent: 09 August 2011 03:01 > To: Chet Ensign > Cc: Patil, Sanjay; Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; > Paul Knight; Robin Cover > Subject: [tab] Re: [opencsa-liaison] Reference dependencies in various SCA > specs > > we can also allocate some time in Process Committee if that would be > desireable/easier. > > FWIW I think the problem is that the SCA TCs are not really completely > independent of each other. (I think of them as "almost separable".) > When we were first developing SCA we discussed whether we should have > one big TC or break things up to make development more manageable > realizing that the trade-off was that we would have mutual dependencies. > > That said i'm not sure the real issue is independent TCs. The mutual > dependencies would exist even if there was one TC. Having multiple TCs > makes it more complicated because its harder to coordinate > simultaneous votes on mutually dependent specs across TCs. I'm trying > to remember why we don't allow DCR's for CSD's. I *think* it might be > because we thought that since these were "only drafts", it was ok if > there were some inconsistencies/bugs and not worth the effort to allow > DCR's. > > The suggestion to allow TC's to decide if a change is not "substantive > enough" is that we were never able to agree on a definition of what > "enough" meant and TCs will almost always declare a change to be non- > substantive, regardless. > > Actually we already have that issue on the Process Committee's agenda > as part of figuring out if the requirement of new PRs for any change > is creating too many PRs. > > cheers, > jeff > > On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: > > > Mike, Sanjay - Actually, before launching on a broad chat, I think > > it would make more sense for us to talk and frame the problem to be > > solved so that conversation can be productive. Can I set up a call > > with both of you, maybe for Wednesday or Thursday? That will give me > > some time to draft a first pass at a problem statement that we can > > use to set up productive discussion with others. > > > > /chet > > > > On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay <sanjay.patil@sap.com> > > wrote: > > I think it makes a lot of sense to have a conference call to jointly > > define the problem and brainstorm the potentially solutions. > > However, scheduling a call with the many interested parties from the > > various time zones might become tricky. One option may be to check > > with the SCA Assembly TC chairs if they would be ok to allocate some > > of their weekly meeting time (Tue 8 AM PST) for this topic (assuming > > that Chet and other concerned OASIS staff / TAB members can make > > it). I believe that most of the SCA TC chairs are also members of > > the SCA Assembly TC and moreover the SCA TCs typically look forward > > to the SCA Assembly TC to resolve such cross-cutting issues and set > > the precedent. Mike/Martin, any thoughts in this regard? > > > > > > > > Sanjay > > > > > > > > From: Chet Ensign [ mailto:chet.ensign@oasis-open.org ] > > Sent: Monday, August 08, 2011 3:20 PM > > To: Patil, Sanjay > > Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul > > Knight; Robin Cover > > Subject: Re: [opencsa-liaison] Reference dependencies in various SCA > > specs > > > > > > > > Sanjay, Mike et al - We started a discussion on this subject at the > > TAB F2F and it is on our agenda. If you all would like, I would like > > to schedule a conference call so that we can discuss together and ... > > > > > > > > - Jointly define the problem(s) - typically the most difficult part > > of any of these conversations <grin> > > > > - Discuss what limitations of the current process / rules contribute > > to the problem(s) > > > > - Brainstorm possible modifications that could resolve the problem(s) > > > > > > > > Is that something you all are interested in doing? > > > > Best, > > > > > > > > /chet > > > > On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay <sanjay.patil@sap.com> > > wrote: > > > > > > > > Do other TC chairs have any further viewpoints on this topic? > > > > > > > > Since the resolution of this issue may involve changes to procedures > > involving the TC Admin (and potentially the TC process!), we need to > > decide how to take this issue forward. At the minimum, I think we > > should inform the TC Admin about our opinions and start the > > discussion. I am taking the liberty to copy Chet Ensign on this > > email thread to set the ball rolling. > > > > > > > > Best wishes, > > > > Sanjay > > > > > > > > From: Mike Edwards [ mailto:mike_edwards@uk.ibm.com ] > > Sent: Wednesday, August 03, 2011 1:33 AM > > To: Patil, Sanjay > > Cc: Anish Karmarkar; OASIS Liaison > > Subject: RE: [opencsa-liaison] Reference dependencies in various SCA > > specs > > > > > > > > > > Sanjay, > > > > I agree with your views. > > > > In the latest round of changes, for example, I think that Assembly > > is not affected by the changes to the > > other specifications (Policy, WS-Binding, Java...), even though > > those changes are normative. > > > > As a result, in my opinion, updating the Assembly spec to reference > > the latest CSDs of the other specs > > is a purely editorial process. > > > > Each TC may need to take a vote that agrees this for any particular > > spec, but once that vote has > > taken place, the update should be purely mechanical. No new public > > reviews are required. > > > > > > Yours, Mike > > > > Dr Mike Edwards > > > > Mail Point 137, Hursley Park > > > > <image001.gif> > > > > STSM > > > > Winchester, Hants SO21 2JN > > > > SCA, Cloud Computing & Services Standards > > > > United Kingdom > > > > Co-Chair OASIS SCA Assembly TC > > > > > > > > Chair UK ISO SC38 mirror committee (Cloud & SOA) > > > > > > > > IBM Software Group > > > > > > > > Phone: > > > > +44-1962 818014 > > > > > > > > Mobile: > > > > +44-7802-467431 (274097) > > > > > > > > e-mail: > > > > mike_edwards@uk.ibm.com > > > > > > > > > > > > > > > > > > > > > > From: > > > > "Patil, Sanjay" <sanjay.patil@sap.com> > > > > To: > > > > Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa- > liaison@lists.oasis-open.org > > > > > > > Date: > > > > 02/08/2011 17:56 > > > > Subject: > > > > RE: [opencsa-liaison] Reference dependencies in various SCA specs > > > > > > > > > > > > > > > > I think the option 3 provides the required solution while retaining > > the independence for the TCs to decide and follow their own > > schedule. During CSD publication and PR, specs can make references > > to the existing source material as of that time. Later, it should be > > allowed to update the references without having to go for another > > round of PR. I think it is reasonable to trust the TCs in making a > > determination about whether a change in a reference is significant > > enough to require another round of PR or not. > > > > Sanjay > > > > > >
Original Message----- > > From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] > > Sent: Tuesday, August 02, 2011 9:22 AM > > To: OASIS Liaison > > Subject: [opencsa-liaison] Reference dependencies in various SCA specs > > > > As we all know, specs in all the SCA TCs have dependencies on each > > other. For example, Assembly has a normative reference to Policy and > > WS-Binding. To conform to Assembly one has to conform to Policy and > > WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on > > Assembly/Policy. The dependency graph is cyclic. > > > > A similar problem exists in SCA-J TC but without any cycles [1]. > > > > OASIS TC process solves this problem of cyclic references by using > > designated cross references [2]. Unfortunately, CSDs cannot use this > > mechanism as the process explicitly excludes it. So, two specs A and B > > that depend on each other, will be in an infinite loop wrt updating > > their normative references. Further compounding the problem (but is an > > independent issue) is the fact that the new process requires at least > > 15-days PR for any change (except the changes on the front page). So > > any > > time spec A or B is updated to update its normative reference it has > > to > > be PRed. > > > > I see three possible solutions to this: > > 1) Fix the process to allow DCRs for CSDs (this is the only long term > > solution, I think). > > 2) Use the solution in [1] where spec A instead of using WDXX > > reference > > of B, uses the CSDYY reference of B. Where CSDYY is the what will > > happen > > to WDXX when the TC Admin processes the request for WDXX to be > > published > > as CSD. This means that the CSDs of A and B should be coordinated to > > go > > in the TC Admin queue around the same time. > > 3) Get TC admin to update normative references when there is no > > material > > change. For example, in (2) above, WDXX and CSDYY are going to be > > identical specs except for the front page. If spec A references WDXX, > > the TC admin should be able to update that reference to CSDYY. A > > similar > > update would have to be done to spec B. > > > > -Anish > > -- > > > > [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html > > [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > > PO6 3AU > > > > > > > > > > > > > > > > > > -- > > > > /chet > > ---------------- > > Chet Ensign > > Director of Standards Development and TC Administration > > OASIS: Advancing open standards for the information society > > http://www.oasis-open.org > > > > Primary: +1 973-378-3472 > > Mobile: +1 201-341-1393 > > > > Follow OASIS on: > > LinkedIn: http://linkd.in/OASISopen > > Twitter: http://twitter.com/OASISopen > > Facebook: http://facebook.com/oasis.open > > > > > > > > > > -- > > > > /chet > > ---------------- > > Chet Ensign > > Director of Standards Development and TC Administration > > OASIS: Advancing open standards for the information society > > http://www.oasis-open.org > > > > Primary: +1 973-378-3472 > > Mobile: +1 201-341-1393 > > > > Follow OASIS on: > > LinkedIn: http://linkd.in/OASISopen > > Twitter: http://twitter.com/OASISopen > > Facebook: http://facebook.com/oasis.open > > > > -- > Jeff Mischkinsky > jeff.mischkinsky@oracle.com > Sr. Director, Oracle Fusion Middleware +1(650)506- > 1975 > and Web Services Standards 500 Oracle > Parkway, M/S 2OP9 > Oracle Redwood Shores, CA 94065 > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >

Jeff et al - I'll draft this up into a note to send the the BPC mailing list. This is an opportunity for people to comment on the problem statement and make sure I have correctly captured and characterized both the problem and the proposed solution. The problem being raised (and thank you Sanjay and Mike for bumping it up a notch) is a narrow one: - A given TC has a Working Draft (WD) approved and submitted for publication as a Committee Specification Draft (CSD). This WD contains references to other approved WD’s that will, at some point in the near future, be approved and published as CSD's. - The TC wants to proceed with publication of their CSD with the references to the approved WD's and have TC Administration update the references in the published CSD at a later date from approved WD to CSD when the referenced specifications are themselves published. - In addition, they want this done without triggering a 15 day public review of the updated CSD. - This situation would be addressed by TC Process section 2.19, Designated Cross Reference Changes and by section 2.18, Work Product Quality item (6) Allowed Changes *if* section 2.19 applied at the CSD stage of a specification. Right now, 2.19 only applies to approvals for Committee Specification and above. The solution being proposed is to allow section 2.19 to apply to CSD approvals as well as CS approvals. (Note for the TC's to consider: as currently constructed, application of section 2.19 will result in publication of the referencing CSD being held up until all the cross-referenced specifications are published. To proceed with immediate publishing of the CSD and subsequent updates to the references requires additional changes to section 2.19.) In addition, we need to answer a second question this raises: what cross references are specifically meant in 2.19: 1. The references in the Related Work section of the cover pages to the specification only? 2. That plus the cross references in the Normative / Non-Normative References section of the specification body? (Meaning that TC Administration would be responsible for making changes with the content produced by the TC.) 3. *Any* cross reference anywhere in the narrative specification document? 4. *Any* cross reference anywhere in *any* component of the complete specification? I ask because I have had other TC's argue that it means item #4. Please provide any comments on this. Jeff, I can send the above to board-process-committee@ if you'd like. Best, /chet On Tue, Aug 9, 2011 at 9:57 AM, Martin Chapman <MARTIN.CHAPMAN@oracle.com> wrote: > We removed C*Ds from the DCR section because we argued that a TC could always produce another draft. However, what we didn't do was to examine the inter-dependency of this rationale with the 15 public review for any change (aside from 2.18(6) changes), and we are seeing some of that interplay here. > > I think if a TC can show that a normative reference has not been materially changed i.e. only a status change has been made - reflected by the changes permissible in section 2.18(6)- they (or TC Admin) should be able to update the reference to that changed version. It should be easy to track if only 2.18(6) changes have been made. > > Martin. > >>
Original Message----- >> From: Jeff Mischkinsky >> Sent: 09 August 2011 03:01 >> To: Chet Ensign >> Cc: Patil, Sanjay; Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; >> Paul Knight; Robin Cover >> Subject: [tab] Re: [opencsa-liaison] Reference dependencies in various SCA >> specs >> >> we can also allocate some time in Process Committee if that would be >> desireable/easier. >> >> FWIW I think the problem is that the SCA TCs are not really completely >> independent of each other. (I think of them as "almost separable".) >> When we were first developing SCA we discussed whether we should have >> one big TC or break things up to make development more manageable >> realizing that the trade-off was that we would have mutual dependencies. >> >> That said i'm not sure the real issue is independent TCs. The mutual >> dependencies would exist even if there was one TC. Having multiple TCs >> makes it more complicated because its harder to coordinate >> simultaneous votes on mutually dependent specs across TCs. I'm trying >> to remember why we don't allow DCR's for CSD's. I *think* it might be >> because we thought that since these were "only drafts", it was ok if >> there were some inconsistencies/bugs and not worth the effort to allow >> DCR's. >> >> The suggestion to allow TC's to decide if a change is not "substantive >> enough" is that we were never able to agree on a definition of what >> "enough" meant and TCs will almost always declare a change to be non- >> substantive, regardless. >> >> Actually we already have that issue on the Process Committee's agenda >> as part of figuring out if the requirement of new PRs for any change >> is creating too many PRs. >> >> cheers, >>    jeff >> >> On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: >> >> > Mike, Sanjay - Actually, before launching on a broad chat, I think >> > it would make more sense for us to talk and frame the problem to be >> > solved so that conversation can be productive. Can I set up a call >> > with both of you, maybe for Wednesday or Thursday? That will give me >> > some time to draft a first pass at a problem statement that we can >> > use to set up productive discussion with others. >> > >> > /chet >> > >> > On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay <sanjay.patil@sap.com> >> > wrote: >> > I think it makes a lot of sense to have a conference call to jointly >> > define the problem and brainstorm the potentially solutions. >> > However, scheduling a call with the many interested parties from the >> > various time zones might become tricky. One option may be to check >> > with the SCA Assembly TC chairs if they would be ok to allocate some >> > of their weekly meeting time (Tue 8 AM PST) for this topic (assuming >> > that Chet and other concerned OASIS staff / TAB members can make >> > it). I believe that most of the SCA TC chairs are also members of >> > the SCA Assembly TC and moreover the SCA TCs typically look forward >> > to the SCA Assembly TC to resolve such cross-cutting issues and set >> > the precedent. Mike/Martin, any thoughts in this regard? >> > >> > >> > >> > Sanjay >> > >> > >> > >> > From: Chet Ensign [ mailto:chet.ensign@oasis-open.org ] >> > Sent: Monday, August 08, 2011 3:20 PM >> > To: Patil, Sanjay >> > Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul >> > Knight; Robin Cover >> > Subject: Re: [opencsa-liaison] Reference dependencies in various SCA >> > specs >> > >> > >> > >> > Sanjay, Mike et al - We started a discussion on this subject at the >> > TAB F2F and it is on our agenda. If you all would like, I would like >> > to schedule a conference call so that we can discuss together and ... >> > >> > >> > >> > - Jointly define the problem(s) - typically the most difficult part >> > of any of these conversations <grin> >> > >> > - Discuss what limitations of the current process / rules contribute >> > to the problem(s) >> > >> > - Brainstorm possible modifications that could resolve the problem(s) >> > >> > >> > >> > Is that something you all are interested in doing? >> > >> > Best, >> > >> > >> > >> > /chet >> > >> > On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay <sanjay.patil@sap.com> >> > wrote: >> > >> > >> > >> > Do other TC chairs have any further viewpoints on this topic? >> > >> > >> > >> > Since the resolution of this issue may involve changes to procedures >> > involving the TC Admin (and potentially the TC process!), we need to >> > decide how to take this issue forward. At the minimum, I think we >> > should inform the TC Admin about our opinions and start the >> > discussion. I am taking the liberty to copy Chet Ensign on this >> > email thread to set the ball rolling. >> > >> > >> > >> > Best wishes, >> > >> > Sanjay >> > >> > >> > >> > From: Mike Edwards [ mailto:mike_edwards@uk.ibm.com ] >> > Sent: Wednesday, August 03, 2011 1:33 AM >> > To: Patil, Sanjay >> > Cc: Anish Karmarkar; OASIS Liaison >> > Subject: RE: [opencsa-liaison] Reference dependencies in various SCA >> > specs >> > >> > >> > >> > >> > Sanjay, >> > >> > I agree with your views. >> > >> > In the latest round of changes, for example, I think that Assembly >> > is not affected by the changes to the >> > other specifications (Policy, WS-Binding, Java...), even though >> > those changes are normative. >> > >> > As a result, in my opinion, updating the Assembly spec to reference >> > the latest CSDs of the other specs >> > is a purely editorial process. >> > >> > Each TC may need to take a vote that agrees this for any particular >> > spec, but once that vote has >> > taken place, the update should be purely mechanical.  No new public >> > reviews are required. >> > >> > >> > Yours, Mike >> > >> > Dr Mike Edwards >> > >> >  Mail Point 137, Hursley Park >> > >> > <image001.gif> >> > >> > STSM >> > >> >  Winchester, Hants SO21 2JN >> > >> > SCA, Cloud Computing & Services Standards >> > >> >  United Kingdom >> > >> > Co-Chair OASIS SCA Assembly TC >> > >> > >> > >> > Chair UK ISO SC38 mirror committee (Cloud & SOA) >> > >> > >> > >> > IBM Software Group >> > >> > >> > >> > Phone: >> > >> > +44-1962 818014 >> > >> > >> > >> > Mobile: >> > >> > +44-7802-467431 (274097) >> > >> > >> > >> > e-mail: >> > >> > mike_edwards@uk.ibm.com >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > From: >> > >> > "Patil, Sanjay" <sanjay.patil@sap.com> >> > >> > To: >> > >> > Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa- >> liaison@lists.oasis-open.org >> > > >> > >> > Date: >> > >> > 02/08/2011 17:56 >> > >> > Subject: >> > >> > RE: [opencsa-liaison] Reference dependencies in various SCA specs >> > >> > >> > >> > >> > >> > >> > >> > I think the option 3 provides the required solution while retaining >> > the independence for the TCs to decide and follow their own >> > schedule. During CSD publication and PR, specs can make references >> > to the existing source material as of that time. Later, it should be >> > allowed to update the references without having to go for another >> > round of PR. I think it is reasonable to trust the TCs in making a >> > determination about whether a change in a reference is significant >> > enough to require another round of PR or not. >> > >> > Sanjay >> > >> > >> >
Original Message----- >> > From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] >> > Sent: Tuesday, August 02, 2011 9:22 AM >> > To: OASIS Liaison >> > Subject: [opencsa-liaison] Reference dependencies in various SCA specs >> > >> > As we all know, specs in all the SCA TCs have dependencies on each >> > other. For example, Assembly has a normative reference to Policy and >> > WS-Binding. To conform to Assembly one has to conform to Policy and >> > WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on >> > Assembly/Policy. The dependency graph is cyclic. >> > >> > A similar problem exists in SCA-J TC but without any cycles [1]. >> > >> > OASIS TC process solves this problem of cyclic references by using >> > designated cross references [2]. Unfortunately, CSDs cannot use this >> > mechanism as the process explicitly excludes it. So, two specs A and B >> > that depend on each other, will be in an infinite loop wrt updating >> > their normative references. Further compounding the problem (but is an >> > independent issue) is the fact that the new process requires at least >> > 15-days PR for any change (except the changes on the front page). So >> > any >> > time spec A or B is updated to update its normative reference it has >> > to >> > be PRed. >> > >> > I see three possible solutions to this: >> > 1) Fix the process to allow DCRs for CSDs (this is the only long term >> > solution, I think). >> > 2) Use the solution in [1] where spec A instead of using WDXX >> > reference >> > of B, uses the CSDYY reference of B. Where CSDYY is the what will >> > happen >> > to WDXX when the TC Admin processes the request for WDXX to be >> > published >> > as CSD. This means that the CSDs of A and B should be coordinated to >> > go >> > in the TC Admin queue around the same time. >> > 3) Get TC admin to update normative references when there is no >> > material >> > change. For example, in (2) above, WDXX and CSDYY are going to be >> > identical specs except for the front page. If spec A references WDXX, >> > the TC admin should be able to update that reference to CSDYY. A >> > similar >> > update would have to be done to spec B. >> > >> > -Anish >> > -- >> > >> > [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html >> > [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs >> > >> > --------------------------------------------------------------------- >> > To unsubscribe from this mail list, you must leave the OASIS TC that >> > generates this mail.  Follow this link to all your TCs in OASIS at: >> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > >> > >> > >> > >> > >> > >> > >> > Unless stated otherwise above: >> > IBM United Kingdom Limited - Registered in England and Wales with >> > number 741598. >> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> > PO6 3AU >> > >> > >> > >> > >> > >> > >> > >> > >> > -- >> > >> > /chet >> > ---------------- >> > Chet Ensign >> > Director of Standards Development and TC Administration >> > OASIS: Advancing open standards for the information society >> > http://www.oasis-open.org >> > >> > Primary: +1 973-378-3472 >> > Mobile: +1 201-341-1393 >> > >> > Follow OASIS on: >> > LinkedIn:     http://linkd.in/OASISopen >> > Twitter:         http://twitter.com/OASISopen >> > Facebook:   http://facebook.com/oasis.open >> > >> > >> > >> > >> > -- >> > >> > /chet >> > ---------------- >> > Chet Ensign >> > Director of Standards Development and TC Administration >> > OASIS: Advancing open standards for the information society >> > http://www.oasis-open.org >> > >> > Primary: +1 973-378-3472 >> > Mobile: +1 201-341-1393 >> > >> > Follow OASIS on: >> > LinkedIn:     http://linkd.in/OASISopen >> > Twitter:         http://twitter.com/OASISopen >> > Facebook:   http://facebook.com/oasis.open >> > >> >> -- >> Jeff Mischkinsky >>       jeff.mischkinsky@oracle.com >> Sr. Director, Oracle Fusion Middleware                                +1(650)506- >> 1975 >>       and Web Services Standards                              500 Oracle >> Parkway, M/S 2OP9 >> Oracle                                                                Redwood Shores, CA 94065 >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail.  Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

Jeff et al - I'll draft this up into a note to send the the BPC mailing list. This is an opportunity for people to comment on the problem statement and make sure I have correctly captured and characterized both the problem and the proposed solution. The problem being raised (and thank you Sanjay and Mike for bumping it up a notch) is a narrow one: - A given TC has a Working Draft (WD) approved and submitted for publication as a Committee Specification Draft (CSD). This WD contains references to other approved WD’s that will, at some point in the near future, be approved and published as CSD's. - The TC wants to proceed with publication of their CSD with the references to the approved WD's and have TC Administration update the references in the published CSD at a later date from approved WD to CSD when the referenced specifications are themselves published. - In addition, they want this done without triggering a 15 day public review of the updated CSD. - This situation would be addressed by TC Process section 2.19, Designated Cross Reference Changes and by section 2.18, Work Product Quality item (6) Allowed Changes *if* section 2.19 applied at the CSD stage of a specification. Right now, 2.19 only applies to approvals for Committee Specification and above. The solution being proposed is to allow section 2.19 to apply to CSD approvals as well as CS approvals. (Note for the TC's to consider: as currently constructed, application of section 2.19 will result in publication of the referencing CSD being held up until all the cross-referenced specifications are published. To proceed with immediate publishing of the CSD and subsequent updates to the references requires additional changes to section 2.19.) In addition, we need to answer a second question this raises: what cross references are specifically meant in 2.19: 1. The references in the Related Work section of the cover pages to the specification only? 2. That plus the cross references in the Normative / Non-Normative References section of the specification body? (Meaning that TC Administration would be responsible for making changes with the content produced by the TC.) 3. *Any* cross reference anywhere in the narrative specification document? 4. *Any* cross reference anywhere in *any* component of the complete specification? I ask because I have had other TC's argue that it means item #4. Please provide any comments on this. Jeff, I can send the above to board-process-committee@ if you'd like. Best, /chet On Tue, Aug 9, 2011 at 9:57 AM, Martin Chapman <MARTIN.CHAPMAN@oracle.com> wrote: > We removed C*Ds from the DCR section because we argued that a TC could always produce another draft. However, what we didn't do was to examine the inter-dependency of this rationale with the 15 public review for any change (aside from 2.18(6) changes), and we are seeing some of that interplay here. > > I think if a TC can show that a normative reference has not been materially changed i.e. only a status change has been made - reflected by the changes permissible in section 2.18(6)- they (or TC Admin) should be able to update the reference to that changed version. It should be easy to track if only 2.18(6) changes have been made. > > Martin. > >>
Original Message----- >> From: Jeff Mischkinsky >> Sent: 09 August 2011 03:01 >> To: Chet Ensign >> Cc: Patil, Sanjay; Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; >> Paul Knight; Robin Cover >> Subject: [tab] Re: [opencsa-liaison] Reference dependencies in various SCA >> specs >> >> we can also allocate some time in Process Committee if that would be >> desireable/easier. >> >> FWIW I think the problem is that the SCA TCs are not really completely >> independent of each other. (I think of them as "almost separable".) >> When we were first developing SCA we discussed whether we should have >> one big TC or break things up to make development more manageable >> realizing that the trade-off was that we would have mutual dependencies. >> >> That said i'm not sure the real issue is independent TCs. The mutual >> dependencies would exist even if there was one TC. Having multiple TCs >> makes it more complicated because its harder to coordinate >> simultaneous votes on mutually dependent specs across TCs. I'm trying >> to remember why we don't allow DCR's for CSD's. I *think* it might be >> because we thought that since these were "only drafts", it was ok if >> there were some inconsistencies/bugs and not worth the effort to allow >> DCR's. >> >> The suggestion to allow TC's to decide if a change is not "substantive >> enough" is that we were never able to agree on a definition of what >> "enough" meant and TCs will almost always declare a change to be non- >> substantive, regardless. >> >> Actually we already have that issue on the Process Committee's agenda >> as part of figuring out if the requirement of new PRs for any change >> is creating too many PRs. >> >> cheers, >>    jeff >> >> On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: >> >> > Mike, Sanjay - Actually, before launching on a broad chat, I think >> > it would make more sense for us to talk and frame the problem to be >> > solved so that conversation can be productive. Can I set up a call >> > with both of you, maybe for Wednesday or Thursday? That will give me >> > some time to draft a first pass at a problem statement that we can >> > use to set up productive discussion with others. >> > >> > /chet >> > >> > On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay <sanjay.patil@sap.com> >> > wrote: >> > I think it makes a lot of sense to have a conference call to jointly >> > define the problem and brainstorm the potentially solutions. >> > However, scheduling a call with the many interested parties from the >> > various time zones might become tricky. One option may be to check >> > with the SCA Assembly TC chairs if they would be ok to allocate some >> > of their weekly meeting time (Tue 8 AM PST) for this topic (assuming >> > that Chet and other concerned OASIS staff / TAB members can make >> > it). I believe that most of the SCA TC chairs are also members of >> > the SCA Assembly TC and moreover the SCA TCs typically look forward >> > to the SCA Assembly TC to resolve such cross-cutting issues and set >> > the precedent. Mike/Martin, any thoughts in this regard? >> > >> > >> > >> > Sanjay >> > >> > >> > >> > From: Chet Ensign [ mailto:chet.ensign@oasis-open.org ] >> > Sent: Monday, August 08, 2011 3:20 PM >> > To: Patil, Sanjay >> > Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul >> > Knight; Robin Cover >> > Subject: Re: [opencsa-liaison] Reference dependencies in various SCA >> > specs >> > >> > >> > >> > Sanjay, Mike et al - We started a discussion on this subject at the >> > TAB F2F and it is on our agenda. If you all would like, I would like >> > to schedule a conference call so that we can discuss together and ... >> > >> > >> > >> > - Jointly define the problem(s) - typically the most difficult part >> > of any of these conversations <grin> >> > >> > - Discuss what limitations of the current process / rules contribute >> > to the problem(s) >> > >> > - Brainstorm possible modifications that could resolve the problem(s) >> > >> > >> > >> > Is that something you all are interested in doing? >> > >> > Best, >> > >> > >> > >> > /chet >> > >> > On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay <sanjay.patil@sap.com> >> > wrote: >> > >> > >> > >> > Do other TC chairs have any further viewpoints on this topic? >> > >> > >> > >> > Since the resolution of this issue may involve changes to procedures >> > involving the TC Admin (and potentially the TC process!), we need to >> > decide how to take this issue forward. At the minimum, I think we >> > should inform the TC Admin about our opinions and start the >> > discussion. I am taking the liberty to copy Chet Ensign on this >> > email thread to set the ball rolling. >> > >> > >> > >> > Best wishes, >> > >> > Sanjay >> > >> > >> > >> > From: Mike Edwards [ mailto:mike_edwards@uk.ibm.com ] >> > Sent: Wednesday, August 03, 2011 1:33 AM >> > To: Patil, Sanjay >> > Cc: Anish Karmarkar; OASIS Liaison >> > Subject: RE: [opencsa-liaison] Reference dependencies in various SCA >> > specs >> > >> > >> > >> > >> > Sanjay, >> > >> > I agree with your views. >> > >> > In the latest round of changes, for example, I think that Assembly >> > is not affected by the changes to the >> > other specifications (Policy, WS-Binding, Java...), even though >> > those changes are normative. >> > >> > As a result, in my opinion, updating the Assembly spec to reference >> > the latest CSDs of the other specs >> > is a purely editorial process. >> > >> > Each TC may need to take a vote that agrees this for any particular >> > spec, but once that vote has >> > taken place, the update should be purely mechanical.  No new public >> > reviews are required. >> > >> > >> > Yours, Mike >> > >> > Dr Mike Edwards >> > >> >  Mail Point 137, Hursley Park >> > >> > <image001.gif> >> > >> > STSM >> > >> >  Winchester, Hants SO21 2JN >> > >> > SCA, Cloud Computing & Services Standards >> > >> >  United Kingdom >> > >> > Co-Chair OASIS SCA Assembly TC >> > >> > >> > >> > Chair UK ISO SC38 mirror committee (Cloud & SOA) >> > >> > >> > >> > IBM Software Group >> > >> > >> > >> > Phone: >> > >> > +44-1962 818014 >> > >> > >> > >> > Mobile: >> > >> > +44-7802-467431 (274097) >> > >> > >> > >> > e-mail: >> > >> > mike_edwards@uk.ibm.com >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > From: >> > >> > "Patil, Sanjay" <sanjay.patil@sap.com> >> > >> > To: >> > >> > Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa- >> liaison@lists.oasis-open.org >> > > >> > >> > Date: >> > >> > 02/08/2011 17:56 >> > >> > Subject: >> > >> > RE: [opencsa-liaison] Reference dependencies in various SCA specs >> > >> > >> > >> > >> > >> > >> > >> > I think the option 3 provides the required solution while retaining >> > the independence for the TCs to decide and follow their own >> > schedule. During CSD publication and PR, specs can make references >> > to the existing source material as of that time. Later, it should be >> > allowed to update the references without having to go for another >> > round of PR. I think it is reasonable to trust the TCs in making a >> > determination about whether a change in a reference is significant >> > enough to require another round of PR or not. >> > >> > Sanjay >> > >> > >> >
Original Message----- >> > From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] >> > Sent: Tuesday, August 02, 2011 9:22 AM >> > To: OASIS Liaison >> > Subject: [opencsa-liaison] Reference dependencies in various SCA specs >> > >> > As we all know, specs in all the SCA TCs have dependencies on each >> > other. For example, Assembly has a normative reference to Policy and >> > WS-Binding. To conform to Assembly one has to conform to Policy and >> > WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on >> > Assembly/Policy. The dependency graph is cyclic. >> > >> > A similar problem exists in SCA-J TC but without any cycles [1]. >> > >> > OASIS TC process solves this problem of cyclic references by using >> > designated cross references [2]. Unfortunately, CSDs cannot use this >> > mechanism as the process explicitly excludes it. So, two specs A and B >> > that depend on each other, will be in an infinite loop wrt updating >> > their normative references. Further compounding the problem (but is an >> > independent issue) is the fact that the new process requires at least >> > 15-days PR for any change (except the changes on the front page). So >> > any >> > time spec A or B is updated to update its normative reference it has >> > to >> > be PRed. >> > >> > I see three possible solutions to this: >> > 1) Fix the process to allow DCRs for CSDs (this is the only long term >> > solution, I think). >> > 2) Use the solution in [1] where spec A instead of using WDXX >> > reference >> > of B, uses the CSDYY reference of B. Where CSDYY is the what will >> > happen >> > to WDXX when the TC Admin processes the request for WDXX to be >> > published >> > as CSD. This means that the CSDs of A and B should be coordinated to >> > go >> > in the TC Admin queue around the same time. >> > 3) Get TC admin to update normative references when there is no >> > material >> > change. For example, in (2) above, WDXX and CSDYY are going to be >> > identical specs except for the front page. If spec A references WDXX, >> > the TC admin should be able to update that reference to CSDYY. A >> > similar >> > update would have to be done to spec B. >> > >> > -Anish >> > -- >> > >> > [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html >> > [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs >> > >> > --------------------------------------------------------------------- >> > To unsubscribe from this mail list, you must leave the OASIS TC that >> > generates this mail.  Follow this link to all your TCs in OASIS at: >> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > >> > >> > >> > >> > >> > >> > >> > Unless stated otherwise above: >> > IBM United Kingdom Limited - Registered in England and Wales with >> > number 741598. >> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> > PO6 3AU >> > >> > >> > >> > >> > >> > >> > >> > >> > -- >> > >> > /chet >> > ---------------- >> > Chet Ensign >> > Director of Standards Development and TC Administration >> > OASIS: Advancing open standards for the information society >> > http://www.oasis-open.org >> > >> > Primary: +1 973-378-3472 >> > Mobile: +1 201-341-1393 >> > >> > Follow OASIS on: >> > LinkedIn:     http://linkd.in/OASISopen >> > Twitter:         http://twitter.com/OASISopen >> > Facebook:   http://facebook.com/oasis.open >> > >> > >> > >> > >> > -- >> > >> > /chet >> > ---------------- >> > Chet Ensign >> > Director of Standards Development and TC Administration >> > OASIS: Advancing open standards for the information society >> > http://www.oasis-open.org >> > >> > Primary: +1 973-378-3472 >> > Mobile: +1 201-341-1393 >> > >> > Follow OASIS on: >> > LinkedIn:     http://linkd.in/OASISopen >> > Twitter:         http://twitter.com/OASISopen >> > Facebook:   http://facebook.com/oasis.open >> > >> >> -- >> Jeff Mischkinsky >>       jeff.mischkinsky@oracle.com >> Sr. Director, Oracle Fusion Middleware                                +1(650)506- >> 1975 >>       and Web Services Standards                              500 Oracle >> Parkway, M/S 2OP9 >> Oracle                                                                Redwood Shores, CA 94065 >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail.  Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

I will also flesh this out for the TAB. This avoids broader topic like cross-references to something that goes from v1.0 to v2.0 or references to specs completely outside of Oasis - all variations on the same problem. ---------- Forwarded message ---------- From: Chet Ensign <chet.ensign@oasis-open.org> Date: Tue, Aug 9, 2011 at 11:21 AM Subject: Re: [tab] Re: [opencsa-liaison] Reference dependencies in various SCA specs To: Martin Chapman <MARTIN.CHAPMAN@oracle.com> Cc: Jeff Mischkinsky <JEFF.MISCHKINSKY@oracle.com>, "Patil, Sanjay" <sanjay.patil@sap.com>, Mike Edwards <mike_edwards@uk.ibm.com>, Anish Karmarkar <ANISH.KARMARKAR@oracle.com>, OASIS Liaison <opencsa-liaison@lists.oasis-open.org>, OASIS TAB <tab@lists.oasis-open.org>, Paul Knight <paul.knight@oasis-open.org>, Robin Cover <robin@oasis-open.org> Jeff et al - I'll draft this up into a note to send the the BPC mailing list. This is an opportunity for people to comment on the problem statement and make sure I have correctly captured and characterized both the problem and the proposed solution. The problem being raised (and thank you Sanjay and Mike for bumping it up a notch) is a narrow one: - A given TC has a Working Draft (WD) approved and submitted for publication as a Committee Specification Draft (CSD). This WD contains references to other approved WD’s that will, at some point in the near future, be approved and published as CSD's. - The TC wants to proceed with publication of their CSD with the references to the approved WD's and have TC Administration update the references in the published CSD at a later date from approved WD to CSD when the referenced specifications are themselves published. - In addition, they want this done without triggering a 15 day public review of the updated CSD. - This situation would be addressed by TC Process section 2.19, Designated Cross Reference Changes and by section 2.18, Work Product Quality item (6) Allowed Changes *if* section 2.19 applied at the CSD stage of a specification. Right now, 2.19 only applies to approvals for Committee Specification and above. The solution being proposed is to allow section 2.19 to apply to CSD approvals as well as CS approvals. (Note for the TC's to consider: as currently constructed, application of section 2.19 will result in publication of the referencing CSD being held up until all the cross-referenced specifications are published. To proceed with immediate publishing of the CSD and subsequent updates to the references requires additional changes to section 2.19.) In addition, we need to answer a second question this raises: what cross references are specifically meant in 2.19: 1. The references in the Related Work section of the cover pages to the specification only? 2. That plus the cross references in the Normative / Non-Normative References section of the specification body? (Meaning that TC Administration would be responsible for making changes with the content produced by the TC.) 3. *Any* cross reference anywhere in the narrative specification document? 4. *Any* cross reference anywhere in *any* component of the complete specification? I ask because I have had other TC's argue that it means item #4. Please provide any comments on this. Jeff, I can send the above to board-process-committee@ if you'd like. Best, /chet On Tue, Aug 9, 2011 at 9:57 AM, Martin Chapman <MARTIN.CHAPMAN@oracle.com> wrote: > We removed C*Ds from the DCR section because we argued that a TC could always produce another draft. However, what we didn't do was to examine the inter-dependency of this rationale with the 15 public review for any change (aside from 2.18(6) changes), and we are seeing some of that interplay here. > > I think if a TC can show that a normative reference has not been materially changed i.e. only a status change has been made - reflected by the changes permissible in section 2.18(6)- they (or TC Admin) should be able to update the reference to that changed version. It should be easy to track if only 2.18(6) changes have been made. > > Martin. > >>
Original Message----- >> From: Jeff Mischkinsky >> Sent: 09 August 2011 03:01 >> To: Chet Ensign >> Cc: Patil, Sanjay; Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; >> Paul Knight; Robin Cover >> Subject: [tab] Re: [opencsa-liaison] Reference dependencies in various SCA >> specs >> >> we can also allocate some time in Process Committee if that would be >> desireable/easier. >> >> FWIW I think the problem is that the SCA TCs are not really completely >> independent of each other. (I think of them as "almost separable".) >> When we were first developing SCA we discussed whether we should have >> one big TC or break things up to make development more manageable >> realizing that the trade-off was that we would have mutual dependencies. >> >> That said i'm not sure the real issue is independent TCs. The mutual >> dependencies would exist even if there was one TC. Having multiple TCs >> makes it more complicated because its harder to coordinate >> simultaneous votes on mutually dependent specs across TCs. I'm trying >> to remember why we don't allow DCR's for CSD's. I *think* it might be >> because we thought that since these were "only drafts", it was ok if >> there were some inconsistencies/bugs and not worth the effort to allow >> DCR's. >> >> The suggestion to allow TC's to decide if a change is not "substantive >> enough" is that we were never able to agree on a definition of what >> "enough" meant and TCs will almost always declare a change to be non- >> substantive, regardless. >> >> Actually we already have that issue on the Process Committee's agenda >> as part of figuring out if the requirement of new PRs for any change >> is creating too many PRs. >> >> cheers, >>    jeff >> >> On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: >> >> > Mike, Sanjay - Actually, before launching on a broad chat, I think >> > it would make more sense for us to talk and frame the problem to be >> > solved so that conversation can be productive. Can I set up a call >> > with both of you, maybe for Wednesday or Thursday? That will give me >> > some time to draft a first pass at a problem statement that we can >> > use to set up productive discussion with others. >> > >> > /chet >> > >> > On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay <sanjay.patil@sap.com> >> > wrote: >> > I think it makes a lot of sense to have a conference call to jointly >> > define the problem and brainstorm the potentially solutions. >> > However, scheduling a call with the many interested parties from the >> > various time zones might become tricky. One option may be to check >> > with the SCA Assembly TC chairs if they would be ok to allocate some >> > of their weekly meeting time (Tue 8 AM PST) for this topic (assuming >> > that Chet and other concerned OASIS staff / TAB members can make >> > it). I believe that most of the SCA TC chairs are also members of >> > the SCA Assembly TC and moreover the SCA TCs typically look forward >> > to the SCA Assembly TC to resolve such cross-cutting issues and set >> > the precedent. Mike/Martin, any thoughts in this regard? >> > >> > >> > >> > Sanjay >> > >> > >> > >> > From: Chet Ensign [ mailto:chet.ensign@oasis-open.org ] >> > Sent: Monday, August 08, 2011 3:20 PM >> > To: Patil, Sanjay >> > Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul >> > Knight; Robin Cover >> > Subject: Re: [opencsa-liaison] Reference dependencies in various SCA >> > specs >> > >> > >> > >> > Sanjay, Mike et al - We started a discussion on this subject at the >> > TAB F2F and it is on our agenda. If you all would like, I would like >> > to schedule a conference call so that we can discuss together and ... >> > >> > >> > >> > - Jointly define the problem(s) - typically the most difficult part >> > of any of these conversations <grin> >> > >> > - Discuss what limitations of the current process / rules contribute >> > to the problem(s) >> > >> > - Brainstorm possible modifications that could resolve the problem(s) >> > >> > >> > >> > Is that something you all are interested in doing? >> > >> > Best, >> > >> > >> > >> > /chet >> > >> > On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay <sanjay.patil@sap.com> >> > wrote: >> > >> > >> > >> > Do other TC chairs have any further viewpoints on this topic? >> > >> > >> > >> > Since the resolution of this issue may involve changes to procedures >> > involving the TC Admin (and potentially the TC process!), we need to >> > decide how to take this issue forward. At the minimum, I think we >> > should inform the TC Admin about our opinions and start the >> > discussion. I am taking the liberty to copy Chet Ensign on this >> > email thread to set the ball rolling. >> > >> > >> > >> > Best wishes, >> > >> > Sanjay >> > >> > >> > >> > From: Mike Edwards [ mailto:mike_edwards@uk.ibm.com ] >> > Sent: Wednesday, August 03, 2011 1:33 AM >> > To: Patil, Sanjay >> > Cc: Anish Karmarkar; OASIS Liaison >> > Subject: RE: [opencsa-liaison] Reference dependencies in various SCA >> > specs >> > >> > >> > >> > >> > Sanjay, >> > >> > I agree with your views. >> > >> > In the latest round of changes, for example, I think that Assembly >> > is not affected by the changes to the >> > other specifications (Policy, WS-Binding, Java...), even though >> > those changes are normative. >> > >> > As a result, in my opinion, updating the Assembly spec to reference >> > the latest CSDs of the other specs >> > is a purely editorial process. >> > >> > Each TC may need to take a vote that agrees this for any particular >> > spec, but once that vote has >> > taken place, the update should be purely mechanical.  No new public >> > reviews are required. >> > >> > >> > Yours, Mike >> > >> > Dr Mike Edwards >> > >> >  Mail Point 137, Hursley Park >> > >> > <image001.gif> >> > >> > STSM >> > >> >  Winchester, Hants SO21 2JN >> > >> > SCA, Cloud Computing & Services Standards >> > >> >  United Kingdom >> > >> > Co-Chair OASIS SCA Assembly TC >> > >> > >> > >> > Chair UK ISO SC38 mirror committee (Cloud & SOA) >> > >> > >> > >> > IBM Software Group >> > >> > >> > >> > Phone: >> > >> > +44-1962 818014 >> > >> > >> > >> > Mobile: >> > >> > +44-7802-467431 (274097) >> > >> > >> > >> > e-mail: >> > >> > mike_edwards@uk.ibm.com >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > From: >> > >> > "Patil, Sanjay" <sanjay.patil@sap.com> >> > >> > To: >> > >> > Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa- >> liaison@lists.oasis-open.org >> > > >> > >> > Date: >> > >> > 02/08/2011 17:56 >> > >> > Subject: >> > >> > RE: [opencsa-liaison] Reference dependencies in various SCA specs >> > >> > >> > >> > >> > >> > >> > >> > I think the option 3 provides the required solution while retaining >> > the independence for the TCs to decide and follow their own >> > schedule. During CSD publication and PR, specs can make references >> > to the existing source material as of that time. Later, it should be >> > allowed to update the references without having to go for another >> > round of PR. I think it is reasonable to trust the TCs in making a >> > determination about whether a change in a reference is significant >> > enough to require another round of PR or not. >> > >> > Sanjay >> > >> > >> >
Original Message----- >> > From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] >> > Sent: Tuesday, August 02, 2011 9:22 AM >> > To: OASIS Liaison >> > Subject: [opencsa-liaison] Reference dependencies in various SCA specs >> > >> > As we all know, specs in all the SCA TCs have dependencies on each >> > other. For example, Assembly has a normative reference to Policy and >> > WS-Binding. To conform to Assembly one has to conform to Policy and >> > WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on >> > Assembly/Policy. The dependency graph is cyclic. >> > >> > A similar problem exists in SCA-J TC but without any cycles [1]. >> > >> > OASIS TC process solves this problem of cyclic references by using >> > designated cross references [2]. Unfortunately, CSDs cannot use this >> > mechanism as the process explicitly excludes it. So, two specs A and B >> > that depend on each other, will be in an infinite loop wrt updating >> > their normative references. Further compounding the problem (but is an >> > independent issue) is the fact that the new process requires at least >> > 15-days PR for any change (except the changes on the front page). So >> > any >> > time spec A or B is updated to update its normative reference it has >> > to >> > be PRed. >> > >> > I see three possible solutions to this: >> > 1) Fix the process to allow DCRs for CSDs (this is the only long term >> > solution, I think). >> > 2) Use the solution in [1] where spec A instead of using WDXX >> > reference >> > of B, uses the CSDYY reference of B. Where CSDYY is the what will >> > happen >> > to WDXX when the TC Admin processes the request for WDXX to be >> > published >> > as CSD. This means that the CSDs of A and B should be coordinated to >> > go >> > in the TC Admin queue around the same time. >> > 3) Get TC admin to update normative references when there is no >> > material >> > change. For example, in (2) above, WDXX and CSDYY are going to be >> > identical specs except for the front page. If spec A references WDXX, >> > the TC admin should be able to update that reference to CSDYY. A >> > similar >> > update would have to be done to spec B. >> > >> > -Anish >> > -- >> > >> > [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html >> > [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs >> > >> > --------------------------------------------------------------------- >> > To unsubscribe from this mail list, you must leave the OASIS TC that >> > generates this mail.  Follow this link to all your TCs in OASIS at: >> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > >> > >> > >> > >> > >> > >> > >> > Unless stated otherwise above: >> > IBM United Kingdom Limited - Registered in England and Wales with >> > number 741598. >> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> > PO6 3AU >> > >> > >> > >> > >> > >> > >> > >> > >> > -- >> > >> > /chet >> > ---------------- >> > Chet Ensign >> > Director of Standards Development and TC Administration >> > OASIS: Advancing open standards for the information society >> > http://www.oasis-open.org >> > >> > Primary: +1 973-378-3472 >> > Mobile: +1 201-341-1393 >> > >> > Follow OASIS on: >> > LinkedIn:     http://linkd.in/OASISopen >> > Twitter:         http://twitter.com/OASISopen >> > Facebook:   http://facebook.com/oasis.open >> > >> > >> > >> > >> > -- >> > >> > /chet >> > ---------------- >> > Chet Ensign >> > Director of Standards Development and TC Administration >> > OASIS: Advancing open standards for the information society >> > http://www.oasis-open.org >> > >> > Primary: +1 973-378-3472 >> > Mobile: +1 201-341-1393 >> > >> > Follow OASIS on: >> > LinkedIn:     http://linkd.in/OASISopen >> > Twitter:         http://twitter.com/OASISopen >> > Facebook:   http://facebook.com/oasis.open >> > >> >> -- >> Jeff Mischkinsky >>       jeff.mischkinsky@oracle.com >> Sr. Director, Oracle Fusion Middleware                                +1(650)506- >> 1975 >>       and Web Services Standards                              500 Oracle >> Parkway, M/S 2OP9 >> Oracle                                                                Redwood Shores, CA 94065 >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail.  Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

hi chet, It also seems to me, as you point out, that this issue has much broader applicability than just the SCA TCs, so i think we should formally raise and address this issue by the Process Committee. That said, getting input and discussion from a wider group is a good thing, and I don't mean to try to stifle that. We have enough on the process comm agenda for the next several weeks, so developing a well formed proposal out of band is probably also a good thing. Also, as martin noted, the TAB already has this on its agenda, so why don't we let it be the focus for the discussion for a while - with an occasional update to Process. I do note that cross posting across multiple oasis lists, for which different people have read/write permission could prove to be awkward -- and process is probably the most limited list which is an added complication. cheers, jeff On Aug 09, 2011, at 8:21 AM, Chet Ensign wrote: > Jeff et al - > > I'll draft this up into a note to send the the BPC mailing list. This > is an opportunity for people to comment on the problem statement and > make sure I have correctly captured and characterized both the problem > and the proposed solution. > > The problem being raised (and thank you Sanjay and Mike for bumping it > up a notch) is a narrow one: > > - A given TC has a Working Draft (WD) approved and submitted for > publication as a Committee Specification Draft (CSD). This WD contains > references to other approved WD’s that will, at some point in the near > future, be approved and published as CSD's. > > - The TC wants to proceed with publication of their CSD with the > references to the approved WD's and have TC Administration update the > references in the published CSD at a later date from approved WD to > CSD when the referenced specifications are themselves published. > > - In addition, they want this done without triggering a 15 day public > review of the updated CSD. > > - This situation would be addressed by TC Process section 2.19, > Designated Cross Reference Changes and by section 2.18, Work Product > Quality item (6) Allowed Changes *if* section 2.19 applied at the CSD > stage of a specification. Right now, 2.19 only applies to approvals > for Committee Specification and above. > > The solution being proposed is to allow section 2.19 to apply to CSD > approvals as well as CS approvals. (Note for the TC's to consider: as > currently constructed, application of section 2.19 will result in > publication of the referencing CSD being held up until all the > cross-referenced specifications are published. To proceed with > immediate publishing of the CSD and subsequent updates to the > references requires additional changes to section 2.19.) > > In addition, we need to answer a second question this raises: what > cross references are specifically meant in 2.19: > > 1. The references in the Related Work section of the cover pages to > the specification only? > 2. That plus the cross references in the Normative / Non-Normative > References section of the specification body? (Meaning that TC > Administration would be responsible for making changes with the > content produced by the TC.) > 3. *Any* cross reference anywhere in the narrative specification > document? > 4. *Any* cross reference anywhere in *any* component of the complete > specification? > > I ask because I have had other TC's argue that it means item #4. > > Please provide any comments on this. Jeff, I can send the above to > board-process-committee@ if you'd like. > > Best, > > /chet > > > > > > On Tue, Aug 9, 2011 at 9:57 AM, Martin Chapman > <MARTIN.CHAPMAN@oracle.com> wrote: >> We removed C*Ds from the DCR section because we argued that a TC >> could always produce another draft. However, what we didn't do was >> to examine the inter-dependency of this rationale with the 15 >> public review for any change (aside from 2.18(6) changes), and we >> are seeing some of that interplay here. >> >> I think if a TC can show that a normative reference has not been >> materially changed i.e. only a status change has been made - >> reflected by the changes permissible in section 2.18(6)- they (or >> TC Admin) should be able to update the reference to that changed >> version. It should be easy to track if only 2.18(6) changes have >> been made. >> >> Martin. >> >>>
Original Message----- >>> From: Jeff Mischkinsky >>> Sent: 09 August 2011 03:01 >>> To: Chet Ensign >>> Cc: Patil, Sanjay; Mike Edwards; Anish Karmarkar; OASIS Liaison; >>> OASIS TAB; >>> Paul Knight; Robin Cover >>> Subject: [tab] Re: [opencsa-liaison] Reference dependencies in >>> various SCA >>> specs >>> >>> we can also allocate some time in Process Committee if that would be >>> desireable/easier. >>> >>> FWIW I think the problem is that the SCA TCs are not really >>> completely >>> independent of each other. (I think of them as "almost separable".) >>> When we were first developing SCA we discussed whether we should >>> have >>> one big TC or break things up to make development more manageable >>> realizing that the trade-off was that we would have mutual >>> dependencies. >>> >>> That said i'm not sure the real issue is independent TCs. The mutual >>> dependencies would exist even if there was one TC. Having multiple >>> TCs >>> makes it more complicated because its harder to coordinate >>> simultaneous votes on mutually dependent specs across TCs. I'm >>> trying >>> to remember why we don't allow DCR's for CSD's. I *think* it might >>> be >>> because we thought that since these were "only drafts", it was ok if >>> there were some inconsistencies/bugs and not worth the effort to >>> allow >>> DCR's. >>> >>> The suggestion to allow TC's to decide if a change is not >>> "substantive >>> enough" is that we were never able to agree on a definition of what >>> "enough" meant and TCs will almost always declare a change to be >>> non- >>> substantive, regardless. >>> >>> Actually we already have that issue on the Process Committee's >>> agenda >>> as part of figuring out if the requirement of new PRs for any change >>> is creating too many PRs. >>> >>> cheers, >>> jeff >>> >>> On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: >>> >>>> Mike, Sanjay - Actually, before launching on a broad chat, I think >>>> it would make more sense for us to talk and frame the problem to be >>>> solved so that conversation can be productive. Can I set up a call >>>> with both of you, maybe for Wednesday or Thursday? That will give >>>> me >>>> some time to draft a first pass at a problem statement that we can >>>> use to set up productive discussion with others. >>>> >>>> /chet >>>> >>>> On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay >>>> <sanjay.patil@sap.com> >>>> wrote: >>>> I think it makes a lot of sense to have a conference call to >>>> jointly >>>> define the problem and brainstorm the potentially solutions. >>>> However, scheduling a call with the many interested parties from >>>> the >>>> various time zones might become tricky. One option may be to check >>>> with the SCA Assembly TC chairs if they would be ok to allocate >>>> some >>>> of their weekly meeting time (Tue 8 AM PST) for this topic >>>> (assuming >>>> that Chet and other concerned OASIS staff / TAB members can make >>>> it). I believe that most of the SCA TC chairs are also members of >>>> the SCA Assembly TC and moreover the SCA TCs typically look forward >>>> to the SCA Assembly TC to resolve such cross-cutting issues and set >>>> the precedent. Mike/Martin, any thoughts in this regard? >>>> >>>> >>>> >>>> Sanjay >>>> >>>> >>>> >>>> From: Chet Ensign [ mailto:chet.ensign@oasis-open.org ] >>>> Sent: Monday, August 08, 2011 3:20 PM >>>> To: Patil, Sanjay >>>> Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul >>>> Knight; Robin Cover >>>> Subject: Re: [opencsa-liaison] Reference dependencies in various >>>> SCA >>>> specs >>>> >>>> >>>> >>>> Sanjay, Mike et al - We started a discussion on this subject at the >>>> TAB F2F and it is on our agenda. If you all would like, I would >>>> like >>>> to schedule a conference call so that we can discuss together >>>> and ... >>>> >>>> >>>> >>>> - Jointly define the problem(s) - typically the most difficult part >>>> of any of these conversations <grin> >>>> >>>> - Discuss what limitations of the current process / rules >>>> contribute >>>> to the problem(s) >>>> >>>> - Brainstorm possible modifications that could resolve the >>>> problem(s) >>>> >>>> >>>> >>>> Is that something you all are interested in doing? >>>> >>>> Best, >>>> >>>> >>>> >>>> /chet >>>> >>>> On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay >>>> <sanjay.patil@sap.com> >>>> wrote: >>>> >>>> >>>> >>>> Do other TC chairs have any further viewpoints on this topic? >>>> >>>> >>>> >>>> Since the resolution of this issue may involve changes to >>>> procedures >>>> involving the TC Admin (and potentially the TC process!), we need >>>> to >>>> decide how to take this issue forward. At the minimum, I think we >>>> should inform the TC Admin about our opinions and start the >>>> discussion. I am taking the liberty to copy Chet Ensign on this >>>> email thread to set the ball rolling. >>>> >>>> >>>> >>>> Best wishes, >>>> >>>> Sanjay >>>> >>>> >>>> >>>> From: Mike Edwards [ mailto:mike_edwards@uk.ibm.com ] >>>> Sent: Wednesday, August 03, 2011 1:33 AM >>>> To: Patil, Sanjay >>>> Cc: Anish Karmarkar; OASIS Liaison >>>> Subject: RE: [opencsa-liaison] Reference dependencies in various >>>> SCA >>>> specs >>>> >>>> >>>> >>>> >>>> Sanjay, >>>> >>>> I agree with your views. >>>> >>>> In the latest round of changes, for example, I think that Assembly >>>> is not affected by the changes to the >>>> other specifications (Policy, WS-Binding, Java...), even though >>>> those changes are normative. >>>> >>>> As a result, in my opinion, updating the Assembly spec to reference >>>> the latest CSDs of the other specs >>>> is a purely editorial process. >>>> >>>> Each TC may need to take a vote that agrees this for any particular >>>> spec, but once that vote has >>>> taken place, the update should be purely mechanical. No new public >>>> reviews are required. >>>> >>>> >>>> Yours, Mike >>>> >>>> Dr Mike Edwards >>>> >>>> Mail Point 137, Hursley Park >>>> >>>> <image001.gif> >>>> >>>> STSM >>>> >>>> Winchester, Hants SO21 2JN >>>> >>>> SCA, Cloud Computing & Services Standards >>>> >>>> United Kingdom >>>> >>>> Co-Chair OASIS SCA Assembly TC >>>> >>>> >>>> >>>> Chair UK ISO SC38 mirror committee (Cloud & SOA) >>>> >>>> >>>> >>>> IBM Software Group >>>> >>>> >>>> >>>> Phone: >>>> >>>> +44-1962 818014 >>>> >>>> >>>> >>>> Mobile: >>>> >>>> +44-7802-467431 (274097) >>>> >>>> >>>> >>>> e-mail: >>>> >>>> mike_edwards@uk.ibm.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> From: >>>> >>>> "Patil, Sanjay" <sanjay.patil@sap.com> >>>> >>>> To: >>>> >>>> Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison >>>> <opencsa- >>> liaison@lists.oasis-open.org >>>>> >>>> >>>> Date: >>>> >>>> 02/08/2011 17:56 >>>> >>>> Subject: >>>> >>>> RE: [opencsa-liaison] Reference dependencies in various SCA specs >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I think the option 3 provides the required solution while retaining >>>> the independence for the TCs to decide and follow their own >>>> schedule. During CSD publication and PR, specs can make references >>>> to the existing source material as of that time. Later, it should >>>> be >>>> allowed to update the references without having to go for another >>>> round of PR. I think it is reasonable to trust the TCs in making a >>>> determination about whether a change in a reference is significant >>>> enough to require another round of PR or not. >>>> >>>> Sanjay >>>> >>>> >>>>
Original Message----- >>>> From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] >>>> Sent: Tuesday, August 02, 2011 9:22 AM >>>> To: OASIS Liaison >>>> Subject: [opencsa-liaison] Reference dependencies in various SCA >>>> specs >>>> >>>> As we all know, specs in all the SCA TCs have dependencies on each >>>> other. For example, Assembly has a normative reference to Policy >>>> and >>>> WS-Binding. To conform to Assembly one has to conform to Policy and >>>> WS-Binding. Policy in turn depends on Assembly. WS-Binding >>>> depends on >>>> Assembly/Policy. The dependency graph is cyclic. >>>> >>>> A similar problem exists in SCA-J TC but without any cycles [1]. >>>> >>>> OASIS TC process solves this problem of cyclic references by using >>>> designated cross references [2]. Unfortunately, CSDs cannot use >>>> this >>>> mechanism as the process explicitly excludes it. So, two specs A >>>> and B >>>> that depend on each other, will be in an infinite loop wrt updating >>>> their normative references. Further compounding the problem (but >>>> is an >>>> independent issue) is the fact that the new process requires at >>>> least >>>> 15-days PR for any change (except the changes on the front page). >>>> So >>>> any >>>> time spec A or B is updated to update its normative reference it >>>> has >>>> to >>>> be PRed. >>>> >>>> I see three possible solutions to this: >>>> 1) Fix the process to allow DCRs for CSDs (this is the only long >>>> term >>>> solution, I think). >>>> 2) Use the solution in [1] where spec A instead of using WDXX >>>> reference >>>> of B, uses the CSDYY reference of B. Where CSDYY is the what will >>>> happen >>>> to WDXX when the TC Admin processes the request for WDXX to be >>>> published >>>> as CSD. This means that the CSDs of A and B should be coordinated >>>> to >>>> go >>>> in the TC Admin queue around the same time. >>>> 3) Get TC admin to update normative references when there is no >>>> material >>>> change. For example, in (2) above, WDXX and CSDYY are going to be >>>> identical specs except for the front page. If spec A references >>>> WDXX, >>>> the TC admin should be able to update that reference to CSDYY. A >>>> similar >>>> update would have to be done to spec B. >>>> >>>> -Anish >>>> -- >>>> >>>> [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html >>>> [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this mail list, you must leave the OASIS TC >>>> that >>>> generates this mail. Follow this link to all your TCs in OASIS at: >>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with >>>> number 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>>> PO6 3AU >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> /chet >>>> ---------------- >>>> Chet Ensign >>>> Director of Standards Development and TC Administration >>>> OASIS: Advancing open standards for the information society >>>> http://www.oasis-open.org >>>> >>>> Primary: +1 973-378-3472 >>>> Mobile: +1 201-341-1393 >>>> >>>> Follow OASIS on: >>>> LinkedIn: http://linkd.in/OASISopen >>>> Twitter: http://twitter.com/OASISopen >>>> Facebook: http://facebook.com/oasis.open >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> /chet >>>> ---------------- >>>> Chet Ensign >>>> Director of Standards Development and TC Administration >>>> OASIS: Advancing open standards for the information society >>>> http://www.oasis-open.org >>>> >>>> Primary: +1 973-378-3472 >>>> Mobile: +1 201-341-1393 >>>> >>>> Follow OASIS on: >>>> LinkedIn: http://linkd.in/OASISopen >>>> Twitter: http://twitter.com/OASISopen >>>> Facebook: http://facebook.com/oasis.open >>>> >>> >>> -- >>> Jeff Mischkinsky >>> jeff.mischkinsky@oracle.com >>> Sr. Director, Oracle Fusion >>> Middleware +1(650)506- >>> 1975 >>> and Web Services Standards 500 >>> Oracle >>> Parkway, M/S 2OP9 >>> Oracle >>> >>> Redwood Shores, CA 94065 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this mail list, you must leave the OASIS TC that >>> generates this mail. Follow this link to all your TCs in OASIS at: >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>> >> > > > > -- > > /chet > ---------------- > Chet Ensign > Director of Standards Development and TC Administration > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-378-3472 > Mobile: +1 201-341-1393 > > Follow OASIS on: > LinkedIn: http://linkd.in/OASISopen > Twitter: http://twitter.com/OASISopen > Facebook: http://facebook.com/oasis.open -- Jeff Mischkinsky jeff.mischkinsky@oracle.com Sr. Director, Oracle Fusion Middleware +1(650)506-1975 and Web Services Standards 500 Oracle Parkway, M/S 2OP9 Oracle Redwood Shores, CA 94065

Thanks Jeff - makes sense. I will draft the problem statement for us to go over in the TAB first. On Tue, Aug 9, 2011 at 11:35 AM, Jeff Mischkinsky <JEFF.MISCHKINSKY@oracle.com> wrote: > hi chet, >  It also seems to me, as you point out, that this issue has much broader > applicability than just the SCA TCs, so i think we should formally raise and > address this issue by the Process Committee. That said, getting input and > discussion from a wider group is a good thing, and I don't mean to try to > stifle that. >   We have enough on the process comm agenda for the next several weeks, so > developing a well formed proposal out of band is probably also a good thing. > > Also, as martin noted, the TAB already has this on its agenda, so why don't > we let it be the focus for the discussion for a while - with an occasional > update to Process. > > I do note that cross posting across multiple oasis lists, for which > different people have read/write permission could prove to be awkward -- and > process is probably the most limited list which is an added complication. > > cheers, >  jeff > > On Aug 09, 2011, at 8:21 AM, Chet Ensign wrote: > >> Jeff et al - >> >> I'll draft this up into a note to send the the BPC mailing list. This >> is an opportunity for people to comment on the problem statement and >> make sure I have correctly captured and characterized both the problem >> and the proposed solution. >> >> The problem being raised (and thank you Sanjay and Mike for bumping it >> up a notch) is a narrow one: >> >> - A given TC has a Working Draft (WD) approved and submitted for >> publication as a Committee Specification Draft (CSD). This WD contains >> references to other approved WD’s that will, at some point in the near >> future, be approved and published as CSD's. >> >> - The TC wants to proceed with publication of their CSD with the >> references to the approved WD's and have TC Administration update the >> references in the published CSD at a later date from approved WD to >> CSD when the referenced specifications are themselves published. >> >> - In addition, they want this done without triggering a 15 day public >> review of the updated CSD. >> >> - This situation would be addressed by TC Process section 2.19, >> Designated Cross Reference Changes and by section 2.18, Work Product >> Quality item (6) Allowed Changes *if* section 2.19 applied at the CSD >> stage of a specification. Right now, 2.19 only applies to approvals >> for Committee Specification and above. >> >> The solution being proposed is to allow section 2.19 to apply to CSD >> approvals as well as CS approvals. (Note for the TC's to consider: as >> currently constructed, application of section 2.19 will result in >> publication of the referencing CSD being held up until all the >> cross-referenced specifications are published. To proceed with >> immediate publishing of the CSD and subsequent updates to the >> references requires additional changes to section 2.19.) >> >> In addition, we need to answer a second question this raises: what >> cross references are specifically meant in 2.19: >> >> 1. The references in the Related Work section of the cover pages to >> the specification only? >> 2. That plus the cross references in the Normative / Non-Normative >> References section of the specification body? (Meaning that TC >> Administration would be responsible for making changes with the >> content produced by the TC.) >> 3. *Any* cross reference anywhere in the narrative specification document? >> 4. *Any* cross reference anywhere in *any* component of the complete >> specification? >> >> I ask because I have had other TC's argue that it means item #4. >> >> Please provide any comments on this. Jeff, I can send the above to >> board-process-committee@ if you'd like. >> >> Best, >> >> /chet >> >> >> >> >> >> On Tue, Aug 9, 2011 at 9:57 AM, Martin Chapman >> <MARTIN.CHAPMAN@oracle.com> wrote: >>> >>> We removed C*Ds from the DCR section because we argued that a TC could >>> always produce another draft. However, what we didn't do was to examine the >>> inter-dependency of this rationale with the 15 public review for any change >>> (aside from 2.18(6) changes), and we are seeing some of that interplay here. >>> >>> I think if a TC can show that a normative reference has not been >>> materially changed i.e. only a status change has been made - reflected by >>> the changes permissible in section 2.18(6)- they (or TC Admin) should be >>> able to update the reference to that changed version. It should be easy to >>> track if only 2.18(6) changes have been made. >>> >>> Martin. >>> >>>>
Original Message----- >>>> From: Jeff Mischkinsky >>>> Sent: 09 August 2011 03:01 >>>> To: Chet Ensign >>>> Cc: Patil, Sanjay; Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS >>>> TAB; >>>> Paul Knight; Robin Cover >>>> Subject: [tab] Re: [opencsa-liaison] Reference dependencies in various >>>> SCA >>>> specs >>>> >>>> we can also allocate some time in Process Committee if that would be >>>> desireable/easier. >>>> >>>> FWIW I think the problem is that the SCA TCs are not really completely >>>> independent of each other. (I think of them as "almost separable".) >>>> When we were first developing SCA we discussed whether we should have >>>> one big TC or break things up to make development more manageable >>>> realizing that the trade-off was that we would have mutual dependencies. >>>> >>>> That said i'm not sure the real issue is independent TCs. The mutual >>>> dependencies would exist even if there was one TC. Having multiple TCs >>>> makes it more complicated because its harder to coordinate >>>> simultaneous votes on mutually dependent specs across TCs. I'm trying >>>> to remember why we don't allow DCR's for CSD's. I *think* it might be >>>> because we thought that since these were "only drafts", it was ok if >>>> there were some inconsistencies/bugs and not worth the effort to allow >>>> DCR's. >>>> >>>> The suggestion to allow TC's to decide if a change is not "substantive >>>> enough" is that we were never able to agree on a definition of what >>>> "enough" meant and TCs will almost always declare a change to be non- >>>> substantive, regardless. >>>> >>>> Actually we already have that issue on the Process Committee's agenda >>>> as part of figuring out if the requirement of new PRs for any change >>>> is creating too many PRs. >>>> >>>> cheers, >>>>   jeff >>>> >>>> On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: >>>> >>>>> Mike, Sanjay - Actually, before launching on a broad chat, I think >>>>> it would make more sense for us to talk and frame the problem to be >>>>> solved so that conversation can be productive. Can I set up a call >>>>> with both of you, maybe for Wednesday or Thursday? That will give me >>>>> some time to draft a first pass at a problem statement that we can >>>>> use to set up productive discussion with others. >>>>> >>>>> /chet >>>>> >>>>> On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay <sanjay.patil@sap.com> >>>>> wrote: >>>>> I think it makes a lot of sense to have a conference call to jointly >>>>> define the problem and brainstorm the potentially solutions. >>>>> However, scheduling a call with the many interested parties from the >>>>> various time zones might become tricky. One option may be to check >>>>> with the SCA Assembly TC chairs if they would be ok to allocate some >>>>> of their weekly meeting time (Tue 8 AM PST) for this topic (assuming >>>>> that Chet and other concerned OASIS staff / TAB members can make >>>>> it). I believe that most of the SCA TC chairs are also members of >>>>> the SCA Assembly TC and moreover the SCA TCs typically look forward >>>>> to the SCA Assembly TC to resolve such cross-cutting issues and set >>>>> the precedent. Mike/Martin, any thoughts in this regard? >>>>> >>>>> >>>>> >>>>> Sanjay >>>>> >>>>> >>>>> >>>>> From: Chet Ensign [ mailto:chet.ensign@oasis-open.org ] >>>>> Sent: Monday, August 08, 2011 3:20 PM >>>>> To: Patil, Sanjay >>>>> Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul >>>>> Knight; Robin Cover >>>>> Subject: Re: [opencsa-liaison] Reference dependencies in various SCA >>>>> specs >>>>> >>>>> >>>>> >>>>> Sanjay, Mike et al - We started a discussion on this subject at the >>>>> TAB F2F and it is on our agenda. If you all would like, I would like >>>>> to schedule a conference call so that we can discuss together and ... >>>>> >>>>> >>>>> >>>>> - Jointly define the problem(s) - typically the most difficult part >>>>> of any of these conversations <grin> >>>>> >>>>> - Discuss what limitations of the current process / rules contribute >>>>> to the problem(s) >>>>> >>>>> - Brainstorm possible modifications that could resolve the problem(s) >>>>> >>>>> >>>>> >>>>> Is that something you all are interested in doing? >>>>> >>>>> Best, >>>>> >>>>> >>>>> >>>>> /chet >>>>> >>>>> On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay <sanjay.patil@sap.com> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> Do other TC chairs have any further viewpoints on this topic? >>>>> >>>>> >>>>> >>>>> Since the resolution of this issue may involve changes to procedures >>>>> involving the TC Admin (and potentially the TC process!), we need to >>>>> decide how to take this issue forward. At the minimum, I think we >>>>> should inform the TC Admin about our opinions and start the >>>>> discussion. I am taking the liberty to copy Chet Ensign on this >>>>> email thread to set the ball rolling. >>>>> >>>>> >>>>> >>>>> Best wishes, >>>>> >>>>> Sanjay >>>>> >>>>> >>>>> >>>>> From: Mike Edwards [ mailto:mike_edwards@uk.ibm.com ] >>>>> Sent: Wednesday, August 03, 2011 1:33 AM >>>>> To: Patil, Sanjay >>>>> Cc: Anish Karmarkar; OASIS Liaison >>>>> Subject: RE: [opencsa-liaison] Reference dependencies in various SCA >>>>> specs >>>>> >>>>> >>>>> >>>>> >>>>> Sanjay, >>>>> >>>>> I agree with your views. >>>>> >>>>> In the latest round of changes, for example, I think that Assembly >>>>> is not affected by the changes to the >>>>> other specifications (Policy, WS-Binding, Java...), even though >>>>> those changes are normative. >>>>> >>>>> As a result, in my opinion, updating the Assembly spec to reference >>>>> the latest CSDs of the other specs >>>>> is a purely editorial process. >>>>> >>>>> Each TC may need to take a vote that agrees this for any particular >>>>> spec, but once that vote has >>>>> taken place, the update should be purely mechanical.  No new public >>>>> reviews are required. >>>>> >>>>> >>>>> Yours, Mike >>>>> >>>>> Dr Mike Edwards >>>>> >>>>>  Mail Point 137, Hursley Park >>>>> >>>>> <image001.gif> >>>>> >>>>> STSM >>>>> >>>>>  Winchester, Hants SO21 2JN >>>>> >>>>> SCA, Cloud Computing & Services Standards >>>>> >>>>>  United Kingdom >>>>> >>>>> Co-Chair OASIS SCA Assembly TC >>>>> >>>>> >>>>> >>>>> Chair UK ISO SC38 mirror committee (Cloud & SOA) >>>>> >>>>> >>>>> >>>>> IBM Software Group >>>>> >>>>> >>>>> >>>>> Phone: >>>>> >>>>> +44-1962 818014 >>>>> >>>>> >>>>> >>>>> Mobile: >>>>> >>>>> +44-7802-467431 (274097) >>>>> >>>>> >>>>> >>>>> e-mail: >>>>> >>>>> mike_edwards@uk.ibm.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: >>>>> >>>>> "Patil, Sanjay" <sanjay.patil@sap.com> >>>>> >>>>> To: >>>>> >>>>> Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa- >>>> >>>> liaison@lists.oasis-open.org >>>>>> >>>>> >>>>> Date: >>>>> >>>>> 02/08/2011 17:56 >>>>> >>>>> Subject: >>>>> >>>>> RE: [opencsa-liaison] Reference dependencies in various SCA specs >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I think the option 3 provides the required solution while retaining >>>>> the independence for the TCs to decide and follow their own >>>>> schedule. During CSD publication and PR, specs can make references >>>>> to the existing source material as of that time. Later, it should be >>>>> allowed to update the references without having to go for another >>>>> round of PR. I think it is reasonable to trust the TCs in making a >>>>> determination about whether a change in a reference is significant >>>>> enough to require another round of PR or not. >>>>> >>>>> Sanjay >>>>> >>>>> >>>>>
Original Message----- >>>>> From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] >>>>> Sent: Tuesday, August 02, 2011 9:22 AM >>>>> To: OASIS Liaison >>>>> Subject: [opencsa-liaison] Reference dependencies in various SCA specs >>>>> >>>>> As we all know, specs in all the SCA TCs have dependencies on each >>>>> other. For example, Assembly has a normative reference to Policy and >>>>> WS-Binding. To conform to Assembly one has to conform to Policy and >>>>> WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on >>>>> Assembly/Policy. The dependency graph is cyclic. >>>>> >>>>> A similar problem exists in SCA-J TC but without any cycles [1]. >>>>> >>>>> OASIS TC process solves this problem of cyclic references by using >>>>> designated cross references [2]. Unfortunately, CSDs cannot use this >>>>> mechanism as the process explicitly excludes it. So, two specs A and B >>>>> that depend on each other, will be in an infinite loop wrt updating >>>>> their normative references. Further compounding the problem (but is an >>>>> independent issue) is the fact that the new process requires at least >>>>> 15-days PR for any change (except the changes on the front page). So >>>>> any >>>>> time spec A or B is updated to update its normative reference it has >>>>> to >>>>> be PRed. >>>>> >>>>> I see three possible solutions to this: >>>>> 1) Fix the process to allow DCRs for CSDs (this is the only long term >>>>> solution, I think). >>>>> 2) Use the solution in [1] where spec A instead of using WDXX >>>>> reference >>>>> of B, uses the CSDYY reference of B. Where CSDYY is the what will >>>>> happen >>>>> to WDXX when the TC Admin processes the request for WDXX to be >>>>> published >>>>> as CSD. This means that the CSDs of A and B should be coordinated to >>>>> go >>>>> in the TC Admin queue around the same time. >>>>> 3) Get TC admin to update normative references when there is no >>>>> material >>>>> change. For example, in (2) above, WDXX and CSDYY are going to be >>>>> identical specs except for the front page. If spec A references WDXX, >>>>> the TC admin should be able to update that reference to CSDYY. A >>>>> similar >>>>> update would have to be done to spec B. >>>>> >>>>> -Anish >>>>> -- >>>>> >>>>> [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html >>>>> [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>>> generates this mail.  Follow this link to all your TCs in OASIS at: >>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Unless stated otherwise above: >>>>> IBM United Kingdom Limited - Registered in England and Wales with >>>>> number 741598. >>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>>>> PO6 3AU >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> /chet >>>>> ---------------- >>>>> Chet Ensign >>>>> Director of Standards Development and TC Administration >>>>> OASIS: Advancing open standards for the information society >>>>> http://www.oasis-open.org >>>>> >>>>> Primary: +1 973-378-3472 >>>>> Mobile: +1 201-341-1393 >>>>> >>>>> Follow OASIS on: >>>>> LinkedIn:     http://linkd.in/OASISopen >>>>> Twitter:         http://twitter.com/OASISopen >>>>> Facebook:   http://facebook.com/oasis.open >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> /chet >>>>> ---------------- >>>>> Chet Ensign >>>>> Director of Standards Development and TC Administration >>>>> OASIS: Advancing open standards for the information society >>>>> http://www.oasis-open.org >>>>> >>>>> Primary: +1 973-378-3472 >>>>> Mobile: +1 201-341-1393 >>>>> >>>>> Follow OASIS on: >>>>> LinkedIn:     http://linkd.in/OASISopen >>>>> Twitter:         http://twitter.com/OASISopen >>>>> Facebook:   http://facebook.com/oasis.open >>>>> >>>> >>>> -- >>>> Jeff Mischkinsky >>>>      jeff.mischkinsky@oracle.com >>>> Sr. Director, Oracle Fusion Middleware >>>>  +1(650)506- >>>> 1975 >>>>      and Web Services Standards                              500 Oracle >>>> Parkway, M/S 2OP9 >>>> Oracle >>>>  Redwood Shores, CA 94065 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>> generates this mail.  Follow this link to all your TCs in OASIS at: >>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>> >>> >> >> >> >> -- >> >> /chet >> ---------------- >> Chet Ensign >> Director of Standards Development and TC Administration >> OASIS: Advancing open standards for the information society >> http://www.oasis-open.org >> >> Primary: +1 973-378-3472 >> Mobile: +1 201-341-1393 >> >> Follow OASIS on: >> LinkedIn:     http://linkd.in/OASISopen >> Twitter:         http://twitter.com/OASISopen >> Facebook:   http://facebook.com/oasis.open > > -- > Jeff Mischkinsky >  jeff.mischkinsky@oracle.com > Sr. Director, Oracle Fusion Middleware >  +1(650)506-1975 >        and Web Services Standards                              500 Oracle > Parkway, M/S 2OP9 > Oracle                                                          Redwood > Shores, CA 94065 > > > > > > > > > > -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

Thanks Jeff - makes sense. I will draft the problem statement for us to go over in the TAB first. On Tue, Aug 9, 2011 at 11:35 AM, Jeff Mischkinsky <JEFF.MISCHKINSKY@oracle.com> wrote: > hi chet, >  It also seems to me, as you point out, that this issue has much broader > applicability than just the SCA TCs, so i think we should formally raise and > address this issue by the Process Committee. That said, getting input and > discussion from a wider group is a good thing, and I don't mean to try to > stifle that. >   We have enough on the process comm agenda for the next several weeks, so > developing a well formed proposal out of band is probably also a good thing. > > Also, as martin noted, the TAB already has this on its agenda, so why don't > we let it be the focus for the discussion for a while - with an occasional > update to Process. > > I do note that cross posting across multiple oasis lists, for which > different people have read/write permission could prove to be awkward -- and > process is probably the most limited list which is an added complication. > > cheers, >  jeff > > On Aug 09, 2011, at 8:21 AM, Chet Ensign wrote: > >> Jeff et al - >> >> I'll draft this up into a note to send the the BPC mailing list. This >> is an opportunity for people to comment on the problem statement and >> make sure I have correctly captured and characterized both the problem >> and the proposed solution. >> >> The problem being raised (and thank you Sanjay and Mike for bumping it >> up a notch) is a narrow one: >> >> - A given TC has a Working Draft (WD) approved and submitted for >> publication as a Committee Specification Draft (CSD). This WD contains >> references to other approved WD’s that will, at some point in the near >> future, be approved and published as CSD's. >> >> - The TC wants to proceed with publication of their CSD with the >> references to the approved WD's and have TC Administration update the >> references in the published CSD at a later date from approved WD to >> CSD when the referenced specifications are themselves published. >> >> - In addition, they want this done without triggering a 15 day public >> review of the updated CSD. >> >> - This situation would be addressed by TC Process section 2.19, >> Designated Cross Reference Changes and by section 2.18, Work Product >> Quality item (6) Allowed Changes *if* section 2.19 applied at the CSD >> stage of a specification. Right now, 2.19 only applies to approvals >> for Committee Specification and above. >> >> The solution being proposed is to allow section 2.19 to apply to CSD >> approvals as well as CS approvals. (Note for the TC's to consider: as >> currently constructed, application of section 2.19 will result in >> publication of the referencing CSD being held up until all the >> cross-referenced specifications are published. To proceed with >> immediate publishing of the CSD and subsequent updates to the >> references requires additional changes to section 2.19.) >> >> In addition, we need to answer a second question this raises: what >> cross references are specifically meant in 2.19: >> >> 1. The references in the Related Work section of the cover pages to >> the specification only? >> 2. That plus the cross references in the Normative / Non-Normative >> References section of the specification body? (Meaning that TC >> Administration would be responsible for making changes with the >> content produced by the TC.) >> 3. *Any* cross reference anywhere in the narrative specification document? >> 4. *Any* cross reference anywhere in *any* component of the complete >> specification? >> >> I ask because I have had other TC's argue that it means item #4. >> >> Please provide any comments on this. Jeff, I can send the above to >> board-process-committee@ if you'd like. >> >> Best, >> >> /chet >> >> >> >> >> >> On Tue, Aug 9, 2011 at 9:57 AM, Martin Chapman >> <MARTIN.CHAPMAN@oracle.com> wrote: >>> >>> We removed C*Ds from the DCR section because we argued that a TC could >>> always produce another draft. However, what we didn't do was to examine the >>> inter-dependency of this rationale with the 15 public review for any change >>> (aside from 2.18(6) changes), and we are seeing some of that interplay here. >>> >>> I think if a TC can show that a normative reference has not been >>> materially changed i.e. only a status change has been made - reflected by >>> the changes permissible in section 2.18(6)- they (or TC Admin) should be >>> able to update the reference to that changed version. It should be easy to >>> track if only 2.18(6) changes have been made. >>> >>> Martin. >>> >>>>
Original Message----- >>>> From: Jeff Mischkinsky >>>> Sent: 09 August 2011 03:01 >>>> To: Chet Ensign >>>> Cc: Patil, Sanjay; Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS >>>> TAB; >>>> Paul Knight; Robin Cover >>>> Subject: [tab] Re: [opencsa-liaison] Reference dependencies in various >>>> SCA >>>> specs >>>> >>>> we can also allocate some time in Process Committee if that would be >>>> desireable/easier. >>>> >>>> FWIW I think the problem is that the SCA TCs are not really completely >>>> independent of each other. (I think of them as "almost separable".) >>>> When we were first developing SCA we discussed whether we should have >>>> one big TC or break things up to make development more manageable >>>> realizing that the trade-off was that we would have mutual dependencies. >>>> >>>> That said i'm not sure the real issue is independent TCs. The mutual >>>> dependencies would exist even if there was one TC. Having multiple TCs >>>> makes it more complicated because its harder to coordinate >>>> simultaneous votes on mutually dependent specs across TCs. I'm trying >>>> to remember why we don't allow DCR's for CSD's. I *think* it might be >>>> because we thought that since these were "only drafts", it was ok if >>>> there were some inconsistencies/bugs and not worth the effort to allow >>>> DCR's. >>>> >>>> The suggestion to allow TC's to decide if a change is not "substantive >>>> enough" is that we were never able to agree on a definition of what >>>> "enough" meant and TCs will almost always declare a change to be non- >>>> substantive, regardless. >>>> >>>> Actually we already have that issue on the Process Committee's agenda >>>> as part of figuring out if the requirement of new PRs for any change >>>> is creating too many PRs. >>>> >>>> cheers, >>>>   jeff >>>> >>>> On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: >>>> >>>>> Mike, Sanjay - Actually, before launching on a broad chat, I think >>>>> it would make more sense for us to talk and frame the problem to be >>>>> solved so that conversation can be productive. Can I set up a call >>>>> with both of you, maybe for Wednesday or Thursday? That will give me >>>>> some time to draft a first pass at a problem statement that we can >>>>> use to set up productive discussion with others. >>>>> >>>>> /chet >>>>> >>>>> On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay <sanjay.patil@sap.com> >>>>> wrote: >>>>> I think it makes a lot of sense to have a conference call to jointly >>>>> define the problem and brainstorm the potentially solutions. >>>>> However, scheduling a call with the many interested parties from the >>>>> various time zones might become tricky. One option may be to check >>>>> with the SCA Assembly TC chairs if they would be ok to allocate some >>>>> of their weekly meeting time (Tue 8 AM PST) for this topic (assuming >>>>> that Chet and other concerned OASIS staff / TAB members can make >>>>> it). I believe that most of the SCA TC chairs are also members of >>>>> the SCA Assembly TC and moreover the SCA TCs typically look forward >>>>> to the SCA Assembly TC to resolve such cross-cutting issues and set >>>>> the precedent. Mike/Martin, any thoughts in this regard? >>>>> >>>>> >>>>> >>>>> Sanjay >>>>> >>>>> >>>>> >>>>> From: Chet Ensign [ mailto:chet.ensign@oasis-open.org ] >>>>> Sent: Monday, August 08, 2011 3:20 PM >>>>> To: Patil, Sanjay >>>>> Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul >>>>> Knight; Robin Cover >>>>> Subject: Re: [opencsa-liaison] Reference dependencies in various SCA >>>>> specs >>>>> >>>>> >>>>> >>>>> Sanjay, Mike et al - We started a discussion on this subject at the >>>>> TAB F2F and it is on our agenda. If you all would like, I would like >>>>> to schedule a conference call so that we can discuss together and ... >>>>> >>>>> >>>>> >>>>> - Jointly define the problem(s) - typically the most difficult part >>>>> of any of these conversations <grin> >>>>> >>>>> - Discuss what limitations of the current process / rules contribute >>>>> to the problem(s) >>>>> >>>>> - Brainstorm possible modifications that could resolve the problem(s) >>>>> >>>>> >>>>> >>>>> Is that something you all are interested in doing? >>>>> >>>>> Best, >>>>> >>>>> >>>>> >>>>> /chet >>>>> >>>>> On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay <sanjay.patil@sap.com> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> Do other TC chairs have any further viewpoints on this topic? >>>>> >>>>> >>>>> >>>>> Since the resolution of this issue may involve changes to procedures >>>>> involving the TC Admin (and potentially the TC process!), we need to >>>>> decide how to take this issue forward. At the minimum, I think we >>>>> should inform the TC Admin about our opinions and start the >>>>> discussion. I am taking the liberty to copy Chet Ensign on this >>>>> email thread to set the ball rolling. >>>>> >>>>> >>>>> >>>>> Best wishes, >>>>> >>>>> Sanjay >>>>> >>>>> >>>>> >>>>> From: Mike Edwards [ mailto:mike_edwards@uk.ibm.com ] >>>>> Sent: Wednesday, August 03, 2011 1:33 AM >>>>> To: Patil, Sanjay >>>>> Cc: Anish Karmarkar; OASIS Liaison >>>>> Subject: RE: [opencsa-liaison] Reference dependencies in various SCA >>>>> specs >>>>> >>>>> >>>>> >>>>> >>>>> Sanjay, >>>>> >>>>> I agree with your views. >>>>> >>>>> In the latest round of changes, for example, I think that Assembly >>>>> is not affected by the changes to the >>>>> other specifications (Policy, WS-Binding, Java...), even though >>>>> those changes are normative. >>>>> >>>>> As a result, in my opinion, updating the Assembly spec to reference >>>>> the latest CSDs of the other specs >>>>> is a purely editorial process. >>>>> >>>>> Each TC may need to take a vote that agrees this for any particular >>>>> spec, but once that vote has >>>>> taken place, the update should be purely mechanical.  No new public >>>>> reviews are required. >>>>> >>>>> >>>>> Yours, Mike >>>>> >>>>> Dr Mike Edwards >>>>> >>>>>  Mail Point 137, Hursley Park >>>>> >>>>> <image001.gif> >>>>> >>>>> STSM >>>>> >>>>>  Winchester, Hants SO21 2JN >>>>> >>>>> SCA, Cloud Computing & Services Standards >>>>> >>>>>  United Kingdom >>>>> >>>>> Co-Chair OASIS SCA Assembly TC >>>>> >>>>> >>>>> >>>>> Chair UK ISO SC38 mirror committee (Cloud & SOA) >>>>> >>>>> >>>>> >>>>> IBM Software Group >>>>> >>>>> >>>>> >>>>> Phone: >>>>> >>>>> +44-1962 818014 >>>>> >>>>> >>>>> >>>>> Mobile: >>>>> >>>>> +44-7802-467431 (274097) >>>>> >>>>> >>>>> >>>>> e-mail: >>>>> >>>>> mike_edwards@uk.ibm.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: >>>>> >>>>> "Patil, Sanjay" <sanjay.patil@sap.com> >>>>> >>>>> To: >>>>> >>>>> Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa- >>>> >>>> liaison@lists.oasis-open.org >>>>>> >>>>> >>>>> Date: >>>>> >>>>> 02/08/2011 17:56 >>>>> >>>>> Subject: >>>>> >>>>> RE: [opencsa-liaison] Reference dependencies in various SCA specs >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I think the option 3 provides the required solution while retaining >>>>> the independence for the TCs to decide and follow their own >>>>> schedule. During CSD publication and PR, specs can make references >>>>> to the existing source material as of that time. Later, it should be >>>>> allowed to update the references without having to go for another >>>>> round of PR. I think it is reasonable to trust the TCs in making a >>>>> determination about whether a change in a reference is significant >>>>> enough to require another round of PR or not. >>>>> >>>>> Sanjay >>>>> >>>>> >>>>>
Original Message----- >>>>> From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] >>>>> Sent: Tuesday, August 02, 2011 9:22 AM >>>>> To: OASIS Liaison >>>>> Subject: [opencsa-liaison] Reference dependencies in various SCA specs >>>>> >>>>> As we all know, specs in all the SCA TCs have dependencies on each >>>>> other. For example, Assembly has a normative reference to Policy and >>>>> WS-Binding. To conform to Assembly one has to conform to Policy and >>>>> WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on >>>>> Assembly/Policy. The dependency graph is cyclic. >>>>> >>>>> A similar problem exists in SCA-J TC but without any cycles [1]. >>>>> >>>>> OASIS TC process solves this problem of cyclic references by using >>>>> designated cross references [2]. Unfortunately, CSDs cannot use this >>>>> mechanism as the process explicitly excludes it. So, two specs A and B >>>>> that depend on each other, will be in an infinite loop wrt updating >>>>> their normative references. Further compounding the problem (but is an >>>>> independent issue) is the fact that the new process requires at least >>>>> 15-days PR for any change (except the changes on the front page). So >>>>> any >>>>> time spec A or B is updated to update its normative reference it has >>>>> to >>>>> be PRed. >>>>> >>>>> I see three possible solutions to this: >>>>> 1) Fix the process to allow DCRs for CSDs (this is the only long term >>>>> solution, I think). >>>>> 2) Use the solution in [1] where spec A instead of using WDXX >>>>> reference >>>>> of B, uses the CSDYY reference of B. Where CSDYY is the what will >>>>> happen >>>>> to WDXX when the TC Admin processes the request for WDXX to be >>>>> published >>>>> as CSD. This means that the CSDs of A and B should be coordinated to >>>>> go >>>>> in the TC Admin queue around the same time. >>>>> 3) Get TC admin to update normative references when there is no >>>>> material >>>>> change. For example, in (2) above, WDXX and CSDYY are going to be >>>>> identical specs except for the front page. If spec A references WDXX, >>>>> the TC admin should be able to update that reference to CSDYY. A >>>>> similar >>>>> update would have to be done to spec B. >>>>> >>>>> -Anish >>>>> -- >>>>> >>>>> [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html >>>>> [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>>> generates this mail.  Follow this link to all your TCs in OASIS at: >>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Unless stated otherwise above: >>>>> IBM United Kingdom Limited - Registered in England and Wales with >>>>> number 741598. >>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>>>> PO6 3AU >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> /chet >>>>> ---------------- >>>>> Chet Ensign >>>>> Director of Standards Development and TC Administration >>>>> OASIS: Advancing open standards for the information society >>>>> http://www.oasis-open.org >>>>> >>>>> Primary: +1 973-378-3472 >>>>> Mobile: +1 201-341-1393 >>>>> >>>>> Follow OASIS on: >>>>> LinkedIn:     http://linkd.in/OASISopen >>>>> Twitter:         http://twitter.com/OASISopen >>>>> Facebook:   http://facebook.com/oasis.open >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> /chet >>>>> ---------------- >>>>> Chet Ensign >>>>> Director of Standards Development and TC Administration >>>>> OASIS: Advancing open standards for the information society >>>>> http://www.oasis-open.org >>>>> >>>>> Primary: +1 973-378-3472 >>>>> Mobile: +1 201-341-1393 >>>>> >>>>> Follow OASIS on: >>>>> LinkedIn:     http://linkd.in/OASISopen >>>>> Twitter:         http://twitter.com/OASISopen >>>>> Facebook:   http://facebook.com/oasis.open >>>>> >>>> >>>> -- >>>> Jeff Mischkinsky >>>>      jeff.mischkinsky@oracle.com >>>> Sr. Director, Oracle Fusion Middleware >>>>  +1(650)506- >>>> 1975 >>>>      and Web Services Standards                              500 Oracle >>>> Parkway, M/S 2OP9 >>>> Oracle >>>>  Redwood Shores, CA 94065 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>> generates this mail.  Follow this link to all your TCs in OASIS at: >>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>> >>> >> >> >> >> -- >> >> /chet >> ---------------- >> Chet Ensign >> Director of Standards Development and TC Administration >> OASIS: Advancing open standards for the information society >> http://www.oasis-open.org >> >> Primary: +1 973-378-3472 >> Mobile: +1 201-341-1393 >> >> Follow OASIS on: >> LinkedIn:     http://linkd.in/OASISopen >> Twitter:         http://twitter.com/OASISopen >> Facebook:   http://facebook.com/oasis.open > > -- > Jeff Mischkinsky >  jeff.mischkinsky@oracle.com > Sr. Director, Oracle Fusion Middleware >  +1(650)506-1975 >        and Web Services Standards                              500 Oracle > Parkway, M/S 2OP9 > Oracle                                                          Redwood > Shores, CA 94065 > > > > > > > > > > -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

hi chet, It also seems to me, as you point out, that this issue has much broader applicability than just the SCA TCs, so i think we should formally raise and address this issue by the Process Committee. That said, getting input and discussion from a wider group is a good thing, and I don't mean to try to stifle that. We have enough on the process comm agenda for the next several weeks, so developing a well formed proposal out of band is probably also a good thing. Also, as martin noted, the TAB already has this on its agenda, so why don't we let it be the focus for the discussion for a while - with an occasional update to Process. I do note that cross posting across multiple oasis lists, for which different people have read/write permission could prove to be awkward -- and process is probably the most limited list which is an added complication. cheers, jeff On Aug 09, 2011, at 8:21 AM, Chet Ensign wrote: > Jeff et al - > > I'll draft this up into a note to send the the BPC mailing list. This > is an opportunity for people to comment on the problem statement and > make sure I have correctly captured and characterized both the problem > and the proposed solution. > > The problem being raised (and thank you Sanjay and Mike for bumping it > up a notch) is a narrow one: > > - A given TC has a Working Draft (WD) approved and submitted for > publication as a Committee Specification Draft (CSD). This WD contains > references to other approved WD’s that will, at some point in the near > future, be approved and published as CSD's. > > - The TC wants to proceed with publication of their CSD with the > references to the approved WD's and have TC Administration update the > references in the published CSD at a later date from approved WD to > CSD when the referenced specifications are themselves published. > > - In addition, they want this done without triggering a 15 day public > review of the updated CSD. > > - This situation would be addressed by TC Process section 2.19, > Designated Cross Reference Changes and by section 2.18, Work Product > Quality item (6) Allowed Changes *if* section 2.19 applied at the CSD > stage of a specification. Right now, 2.19 only applies to approvals > for Committee Specification and above. > > The solution being proposed is to allow section 2.19 to apply to CSD > approvals as well as CS approvals. (Note for the TC's to consider: as > currently constructed, application of section 2.19 will result in > publication of the referencing CSD being held up until all the > cross-referenced specifications are published. To proceed with > immediate publishing of the CSD and subsequent updates to the > references requires additional changes to section 2.19.) > > In addition, we need to answer a second question this raises: what > cross references are specifically meant in 2.19: > > 1. The references in the Related Work section of the cover pages to > the specification only? > 2. That plus the cross references in the Normative / Non-Normative > References section of the specification body? (Meaning that TC > Administration would be responsible for making changes with the > content produced by the TC.) > 3. *Any* cross reference anywhere in the narrative specification > document? > 4. *Any* cross reference anywhere in *any* component of the complete > specification? > > I ask because I have had other TC's argue that it means item #4. > > Please provide any comments on this. Jeff, I can send the above to > board-process-committee@ if you'd like. > > Best, > > /chet > > > > > > On Tue, Aug 9, 2011 at 9:57 AM, Martin Chapman > <MARTIN.CHAPMAN@oracle.com> wrote: >> We removed C*Ds from the DCR section because we argued that a TC >> could always produce another draft. However, what we didn't do was >> to examine the inter-dependency of this rationale with the 15 >> public review for any change (aside from 2.18(6) changes), and we >> are seeing some of that interplay here. >> >> I think if a TC can show that a normative reference has not been >> materially changed i.e. only a status change has been made - >> reflected by the changes permissible in section 2.18(6)- they (or >> TC Admin) should be able to update the reference to that changed >> version. It should be easy to track if only 2.18(6) changes have >> been made. >> >> Martin. >> >>>
Original Message----- >>> From: Jeff Mischkinsky >>> Sent: 09 August 2011 03:01 >>> To: Chet Ensign >>> Cc: Patil, Sanjay; Mike Edwards; Anish Karmarkar; OASIS Liaison; >>> OASIS TAB; >>> Paul Knight; Robin Cover >>> Subject: [tab] Re: [opencsa-liaison] Reference dependencies in >>> various SCA >>> specs >>> >>> we can also allocate some time in Process Committee if that would be >>> desireable/easier. >>> >>> FWIW I think the problem is that the SCA TCs are not really >>> completely >>> independent of each other. (I think of them as "almost separable".) >>> When we were first developing SCA we discussed whether we should >>> have >>> one big TC or break things up to make development more manageable >>> realizing that the trade-off was that we would have mutual >>> dependencies. >>> >>> That said i'm not sure the real issue is independent TCs. The mutual >>> dependencies would exist even if there was one TC. Having multiple >>> TCs >>> makes it more complicated because its harder to coordinate >>> simultaneous votes on mutually dependent specs across TCs. I'm >>> trying >>> to remember why we don't allow DCR's for CSD's. I *think* it might >>> be >>> because we thought that since these were "only drafts", it was ok if >>> there were some inconsistencies/bugs and not worth the effort to >>> allow >>> DCR's. >>> >>> The suggestion to allow TC's to decide if a change is not >>> "substantive >>> enough" is that we were never able to agree on a definition of what >>> "enough" meant and TCs will almost always declare a change to be >>> non- >>> substantive, regardless. >>> >>> Actually we already have that issue on the Process Committee's >>> agenda >>> as part of figuring out if the requirement of new PRs for any change >>> is creating too many PRs. >>> >>> cheers, >>> jeff >>> >>> On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: >>> >>>> Mike, Sanjay - Actually, before launching on a broad chat, I think >>>> it would make more sense for us to talk and frame the problem to be >>>> solved so that conversation can be productive. Can I set up a call >>>> with both of you, maybe for Wednesday or Thursday? That will give >>>> me >>>> some time to draft a first pass at a problem statement that we can >>>> use to set up productive discussion with others. >>>> >>>> /chet >>>> >>>> On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay >>>> <sanjay.patil@sap.com> >>>> wrote: >>>> I think it makes a lot of sense to have a conference call to >>>> jointly >>>> define the problem and brainstorm the potentially solutions. >>>> However, scheduling a call with the many interested parties from >>>> the >>>> various time zones might become tricky. One option may be to check >>>> with the SCA Assembly TC chairs if they would be ok to allocate >>>> some >>>> of their weekly meeting time (Tue 8 AM PST) for this topic >>>> (assuming >>>> that Chet and other concerned OASIS staff / TAB members can make >>>> it). I believe that most of the SCA TC chairs are also members of >>>> the SCA Assembly TC and moreover the SCA TCs typically look forward >>>> to the SCA Assembly TC to resolve such cross-cutting issues and set >>>> the precedent. Mike/Martin, any thoughts in this regard? >>>> >>>> >>>> >>>> Sanjay >>>> >>>> >>>> >>>> From: Chet Ensign [ mailto:chet.ensign@oasis-open.org ] >>>> Sent: Monday, August 08, 2011 3:20 PM >>>> To: Patil, Sanjay >>>> Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul >>>> Knight; Robin Cover >>>> Subject: Re: [opencsa-liaison] Reference dependencies in various >>>> SCA >>>> specs >>>> >>>> >>>> >>>> Sanjay, Mike et al - We started a discussion on this subject at the >>>> TAB F2F and it is on our agenda. If you all would like, I would >>>> like >>>> to schedule a conference call so that we can discuss together >>>> and ... >>>> >>>> >>>> >>>> - Jointly define the problem(s) - typically the most difficult part >>>> of any of these conversations <grin> >>>> >>>> - Discuss what limitations of the current process / rules >>>> contribute >>>> to the problem(s) >>>> >>>> - Brainstorm possible modifications that could resolve the >>>> problem(s) >>>> >>>> >>>> >>>> Is that something you all are interested in doing? >>>> >>>> Best, >>>> >>>> >>>> >>>> /chet >>>> >>>> On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay >>>> <sanjay.patil@sap.com> >>>> wrote: >>>> >>>> >>>> >>>> Do other TC chairs have any further viewpoints on this topic? >>>> >>>> >>>> >>>> Since the resolution of this issue may involve changes to >>>> procedures >>>> involving the TC Admin (and potentially the TC process!), we need >>>> to >>>> decide how to take this issue forward. At the minimum, I think we >>>> should inform the TC Admin about our opinions and start the >>>> discussion. I am taking the liberty to copy Chet Ensign on this >>>> email thread to set the ball rolling. >>>> >>>> >>>> >>>> Best wishes, >>>> >>>> Sanjay >>>> >>>> >>>> >>>> From: Mike Edwards [ mailto:mike_edwards@uk.ibm.com ] >>>> Sent: Wednesday, August 03, 2011 1:33 AM >>>> To: Patil, Sanjay >>>> Cc: Anish Karmarkar; OASIS Liaison >>>> Subject: RE: [opencsa-liaison] Reference dependencies in various >>>> SCA >>>> specs >>>> >>>> >>>> >>>> >>>> Sanjay, >>>> >>>> I agree with your views. >>>> >>>> In the latest round of changes, for example, I think that Assembly >>>> is not affected by the changes to the >>>> other specifications (Policy, WS-Binding, Java...), even though >>>> those changes are normative. >>>> >>>> As a result, in my opinion, updating the Assembly spec to reference >>>> the latest CSDs of the other specs >>>> is a purely editorial process. >>>> >>>> Each TC may need to take a vote that agrees this for any particular >>>> spec, but once that vote has >>>> taken place, the update should be purely mechanical. No new public >>>> reviews are required. >>>> >>>> >>>> Yours, Mike >>>> >>>> Dr Mike Edwards >>>> >>>> Mail Point 137, Hursley Park >>>> >>>> <image001.gif> >>>> >>>> STSM >>>> >>>> Winchester, Hants SO21 2JN >>>> >>>> SCA, Cloud Computing & Services Standards >>>> >>>> United Kingdom >>>> >>>> Co-Chair OASIS SCA Assembly TC >>>> >>>> >>>> >>>> Chair UK ISO SC38 mirror committee (Cloud & SOA) >>>> >>>> >>>> >>>> IBM Software Group >>>> >>>> >>>> >>>> Phone: >>>> >>>> +44-1962 818014 >>>> >>>> >>>> >>>> Mobile: >>>> >>>> +44-7802-467431 (274097) >>>> >>>> >>>> >>>> e-mail: >>>> >>>> mike_edwards@uk.ibm.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> From: >>>> >>>> "Patil, Sanjay" <sanjay.patil@sap.com> >>>> >>>> To: >>>> >>>> Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison >>>> <opencsa- >>> liaison@lists.oasis-open.org >>>>> >>>> >>>> Date: >>>> >>>> 02/08/2011 17:56 >>>> >>>> Subject: >>>> >>>> RE: [opencsa-liaison] Reference dependencies in various SCA specs >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I think the option 3 provides the required solution while retaining >>>> the independence for the TCs to decide and follow their own >>>> schedule. During CSD publication and PR, specs can make references >>>> to the existing source material as of that time. Later, it should >>>> be >>>> allowed to update the references without having to go for another >>>> round of PR. I think it is reasonable to trust the TCs in making a >>>> determination about whether a change in a reference is significant >>>> enough to require another round of PR or not. >>>> >>>> Sanjay >>>> >>>> >>>>
Original Message----- >>>> From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] >>>> Sent: Tuesday, August 02, 2011 9:22 AM >>>> To: OASIS Liaison >>>> Subject: [opencsa-liaison] Reference dependencies in various SCA >>>> specs >>>> >>>> As we all know, specs in all the SCA TCs have dependencies on each >>>> other. For example, Assembly has a normative reference to Policy >>>> and >>>> WS-Binding. To conform to Assembly one has to conform to Policy and >>>> WS-Binding. Policy in turn depends on Assembly. WS-Binding >>>> depends on >>>> Assembly/Policy. The dependency graph is cyclic. >>>> >>>> A similar problem exists in SCA-J TC but without any cycles [1]. >>>> >>>> OASIS TC process solves this problem of cyclic references by using >>>> designated cross references [2]. Unfortunately, CSDs cannot use >>>> this >>>> mechanism as the process explicitly excludes it. So, two specs A >>>> and B >>>> that depend on each other, will be in an infinite loop wrt updating >>>> their normative references. Further compounding the problem (but >>>> is an >>>> independent issue) is the fact that the new process requires at >>>> least >>>> 15-days PR for any change (except the changes on the front page). >>>> So >>>> any >>>> time spec A or B is updated to update its normative reference it >>>> has >>>> to >>>> be PRed. >>>> >>>> I see three possible solutions to this: >>>> 1) Fix the process to allow DCRs for CSDs (this is the only long >>>> term >>>> solution, I think). >>>> 2) Use the solution in [1] where spec A instead of using WDXX >>>> reference >>>> of B, uses the CSDYY reference of B. Where CSDYY is the what will >>>> happen >>>> to WDXX when the TC Admin processes the request for WDXX to be >>>> published >>>> as CSD. This means that the CSDs of A and B should be coordinated >>>> to >>>> go >>>> in the TC Admin queue around the same time. >>>> 3) Get TC admin to update normative references when there is no >>>> material >>>> change. For example, in (2) above, WDXX and CSDYY are going to be >>>> identical specs except for the front page. If spec A references >>>> WDXX, >>>> the TC admin should be able to update that reference to CSDYY. A >>>> similar >>>> update would have to be done to spec B. >>>> >>>> -Anish >>>> -- >>>> >>>> [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html >>>> [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this mail list, you must leave the OASIS TC >>>> that >>>> generates this mail. Follow this link to all your TCs in OASIS at: >>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with >>>> number 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>>> PO6 3AU >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> /chet >>>> ---------------- >>>> Chet Ensign >>>> Director of Standards Development and TC Administration >>>> OASIS: Advancing open standards for the information society >>>> http://www.oasis-open.org >>>> >>>> Primary: +1 973-378-3472 >>>> Mobile: +1 201-341-1393 >>>> >>>> Follow OASIS on: >>>> LinkedIn: http://linkd.in/OASISopen >>>> Twitter: http://twitter.com/OASISopen >>>> Facebook: http://facebook.com/oasis.open >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> /chet >>>> ---------------- >>>> Chet Ensign >>>> Director of Standards Development and TC Administration >>>> OASIS: Advancing open standards for the information society >>>> http://www.oasis-open.org >>>> >>>> Primary: +1 973-378-3472 >>>> Mobile: +1 201-341-1393 >>>> >>>> Follow OASIS on: >>>> LinkedIn: http://linkd.in/OASISopen >>>> Twitter: http://twitter.com/OASISopen >>>> Facebook: http://facebook.com/oasis.open >>>> >>> >>> -- >>> Jeff Mischkinsky >>> jeff.mischkinsky@oracle.com >>> Sr. Director, Oracle Fusion >>> Middleware +1(650)506- >>> 1975 >>> and Web Services Standards 500 >>> Oracle >>> Parkway, M/S 2OP9 >>> Oracle >>> >>> Redwood Shores, CA 94065 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this mail list, you must leave the OASIS TC that >>> generates this mail. Follow this link to all your TCs in OASIS at: >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>> >> > > > > -- > > /chet > ---------------- > Chet Ensign > Director of Standards Development and TC Administration > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-378-3472 > Mobile: +1 201-341-1393 > > Follow OASIS on: > LinkedIn: http://linkd.in/OASISopen > Twitter: http://twitter.com/OASISopen > Facebook: http://facebook.com/oasis.open -- Jeff Mischkinsky jeff.mischkinsky@oracle.com Sr. Director, Oracle Fusion Middleware +1(650)506-1975 and Web Services Standards 500 Oracle Parkway, M/S 2OP9 Oracle Redwood Shores, CA 94065

we can also allocate some time in Process Committee if that would be desireable/easier. FWIW I think the problem is that the SCA TCs are not really completely independent of each other. (I think of them as "almost separable".) When we were first developing SCA we discussed whether we should have one big TC or break things up to make development more manageable realizing that the trade-off was that we would have mutual dependencies. That said i'm not sure the real issue is independent TCs. The mutual dependencies would exist even if there was one TC. Having multiple TCs makes it more complicated because its harder to coordinate simultaneous votes on mutually dependent specs across TCs. I'm trying to remember why we don't allow DCR's for CSD's. I *think* it might be because we thought that since these were "only drafts", it was ok if there were some inconsistencies/bugs and not worth the effort to allow DCR's. The suggestion to allow TC's to decide if a change is not "substantive enough" is that we were never able to agree on a definition of what "enough" meant and TCs will almost always declare a change to be non- substantive, regardless. Actually we already have that issue on the Process Committee's agenda as part of figuring out if the requirement of new PRs for any change is creating too many PRs. cheers, jeff On Aug 08, 2011, at 5:14 PM, Chet Ensign wrote: > Mike, Sanjay - Actually, before launching on a broad chat, I think > it would make more sense for us to talk and frame the problem to be > solved so that conversation can be productive. Can I set up a call > with both of you, maybe for Wednesday or Thursday? That will give me > some time to draft a first pass at a problem statement that we can > use to set up productive discussion with others. > > /chet > > On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay <sanjay.patil@sap.com> > wrote: > I think it makes a lot of sense to have a conference call to jointly > define the problem and brainstorm the potentially solutions. > However, scheduling a call with the many interested parties from the > various time zones might become tricky. One option may be to check > with the SCA Assembly TC chairs if they would be ok to allocate some > of their weekly meeting time (Tue 8 AM PST) for this topic (assuming > that Chet and other concerned OASIS staff / TAB members can make > it). I believe that most of the SCA TC chairs are also members of > the SCA Assembly TC and moreover the SCA TCs typically look forward > to the SCA Assembly TC to resolve such cross-cutting issues and set > the precedent. Mike/Martin, any thoughts in this regard? > > > > Sanjay > > > > From: Chet Ensign [ mailto:chet.ensign@oasis-open.org ] > Sent: Monday, August 08, 2011 3:20 PM > To: Patil, Sanjay > Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul > Knight; Robin Cover > Subject: Re: [opencsa-liaison] Reference dependencies in various SCA > specs > > > > Sanjay, Mike et al - We started a discussion on this subject at the > TAB F2F and it is on our agenda. If you all would like, I would like > to schedule a conference call so that we can discuss together and ... > > > > - Jointly define the problem(s) - typically the most difficult part > of any of these conversations <grin> > > - Discuss what limitations of the current process / rules contribute > to the problem(s) > > - Brainstorm possible modifications that could resolve the problem(s) > > > > Is that something you all are interested in doing? > > Best, > > > > /chet > > On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay <sanjay.patil@sap.com> > wrote: > > > > Do other TC chairs have any further viewpoints on this topic? > > > > Since the resolution of this issue may involve changes to procedures > involving the TC Admin (and potentially the TC process!), we need to > decide how to take this issue forward. At the minimum, I think we > should inform the TC Admin about our opinions and start the > discussion. I am taking the liberty to copy Chet Ensign on this > email thread to set the ball rolling. > > > > Best wishes, > > Sanjay > > > > From: Mike Edwards [ mailto:mike_edwards@uk.ibm.com ] > Sent: Wednesday, August 03, 2011 1:33 AM > To: Patil, Sanjay > Cc: Anish Karmarkar; OASIS Liaison > Subject: RE: [opencsa-liaison] Reference dependencies in various SCA > specs > > > > > Sanjay, > > I agree with your views. > > In the latest round of changes, for example, I think that Assembly > is not affected by the changes to the > other specifications (Policy, WS-Binding, Java...), even though > those changes are normative. > > As a result, in my opinion, updating the Assembly spec to reference > the latest CSDs of the other specs > is a purely editorial process. > > Each TC may need to take a vote that agrees this for any particular > spec, but once that vote has > taken place, the update should be purely mechanical. No new public > reviews are required. > > > Yours, Mike > > Dr Mike Edwards > > Mail Point 137, Hursley Park > > <image001.gif> > > STSM > > Winchester, Hants SO21 2JN > > SCA, Cloud Computing & Services Standards > > United Kingdom > > Co-Chair OASIS SCA Assembly TC > > > > Chair UK ISO SC38 mirror committee (Cloud & SOA) > > > > IBM Software Group > > > > Phone: > > +44-1962 818014 > > > > Mobile: > > +44-7802-467431 (274097) > > > > e-mail: > > mike_edwards@uk.ibm.com > > > > > > > > > > > From: > > "Patil, Sanjay" <sanjay.patil@sap.com> > > To: > > Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa-liaison@lists.oasis-open.org > > > > Date: > > 02/08/2011 17:56 > > Subject: > > RE: [opencsa-liaison] Reference dependencies in various SCA specs > > > > > > > > I think the option 3 provides the required solution while retaining > the independence for the TCs to decide and follow their own > schedule. During CSD publication and PR, specs can make references > to the existing source material as of that time. Later, it should be > allowed to update the references without having to go for another > round of PR. I think it is reasonable to trust the TCs in making a > determination about whether a change in a reference is significant > enough to require another round of PR or not. > > Sanjay > > >
Original Message----- > From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] > Sent: Tuesday, August 02, 2011 9:22 AM > To: OASIS Liaison > Subject: [opencsa-liaison] Reference dependencies in various SCA specs > > As we all know, specs in all the SCA TCs have dependencies on each > other. For example, Assembly has a normative reference to Policy and > WS-Binding. To conform to Assembly one has to conform to Policy and > WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on > Assembly/Policy. The dependency graph is cyclic. > > A similar problem exists in SCA-J TC but without any cycles [1]. > > OASIS TC process solves this problem of cyclic references by using > designated cross references [2]. Unfortunately, CSDs cannot use this > mechanism as the process explicitly excludes it. So, two specs A and B > that depend on each other, will be in an infinite loop wrt updating > their normative references. Further compounding the problem (but is an > independent issue) is the fact that the new process requires at least > 15-days PR for any change (except the changes on the front page). So > any > time spec A or B is updated to update its normative reference it has > to > be PRed. > > I see three possible solutions to this: > 1) Fix the process to allow DCRs for CSDs (this is the only long term > solution, I think). > 2) Use the solution in [1] where spec A instead of using WDXX > reference > of B, uses the CSDYY reference of B. Where CSDYY is the what will > happen > to WDXX when the TC Admin processes the request for WDXX to be > published > as CSD. This means that the CSDs of A and B should be coordinated to > go > in the TC Admin queue around the same time. > 3) Get TC admin to update normative references when there is no > material > change. For example, in (2) above, WDXX and CSDYY are going to be > identical specs except for the front page. If spec A references WDXX, > the TC admin should be able to update that reference to CSDYY. A > similar > update would have to be done to spec B. > > -Anish > -- > > [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html > [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > > > > > > > > -- > > /chet > ---------------- > Chet Ensign > Director of Standards Development and TC Administration > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-378-3472 > Mobile: +1 201-341-1393 > > Follow OASIS on: > LinkedIn: http://linkd.in/OASISopen > Twitter: http://twitter.com/OASISopen > Facebook: http://facebook.com/oasis.open > > > > > -- > > /chet > ---------------- > Chet Ensign > Director of Standards Development and TC Administration > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-378-3472 > Mobile: +1 201-341-1393 > > Follow OASIS on: > LinkedIn: http://linkd.in/OASISopen > Twitter: http://twitter.com/OASISopen > Facebook: http://facebook.com/oasis.open > -- Jeff Mischkinsky jeff.mischkinsky@oracle.com Sr. Director, Oracle Fusion Middleware +1(650)506-1975 and Web Services Standards 500 Oracle Parkway, M/S 2OP9 Oracle Redwood Shores, CA 94065

Chet, I am happy to have an initial chat - and I can make both Wednesday & Thursday of this week at a time that should work for us all = any time between 17:00 - 19:00 UK on Wednesday == 09:00 - 11:00 Pacific any time between 17:30 - 19:00 UK on Wednesday == 09:30 - 11:00 Pacific Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: Chet Ensign <chet.ensign@oasis-open.org> To: "Patil, Sanjay" <sanjay.patil@sap.com> Cc: Mike Edwards/UK/IBM@IBMGB, Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa-liaison@lists.oasis-open.org>, OASIS TAB <tab@lists.oasis-open.org>, Paul Knight <paul.knight@oasis-open.org>, Robin Cover <robin@oasis-open.org> Date: 09/08/2011 01:15 Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs Mike, Sanjay - Actually, before launching on a broad chat, I think it would make more sense for us to talk and frame the problem to be solved so that conversation can be productive. Can I set up a call with both of you, maybe for Wednesday or Thursday? That will give me some time to draft a first pass at a problem statement that we can use to set up productive discussion with others.  /chet On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard?   Sanjay   From: Chet Ensign [mailto: chet.ensign@oasis-open.org ] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ...    - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin>  - Discuss what limitations of the current process / rules contribute to the problem(s)  - Brainstorm possible modifications that could resolve the problem(s)    Is that something you all are interested in doing?  Best,    /chet  On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote:   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Chet, I am happy to have an initial chat - and I can make both Wednesday & Thursday of this week at a time that should work for us all = any time between 17:00 - 19:00 UK on Wednesday == 09:00 - 11:00 Pacific any time between 17:30 - 19:00 UK on Wednesday == 09:30 - 11:00 Pacific Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: Chet Ensign <chet.ensign@oasis-open.org> To: "Patil, Sanjay" <sanjay.patil@sap.com> Cc: Mike Edwards/UK/IBM@IBMGB, Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa-liaison@lists.oasis-open.org>, OASIS TAB <tab@lists.oasis-open.org>, Paul Knight <paul.knight@oasis-open.org>, Robin Cover <robin@oasis-open.org> Date: 09/08/2011 01:15 Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs Mike, Sanjay - Actually, before launching on a broad chat, I think it would make more sense for us to talk and frame the problem to be solved so that conversation can be productive. Can I set up a call with both of you, maybe for Wednesday or Thursday? That will give me some time to draft a first pass at a problem statement that we can use to set up productive discussion with others.  /chet On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard?   Sanjay   From: Chet Ensign [mailto: chet.ensign@oasis-open.org ] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ...    - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin>  - Discuss what limitations of the current process / rules contribute to the problem(s)  - Brainstorm possible modifications that could resolve the problem(s)    Is that something you all are interested in doing?  Best,    /chet  On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote:   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

I can do Thursday AM Pacific time (on vacation on Wed). It will be great to get some of the TAB members also on the call since they seem to have already researched this issue!   From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] Sent: Tuesday, August 09, 2011 2:06 AM To: Chet Ensign Cc: OASIS Liaison; Paul Knight; Robin Cover; OASIS TAB Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Chet, I am happy to have an initial chat - and I can make both Wednesday & Thursday of this week at a time that should work for us all = any time between 17:00 - 19:00 UK on Wednesday == 09:00 - 11:00 Pacific any time between 17:30 - 19:00 UK on Wednesday == 09:30 - 11:00 Pacific Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: Chet Ensign <chet.ensign@oasis-open.org> To: "Patil, Sanjay" <sanjay.patil@sap.com> Cc: Mike Edwards/UK/IBM@IBMGB, Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa-liaison@lists.oasis-open.org>, OASIS TAB <tab@lists.oasis-open.org>, Paul Knight <paul.knight@oasis-open.org>, Robin Cover <robin@oasis-open.org> Date: 09/08/2011 01:15 Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Mike, Sanjay - Actually, before launching on a broad chat, I think it would make more sense for us to talk and frame the problem to be solved so that conversation can be productive. Can I set up a call with both of you, maybe for Wednesday or Thursday? That will give me some time to draft a first pass at a problem statement that we can use to set up productive discussion with others.  /chet On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard?   Sanjay   From: Chet Ensign [mailto: chet.ensign@oasis-open.org ] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ...    - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin>  - Discuss what limitations of the current process / rules contribute to the problem(s)  - Brainstorm possible modifications that could resolve the problem(s)    Is that something you all are interested in doing?  Best,    /chet  On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote:   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com         From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU   -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

I can do Thursday AM Pacific time (on vacation on Wed). It will be great to get some of the TAB members also on the call since they seem to have already researched this issue!   From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] Sent: Tuesday, August 09, 2011 2:06 AM To: Chet Ensign Cc: OASIS Liaison; Paul Knight; Robin Cover; OASIS TAB Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Chet, I am happy to have an initial chat - and I can make both Wednesday & Thursday of this week at a time that should work for us all = any time between 17:00 - 19:00 UK on Wednesday == 09:00 - 11:00 Pacific any time between 17:30 - 19:00 UK on Wednesday == 09:30 - 11:00 Pacific Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com       From: Chet Ensign <chet.ensign@oasis-open.org> To: "Patil, Sanjay" <sanjay.patil@sap.com> Cc: Mike Edwards/UK/IBM@IBMGB, Anish Karmarkar <Anish.Karmarkar@oracle.com>, OASIS Liaison <opencsa-liaison@lists.oasis-open.org>, OASIS TAB <tab@lists.oasis-open.org>, Paul Knight <paul.knight@oasis-open.org>, Robin Cover <robin@oasis-open.org> Date: 09/08/2011 01:15 Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Mike, Sanjay - Actually, before launching on a broad chat, I think it would make more sense for us to talk and frame the problem to be solved so that conversation can be productive. Can I set up a call with both of you, maybe for Wednesday or Thursday? That will give me some time to draft a first pass at a problem statement that we can use to set up productive discussion with others.  /chet On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard?   Sanjay   From: Chet Ensign [mailto: chet.ensign@oasis-open.org ] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we can discuss together and ...    - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin>  - Discuss what limitations of the current process / rules contribute to the problem(s)  - Brainstorm possible modifications that could resolve the problem(s)    Is that something you all are interested in doing?  Best,    /chet  On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote:   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Binding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com         From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/2011 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CSDYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU   -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

I can’t go on a few days vacation and leave you lot alone;-) I thought we had covered the issues at the TAB F2F – there is no new information here. We need a solution not a problem statement!   There are two issues:   1)       permanent changes to the TC Process, to which Chet has an action to propose to the TAB/Board Process SC – possibly involving changes to 2.18 (6), allowable changes and 2.19 Designated Cross References being possible on C*Ds 2)       a temporary solution to allow the interbreeding of SCA specs to progress in a reasonable manner while waiting on 1) to be approved.     Martin.     From: Chet Ensign [mailto:chet.ensign@oasis-open.org] Sent: 09 August 2011 01:15 To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Mike, Sanjay - Actually, before launching on a broad chat, I think it would make more sense for us to talk and frame the problem to be solved so that conversation can be productive. Can I set up a call with both of you, maybe for Wednesday or Thursday? That will give me some time to draft a first pass at a problem statement that we ! can use to set up productive discussion with others.    /chet On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most ! of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard?   Sanjay   From: Chet Ensign [mailto: chet.ensign@oasis-open.org ] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we! can discuss together and ...    - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin>  - Discuss what limitations of the current process / rules contribute to the problem(s)  - Brainstorm possible modifications that could resolve the problem(s)    Is that something you all are interested in doing?  Best,    /chet  On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote:   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Bi! nding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com         From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/20! 11 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I ! think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CS! DYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

I can’t go on a few days vacation and leave you lot alone;-) I thought we had covered the issues at the TAB F2F – there is no new information here. We need a solution not a problem statement!   There are two issues:   1)       permanent changes to the TC Process, to which Chet has an action to propose to the TAB/Board Process SC – possibly involving changes to 2.18 (6), allowable changes and 2.19 Designated Cross References being possible on C*Ds 2)       a temporary solution to allow the interbreeding of SCA specs to progress in a reasonable manner while waiting on 1) to be approved.     Martin.     From: Chet Ensign [mailto:chet.ensign@oasis-open.org] Sent: 09 August 2011 01:15 To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Mike, Sanjay - Actually, before launching on a broad chat, I think it would make more sense for us to talk and frame the problem to be solved so that conversation can be productive. Can I set up a call with both of you, maybe for Wednesday or Thursday? That will give me some time to draft a first pass at a problem statement that we ! can use to set up productive discussion with others.    /chet On Mon, Aug 8, 2011 at 6:40 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote: I think it makes a lot of sense to have a conference call to jointly define the problem and brainstorm the potentially solutions. However, scheduling a call with the many interested parties from the various time zones might become tricky. One option may be to check with the SCA Assembly TC chairs if they would be ok to allocate some of their weekly meeting time (Tue 8 AM PST) for this topic (assuming that Chet and other concerned OASIS staff / TAB members can make it). I believe that most ! of the SCA TC chairs are also members of the SCA Assembly TC and moreover the SCA TCs typically look forward to the SCA Assembly TC to resolve such cross-cutting issues and set the precedent. Mike/Martin, any thoughts in this regard?   Sanjay   From: Chet Ensign [mailto: chet.ensign@oasis-open.org ] Sent: Monday, August 08, 2011 3:20 PM To: Patil, Sanjay Cc: Mike Edwards; Anish Karmarkar; OASIS Liaison; OASIS TAB; Paul Knight; Robin Cover Subject: Re: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, Mike et al - We started a discussion on this subject at the TAB F2F and it is on our agenda. If you all would like, I would like to schedule a conference call so that we! can discuss together and ...    - Jointly define the problem(s) - typically the most difficult part of any of these conversations <grin>  - Discuss what limitations of the current process / rules contribute to the problem(s)  - Brainstorm possible modifications that could resolve the problem(s)    Is that something you all are interested in doing?  Best,    /chet  On Mon, Aug 8, 2011 at 5:05 PM, Patil, Sanjay < sanjay.patil@sap.com > wrote:   Do other TC chairs have any further viewpoints on this topic?   Since the resolution of this issue may involve changes to procedures involving the TC Admin (and potentially the TC process!), we need to decide how to take this issue forward. At the minimum, I think we should inform the TC Admin about our opinions and start the discussion. I am taking the liberty to copy Chet Ensign on this email thread to set the ball rolling.   Best wishes, Sanjay   From: Mike Edwards [mailto: mike_edwards@uk.ibm.com ] Sent: Wednesday, August 03, 2011 1:33 AM To: Patil, Sanjay Cc: Anish Karmarkar; OASIS Liaison Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   Sanjay, I agree with your views. In the latest round of changes, for example, I think that Assembly is not affected by the changes to the other specifications (Policy, WS-Bi! nding, Java...), even though those changes are normative. As a result, in my opinion, updating the Assembly spec to reference the latest CSDs of the other specs is a purely editorial process.   Each TC may need to take a vote that agrees this for any particular spec, but once that vote has taken place, the update should be purely mechanical.  No new public reviews are required. Yours, Mike Dr Mike Edwards  Mail Point 137, Hursley Park STSM  Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards  United Kingdom Co-Chair OASIS SCA Assembly TC   Chair UK ISO SC38 mirror committee (Cloud & SOA)   IBM Software Group   Phone: +44-1962 818014   Mobile: +44-7802-467431 (274097)   e-mail: mike_edwards@uk.ibm.com         From: "Patil, Sanjay" < sanjay.patil@sap.com > To: Anish Karmarkar < Anish.Karmarkar@oracle.com >, OASIS Liaison < opencsa-liaison@lists.oasis-open.org > Date: 02/08/20! 11 17:56 Subject: RE: [opencsa-liaison] Reference dependencies in various SCA specs   I ! think the option 3 provides the required solution while retaining the independence for the TCs to decide and follow their own schedule. During CSD publication and PR, specs can make references to the existing source material as of that time. Later, it should be allowed to update the references without having to go for another round of PR. I think it is reasonable to trust the TCs in making a determination about whether a change in a reference is significant enough to require another round of PR or not. Sanjay
Original Message----- From: Anish Karmarkar [ mailto:Anish.Karmarkar@oracle.com ] Sent: Tuesday, August 02, 2011 9:22 AM To: OASIS Liaison Subject: [opencsa-liaison] Reference dependencies in various SCA specs As we all know, specs in all the SCA TCs have dependencies on each other. For example, Assembly has a normative reference to Policy and WS-Binding. To conform to Assembly one has to conform to Policy and WS-Binding. Policy in turn depends on Assembly. WS-Binding depends on Assembly/Policy. The dependency graph is cyclic. A similar problem exists in SCA-J TC but without any cycles [1]. OASIS TC process solves this problem of cyclic references by using designated cross references [2]. Unfortunately, CSDs cannot use this mechanism as the process explicitly excludes it. So, two specs A and B that depend on each other, will be in an infinite loop wrt updating their normative references. Further compounding the problem (but is an independent issue) is the fact that the new process requires at least 15-days PR for any change (except the changes on the front page). So any time spec A or B is updated to update its normative reference it has to be PRed. I see three possible solutions to this: 1) Fix the process to allow DCRs for CSDs (this is the only long term solution, I think). 2) Use the solution in [1] where spec A instead of using WDXX reference of B, uses the CSDYY reference of B. Where CSDYY is the what will happen to WDXX when the TC Admin processes the request for WDXX to be published as CSD. This means that the CSDs of A and B should be coordinated to go in the TC Admin queue around the same time. 3) Get TC admin to update normative references when there is no material change. For example, in (2) above, WDXX and CS! DYY are going to be identical specs except for the front page. If spec A references WDXX, the TC admin should be able to update that reference to CSDYY. A similar update would have to be done to spec B. -Anish -- [1] http://lists.oasis-open.org/archives/sca-j/201107/msg00028.html [2] http://www.oasis-open.org/policies-guidelines/tc-process#crossRefs --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open