action items for editing

As follow up to our conversation at
the f2f about how to track the misc editing items we are likely to come
up with, I propose to start using the action items on our web site.  If
this doesn't work, we'll revert to a spreadsheet but I like the visibility
of hte action item list.  

One question to you all - would you
prefer that we use hte action item list on the mail tc web page (would
allow everyone to add action items as they are found) or the one on the
spec editing team page (only this group could add/edit an item)?  

Either way the action items can be visible
to the whole group.  

Let me know you're opinion - I'm inclined
toward the main page, but not very strongly.  

We can keep track of status according
to assignment and due date fields - anyone can open an action item, once
an editor's name and date are there, we know someone has taken the pen
to fix one.  When we meet we can go through any open ones not yet
assigned - if there are concerns/questions we'll leave as is and email
the originator, if someone will work on it soon, we'll update the fields,
if no one is ready but we agree it should be done as stated, I'll put my
name as owner till someone is ready.  

Does this sound reasonable? 

I added this one - you can see it on
the TC web page as number 5.  

Regards, Diane

IBM  Emerging Internet Software Standards



(919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709

----- Forwarded by Diane
Jordan/Raleigh/IBM on 01/26/2006 12:07 PM -----

Ron Ten-Hove <>

01/25/2006 02:02 PM

To

Ron Ten-Hove <>

cc



Subject

Re: [wsbpel] Section G: Minor Nits

Just to capture what was discussed in today's meeting,
it was pointed out that SOAP 1.1 is also unneeded as a normative reference.
Good luck, editors! Thanks for all your hard work. (Trust me, I know how
difficult it is.)

Ron Ten-Hove wrote: 

Whilst browsing the latest committee draft of our specification,
I happened upon section G, References (Normative). I noted a few
errors:

XLANG and WSFL are listed; however, I believe are not
even mentioned in the specification text anymore, and should be deleted.

UDDI is also listed, but is only mentioned briefly in
the introductory text, and can hardly be regarded as a normative dependency,
and should be deleted.

Also questionable as normative dependencies: sagas,
trends. These ought to be referenced non-normatively; BPEL's compensation
and LRT mechanisms are decidedly different from sagas and trends, respectively.
Sagas and trends certainly aren't required to define WS-BPEL.

XSLT 1.0 is now a normative dependency of WS-BPEL (per
the issue 11 resolution), and should be included in the list. (I don't
see the issue 11 resolution text in the specification yet, so I may be
getting ahead of the editting team).I'm pretty
sure these aren't worth creating a formal issue for; this email ought to
serve to track the problem. Or perhaps this requires discussion?

-Ron