Re: CR and 'at risk'

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
> 
> 
> 
>

Received on Friday, 15 August 2003 09:03:17 UTC