sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] Re: [members] Please follow these steps to avoidproblems with your requests for TC Admin support
- From: Simon Holdsworth <simon_holdsworth@uk.ibm.com>
- To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Mon, 1 Aug 2011 11:30:56 +0100
Anish,
Currently our specs don't use the exact
formal normative reference format in the "related works" section,
possibly that's something we need to fix. I don't see the need for
reference to a specific version in related works, as that's not a normative
link and intended to be there to provide a wider context for the document.
Wrt. to the "predictive" references,
I don't object to that approach, although there is still the possibility
that one of assembly or policy goes through another CSD level before CS,
in which case the problem still exists that the referencing specs would
need to either have yet another CSD/PR to update those links, or we would
need to be able to skip a version when we make the CS request (skipping
direct to CS) - in the latter case there's no need for the predictive refernces.
I don't see an issue with updating a
designated cross reference from an older CSD to the proposed CS of the
same spec if the TC resolves to make that change as part of the CS motion,
but that's something I am trying to clarify with TC admin.
I'm assuming that we will coordinate
CS across the SCA specs, rather than doing them piecemeal.
Simon Holdsworth
Anish Karmarkar <Anish.Karmarkar@oracle.com>
wrote on 29/07/2011 19:12:17:
> From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
> To: Simon Holdsworth/UK/IBM@IBMGB
> Cc: Chet Ensign <chet.ensign@oasis-open.org>,
Paul Knight
> <paul.knight@oasis-open.org>, Robin Cover <robin@oasis-open.org>,
> OASIS TAB <tab@lists.oasis-open.org>, sca-bindings@lists.oasis-open.org
> Date: 29/07/2011 19:12
> Subject: Re: [sca-bindings] Re: [members] Please
follow these steps
> to avoid problems with your requests for TC Admin support
>
> Few comments:
>
> 1) WRT the suggestion from Chet:
>
> "One option is to use the "Latest Version" link from
the spec's front
> page in your cross-reference. This will resolve to the latest of the
> CSD's for the specific specification rather than to the published
> version at the time you approved your CSD. Your risk there of course
> is that the most recent CSD may have changes in it that you haven't
> accounted for in your spec - that is a risk you would need to weigh
> yourselves."
>
> I don't believe the normative reference format in the template allows
> that. The URL in the reference may point to the latest link, but the
> reference has to list the title, date and state/stage of the OASIS
spec.
>
> 2) This is how the SCA-J TC is planning to deal with its reference
> problem (note there aren't any cyclic dependencies here, so the SCA-J
TC
> doesn't need the DCRs; at least not yet):
> http://lists.oasis-open.org/archives/sca-j/201107/msg00029.html
>
> 3) I think between DCRs (if they are extended to CSDs; currently they
> are not) and allowing specs to reference other specs that are in the
> TCAdmin pipeline as outlined in (2) above, we should be able to solve
> our reference problems. I'm not in favor of using references to the
> 'latest'. Especially with the new OASIS policy in mind, of requiring
at
> least a 15-day review if there is any change to the spec (other than
> front page matter). A change in reference may be a big deal for a
spec.
> And it is not always easily apparent if it is a big deal or not for
a
> particular spec unless you examine it closely. The referenced spec
> itself may not have changed except for maybe one of *its* references
and
> so on -- it is turtles all the way down. Allowing a spec to reference
> the latest link of another spec is just asking for trouble IMHO.
>
> -Anish
> --
>
>
> On 7/29/2011 2:47 AM, Simon Holdsworth wrote:
> > Chet,
> >
> > (including SCA Bindings TC on my response as this is the subject
of
> > discussion at the TC).
> >
> > Thanks for the response. At least for the spec documents I am
editor for
> > we have take the approach that the "related works"
section contains
> > "latest" links and not links to specific versions,
however the
> > "Normative references" section does have references
to specific
> > versions. For links between specifications within the member
section,
> > the expectation is that the reference is to that specific version
or any
> > more recent, requiring the TCs to resolve any backward incompatibilities
> > and that such changes would require new CSDs with updated references.
> >
> > There's one remaining question I have which is probably best
posed with
> > a scenario:
> >
> > The SCA Assembly TC requests upload of CSD08 of the Assembly
> > specification. This includes a normative reference to CSD04 of
the SCA
> > Web Service Binding owned by the SCA Bindings TC (in fact this
spec
> > includes normative references to around 10 specs from other SCA
TCs).
> > The CSD upload is successful and 15 day public review goes ahead.
> >
> > The SCA Bindings TC then requests upload of CSD05 of the Web
Service
> > Binding specification. This includes changes which require public
> > review, but no incompatible changes related with the SCA Assembly
> > specification. The Web Service Binding specification includes
a
> > normative reference to the SCA Assembly Specification CSD08.
The CSD
> > upload is successful and 15 day public review goes ahead.
> >
> > Now the SCA Assembly and SCA Bindings TCs want to take their
> > specifications to CS level (I'm assuming here that the TCs coordinate
> > the CS submissions of a number of specifications) However the
Assembly
> > specification includes a reference to Web Service Binding CSD04
which is
> > not the most recent version.
> >
> > The question then is, would the SCA Assembly TC have to have
another
> > public review of the Assembly specification (and therefore a
new CSD,
> > and therefore making the Web Service binding spec refer to an
older
> > version of Assembly), or would it be acceptable for the CS motion
to
> > include a designated cross reference which updates the Web Service
> > Binding reference from CSD04 directly to the Web Service Binding
CS
> > (skipping CSD05)?
> >
> > There has been debate in the SCA Bindings TC around the CSD/PR
requests
> > we have in the pipeline at the moment. We have Web Service binding
and
> > JMS Binding specs in the CSD/PR pipeline which refer to the SCA
Assembly
> > specification (CSD8), however that is also in the pipeline ahead
of
> > them, and so when they get to be processed the reference to Assembly
> > will already be out of date, (and also the references from Assembly
spec
> > to those specs will be out of date). However I can't see any
way to
> > indicate in the upload requests that these normative references
should
> > be updated other than informal comments. The TC is not keen on
the idea
> > of having all these CSD requests processed as a single unit of
work,
> > assuming this will inevitably introduce additional delays. This
also
> > would not solve the issue of the circular references between
the specs.
> > The answer to the scenario above might render this moot if we
can update
> > all the normative references between SCA specification documents
as part
> > of the CS process, and not worry about the versions mentioned
in the
> > current CSDs being to the most recent.
> >
> > Thanks, Simon
> >
> > Simon Holdsworth
> >
> >
> >
> > From: Chet Ensign <chet.ensign@oasis-open.org>
> > To: Simon Holdsworth/UK/IBM@IBMGB
> > Cc: Robin Cover <robin@oasis-open.org>, Paul Knight
> > <paul.knight@oasis-open.org>, OASIS TAB <tab@lists.oasis-open.org>
> > Date: 29/07/2011 00:18
> > Subject: Re: [members] Please follow these steps to avoid problems
with
> > your requests for TC Admin support
> > ------------------------------------------------------------------------
> >
> >
> >
> > Hi Simon,
> >
> > The TAB discussed this issue today. This is a problem in every
> > standards organization where multiple parties are moving work
forward
> > on different schedules and we are trying to come up with proposals
to
> > the Board Process Committee. In regard to your specific questions...
> >
> > On Mon, Jul 25, 2011 at 8:19 AM, Simon Holdsworth
> > <simon_holdsworth@uk.ibm.com> wrote:
> > > So really the question is how we keep these cross-references
up to date,
> > > without requiring a new CSD and PR of all the specs
every time one of the
> > > related specs is updated
> > One option is to use the "Latest Version" link from
the spec's front
> > page in your cross-reference. This will resolve to the latest
of the
> > CSD's for the specific specification rather than to the published
> > version at the time you approved your CSD. Your risk there of
course
> > is that the most recent CSD may have changes in it that you haven't
> > accounted for in your spec - that is a risk you would need to
weigh
> > yourselves.
> >
> > - and whether its OK for the TC to request that a
> > > normative reference within a spec is updated as part
of the CSD upload
> > > request.
> > The TAB discussed modifying Section 2.19, Designated Cross References
> > to apply to CSD's as well as CS's. That is the mechanism you
would
> > use. I will be sending the Chairs an explanation and update on
that in
> > the near future. Under that step, you would make a special motion
as
> > part of your approval to publish as a CSD. Understand that one
result
> > of that is that publication of your CSD is put on hold until
the
> > referenced spec is completed and published.
> >
> > Does this give you the information you need? If you would like,
I
> > would be happy to get on the phone and talk about this further.
> >
> > Best,
> >
> > /chet
> >
> > >
> > > [1] http://tools.oasis-open.org/issues/browse/TCADMIN-578
> > >
> > > Thanks, Simon
> > >
> > > Simon Holdsworth
> > > STSM, SCA Bindings Architect; Master Inventor; OASIS
SCA Bindings TC
> > Chair,
> > > AT&T and Boeing Lab Advocate
> > > MP 211, IBM UK Labs, Hursley Park, Winchester SO21
2JN, UK
> > > Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
> > > Internet - Simon_Holdsworth@uk.ibm.com
> > >
> > >
> > >
> > > From: Chet Ensign <chet.ensign@oasis-open.org>
> > > To: chairs@lists.oasis-open.org, members@lists.oasis-open.org
> > > Cc: Staff <staff@lists.oasis-open.org>, OASIS
Board Process Committee
> > > <board-process@lists.oasis-open.org>, OASIS
TAB
> > <tab@lists.oasis-open.org>,
> > > Laurent Liscia <laurent.liscia@oasis-open.org>,
Robin Cover
> > > <robin@oasis-open.org>, Paul Knight <paul.knight@oasis-open.org>
> > > Date: 23/07/2011 21:11
> > > Subject: [members] Please follow these steps to avoid
problems with
> > > your requests for TC Admin support
> > > ________________________________
> > >
> > >
> > > All,
> > >
> > > We have recently encountered some problems with TC
requests to create
> > > committee drafts and submit them to public review.
Specifically:
> > >
> > > - Meeting minutes or ballots have not clearly identified
the source
> > > files for the Working Draft being voted on or failed
to clearly record
> > > the vote
> > > - The Working Draft submitted to TC Administration
for processing has
> > > been different from the one the TC approved
> > > - The TC has approved unfinished Working Drafts or
requested that TC
> > > Administration make changes to the content of the
Working Draft after
> > > submission
> > >
> > > In some cases, we have had to reject requests as submitted
and ask the
> > > TC to address these problems.
> > >
> > > Please, in order to avoid added delays in servicing
your requests,
> > > ensure that you adhere to the following requirements
as published in
> > > the TC Process and related documents [1] when you
submit a request:
> > >
> > > 1. Ensure that the motions you vote on to approve
Working Drafts as
> > > Committee Specification/Note Drafts include the URI
to the zip file or
> > > unique archive containing all component materials
that are to be
> > > approved by the TC and that the vote itself is clearly
recorded in the
> > > meeting minutes. (Note that the archive must include
editable source
> > > format files and all component files that are part
of the Working
> > > Draft.)
> > >
> > > For example, a motion in your minutes such as the
following will meet
> > > this requirement:
> > >
> > > "Motion: Shall the OASIS Mumble-Mumble TC approve
Mumble
> > > Profile Version 1.0 Working Draft 07 and its associated
artifacts
> > > packaged together in
> > > http://www.oasis-open.org/committees/download.php/39296/Mumble07.zip
> > > as OASIS Mumble Profile v1.0
> > > Committee Specification Draft 01 and direct the Chair
to
> > > submit this Working Draft to TC Administrator for
creation and upload
> > > as
> > > soon as practicable.
> > >
> > > Motion made by Bob Smith. Seconded by Shirley Jones.
7 votes
> > > in favor, 1 abstention, no votes opposed. Motion passes."
> > >
> > > 2. Ensure that the TC Administration request (made
via
> > > http://www.oasis-open.org/resources/tc-admin-requests)
includes the
> > > link to the ballot or to the minutes where the motion
and approval
> > > were made and the same URI to the zip file or archive
approved.
> > >
> > > We have encountered requests where the minutes provided
actually
> > > mentioned earlier meetings where the draft was approved
and we've had
> > > to request that the reference be corrected. We have
also received
> > > requests where the Working Draft URI provided was
something different
> > > from what the TC voted to approve and we've had to
reject those
> > > requests.
> > >
> > > 3. Ensure that your Working Draft is complete and
ready to go.
> > >
> > > We cannot accept as valid a submission approved by
the TC "…contingent
> > > on Chet fixing those links he's been promising to
fix for weeks." Get
> > > it all done - then vote to approve it.
> > >
> > > 4. And should you find that you need to make some
changes or
> > > corrections after submitting a Working Draft to TC
Administration,
> > > first, get in touch with us so that we can coordinate
next steps with
> > > you and second, create a new, complete, numerically
incremented
> > > Working Draft and hold another TC vote to approve
it. Per TC Process
> > > rules, we cannot accept requests to piece-meal replace
parts of your
> > > submitted Working Draft with replacements.
> > >
> > > If we have not yet assigned anyone to your request
and started work on
> > > the draft, we can update the existing request with
the new Working
> > > Draft. If we have assigned someone to the ticket and
work has begun,
> > > we reserve the right require you to enter a new request.
> > >
> > > I realize that this may look like a lot of bureaucracy
to some,
> > > particularly item 4. So I want to stress that the
TC Process rules are
> > > in place to ensure that the integrity and quality
of your work is
> > > unassailable. We ask you to take the steps above in
order to guarantee
> > > to the world that your Committee Specifications, Committee
Notes or
> > > OASIS Standards are the unalloyed work of your TC
and that their
> > > quality and integrity cannot be called into question.
The work is your
> > > accomplishment; we want to make sure that everyone
respects it.
> > >
> > > Please let me know if you have any questions.
> > >
> > > Best regards,
> > >
> > > /chet
> > > ----------------
> > > Chet Ensign
> > > Director of Standards Development and TC Administration
> > > OASIS: Advancing open standards for the information
society
> > > http://www.oasis-open.org
<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
> > >
> > > ---
> > >
> > > [1] References
> > >
> > > *** OASIS TC Process ***
> > >
> > > 2.18 Work Product Quality
> > >
> > http://www.oasis-open.org/policies-guidelines/tc-
> process-2010-07-28#specQuality
> > > File Formats
> > >
> > http://www.oasis-open.org/policies-guidelines/tc-
> process-2010-07-28#quality-fileFormats
> > > Multi-Part Work Products
> > >
> > http://www.oasis-open.org/policies-guidelines/tc-
> process-2010-07-28#quality-multiPart
> > >
> > > *** TC Handbook ***
> > >
> > > Approval of a Committee Specification Draft
> > >
> > http://docs.oasis-open.org/TChandbook/Reference/CommitteeSpecDrafts.html#wd
> > >
> > > ---------------------------------------------------------------------
> > >
> > > This email list is used solely by OASIS for official
consortium
> > > communications.
> > >
> > > Opt-out requests may be sent to member-services@oasis-open.org,
> > however, all
> > > members are strongly encouraged to maintain a subscription
to this list.
> > >
> > >
> > >
> > >
> > >
> > > ________________________________
> > >
> > > 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
<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/
> >
> >
> >
> >
> >
> >
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]