Re: CR and 'at risk'

Dan--

What you say may be strictly correct as far as procedure goes, but from 
where I sit, many of the problems you describe below have been caused by 
our willingness to "go the extra mile" with people making comments well 
after last call, and making corresponding changes, in a sincere effort 
to address problems people had, rather than our "pushing the boundaries" 
(as if somehow we were thinking up these changes all by ourselves and 
attempting to evade the same last call constraints everyone else is 
bound to).  If, as a result of all this, we're going to have to go to a 
second last call, which will probably result in additional comments 
about all sorts of issues not currently on the table that we have to 
keep track of, formally respond to, etc., then I for one am going to be 
really bloody-minded about formal process as regards to last call dates, 
and rejecting additional comments, and I suggest the WG as a whole will 
have to be too.

--Frank

Dan Brickley wrote:

> Jeremy, RDFCore,
> 
> I'm sympathetic to an approach along these lines, but not yet convinced 
> we can navigate our way through the process that way. I believe given the 
> current I18N-related controversy and fact that we haven't actually published any
> specs in months (but have implicitly allowed or even encouraged our 
> unpublished Editor's drafts to be treated as Working Drafts), that we
> owe the world another cycle of docs before we go to PR. The big question 
> is what class of document we publish under. As you noted earlier, 
> going through another LC would is a pretty depressing prospect. At this
> stage though, I'm not sure it can be definitively ruled out, since the WG has 
> changed its mind post-LC on XML Literal (as well as on other things, 
> eg 'iff' -> 'if' for RDFS' semantics). I do hope we can negotiate a path 
> through this asap, hopefully one that allows us to seek feedback on the 
> new design without constituting a major setback. I fear that our
> collective anxiety to reach PR and the expectation that our 'next' step
> will be PR has had the negative effect of dissuading us from
> republishing our documents as W3C Technical Reports in any form. One
> way out of that logjam would be to propose we go to CR as you outline 
> below; another that occurs to me would be to publish as vanilla Working 
> Drafts without explicit status, putting our unpublished design into 
> a more cite-able form. I would prefer CR.
> 
> We have, to be blunt, been pushing at the boundaries w.r.t. how far it is
> reasonable to change things beyond Last Call without doing another. I 
> understand the concerns at HP and appreciate the huge amount of support
> the HP SW team have provided these working groups. We all want this work 
> finished as soon as possible. But we also have to work with the definition of 
> 'Last Call' that the rest of W3C are held accountable to. I fear that an 
> independent examination of our post-LC unpublished specs with the LC 
> version would raise eyebrows w.r.t. skipping a 2nd LC. It may be that we 
> can assemble a compelling case going to to CR, but given 
> http://www.w3.org/2003/06/Process-20030618/tr.html#return-to-wg
> http://www.w3.org/2003/06/Process-20030618/tr.html#substantive-change
> that will be a challenge, and not something we can take for granted, even though 
> we are all aware of the danger of the WG losing members and energy. 
> Until the WG decides what design to publish in its next set of TRs, we won't 
> know for sure how plausible our 'we don't need another LC' claim will be.
> 
> My own view is that, if we can demonstrate support for proceeding to an 
> 'at risk'-annotated CR from all parties in the current dispute, and 
> formal dependents (eg. the WebOnt WG), we could perhaps assemble a 
> convincing case for going to CR. Nobody wants the WG to fizzle out by 
> being stuck in an LC loop for months and months; I hope there is some scope 
> for pragmatism. Where we are on strong ground is that we have done our 
> best to use the Exclusion C14n spec rather than make up our own
> variation on that theme; there are good reasons for claiming that
> RDFCore has done the best it can with the raw materials available.
> 
> It may be that we should take the time to write up an explanation of why 
> we believe there is no way (eg. via pre-process addition of a lang
> tag'd wrapper element) to address the I18N group's desire to language
> tag markup fragments without reversing our decisions (a) to use exc-c14n and (b)
> not to allow datatyped literals to carry a lang tag unless stuffed into
> their content/payload. It may be that we should have one more push at 
> finding such a compromise design. I have only recently acquired enough 
> understanding of these issues to comment on them technically, but I'm 
> coming to the view that the clear documentation of such an attempt might
> be one way to unblock this logjam and find us a way to progress the
> specs. And that's without considering the possibility that we might 
> actually succeed in identifying a workable compromise. (I know you've
> tried hard already...).
> 
> We are being pulled in several different ways here. One thing to my mind 
> is clear. We need to get some updated tech reports on to the W3C /TR/
> page asap. Our latest documented designs date from January; 7 months
> ago. Eric as staff contact and Activity lead can comment in more detail
> on the process aspects and possible options. 
> 
> Dan
> 
> 
> * Jeremy Carroll <jjc@hplb.hpl.hp.com> [2003-08-15 12:33+0100]
> 
>>
>>The process document
>>
>>http://www.w3.org/2003/06/Process-20030618/tr.html#cfi
>>
>>allows for some features to be labelled as 'at risk'.
>>[[
>>In the Call for Implementations, the Working Group MAY identify specific 
>>features of the technical report as being "features at risk." General 
>>statements such as "We plan to remove any unimplemented feature" are not 
>>acceptable; the Working Group MUST precisely identify any features at risk. 
>>Thus, in response to a Call for Implementations, reviewers can indicate 
>>whether they would formally object to the removal of the identified 
>>features.
>>]]
>>
>>We could proceed to CR and label the current XMLLiteral design as 'at risk' 
>> (because of the xml:lang issue) and specifically indicate one or two 
>>other designs that we may change to if implementor feedback indicates the 
>>current design is broken. We could continue to seek feedback on this issue 
>>within the SOTD - even the design concerns (IMO).
>>
>>(WebOnt did this - which is a somewhat liberal reading of the above text)
>>
>>We could specifically request implementations that:
>>- provide API or query support for accessing language information in both 
>>plain literals and XMLLiterals
>>
>>
>>Given satisfactory implementation reports we can then proceed to PR ... 
>>maybe.
>>
>>Jeremy
>>
>>
>>
>>
>>
> 


-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

Received on Friday, 15 August 2003 09:39:52 UTC