W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > August 2003

Re: CR and 'at risk'

From: Jos De_Roo <jos.deroo@agfa.com>
Date: Fri, 15 Aug 2003 15:44:28 +0200
To: "Dan Brickley <danbri" <danbri@w3.org>
Cc: Jeremy Carroll <jjc@hplb.hpl.hp.com>, w3c-rdfcore-wg@w3.org, w3c-rdfcore-wg-request@w3.org
Message-ID: <OFFD93AF96.0CA91B73-ONC1256D83.0049C777-C1256D83.004B7B8D@agfa.be>


I have to leave in about 10 min, but I think we have to
also look to this from an engineering point of view
and I learned that to be healthy one has to take one
risk a day. We are close to having this stuff put in
thousends of machines (in the form of independent
observers collecting triples, detecting inconsistencies etc)
and we have to move faster evt by explicitly pointing
to stuff "at risk".


--
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/


                                                                                                                                        
                      Dan Brickley                                                                                                      
                      <danbri@w3.org>           To:       Jeremy Carroll <jjc@hplb.hpl.hp.com>                                          
                      Sent by:                  cc:       w3c-rdfcore-wg@w3.org                                                         
                      w3c-rdfcore-wg-req        Subject:  Re: CR and 'at risk'                                                          
                      uest@w3.org                                                                                                       
                                                                                                                                        
                                                                                                                                        
                      2003-08-15 02:52                                                                                                  
                      PM                                                                                                                
                                                                                                                                        
                                                                                                                                        





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:44:41 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:59:38 EDT