OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

opencsa-liaison message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]