W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2006

Re: rq24 ready for publication

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Thu, 21 Sep 2006 17:02:12 +0100
Message-Id: <EC6200B5-99E9-4582-B8FA-B5D1F717C62B@cs.man.ac.uk>
Cc: Kendall Clark <kendall@monkeyfist.com>, dawg mailing list <public-rdf-dawg@w3.org>
To: andy.seaborne@hp.com

On Sep 21, 2006, at 4:32 PM, Seaborne, Andy wrote:

[snip]
>> Andy, what conclusion are we supposed to draw from this relevant  
>> to the discussion?
>> Kendall
>
> There were statements about what the decision was so I dug out the  
> wording on-record.  It does not say "Working Draft" - that seems to  
> be a cause of confusion.

I don't see how it could be.

> Earlier proposals did say WD in the telecon; there was discussion  
> with pros-and-cons of not being in CR.  The wording the WG made a  
> decision on did not; that might have affected some people's decision.

I do not believe so, from what I recall at the meeting. Indeed let us  
look at the minutes:

<http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/ 
att-0204/05-dawg-minutes.html>

"""AndyS: what message are we trying to give to the community?
... does publishing a WD remove us from CR?
<bijan> I understand from DanC, last week, the WD knocks us out
<AndyS> XPath/Xquery published in CR with fixes.
<SimonR> To remain in CR, I'd suggest Andy is right, it'd take  
another editorial pass.
AndyS: knowing what happens with the status of the document affects  
what I spend my time on with respect to getting the text up to  
publishing quality
SimonR: i think publishing rq24 is the right step forward; if  
published as is (the fastest way forward), it's not CR material and  
we should publish as WD
... if we want to stay in CR, i suggest we need to do some hole  
patching, but most of the hole patching is almost cosmetic.
... i say, go to WD and publish rq24
FredZ: i believe we should go to WD and I think current rq24 is  
better than current CR
ericP: i want to publish as quickly as possibly, but with a BIG RED  
NOTE asking for input into semantics
EliasT: i want to publish, but feel Andy's concerns about being  
careful going back into WD -- I think we need to make decisions  
quickly, and not go back into our pre-CR mode where we re-open lots  
of design decisions, etc.
<SimonR> If we drop back to WD, how long would it take to release a  
subsequent CR? Do we actually long any time that way compared to  
holding off on publishing until rq24 is tidied up?
kendallclark: Going to WD does not open all old decisions -- still  
need burden of proof of new information to open new issues
<AndyS> SimonR - yes, in practice I can't see it not having that effect
EliasT: I agree; I think it's important to psychologically stay in a  
mode where we try to close issues and keep moving forward
<kendallclark> IMO, having 7 open issues on the issues list means  
that the horse is already bolted from the barn -- to use a technical  
phrase :)
bijan: i don't think we can avoid going back to WD (DISTINCT alone  
being underspecificed will require significant changes to document  
that probably can't be published as patch to current CR document)
... as Dan pointed out, we might be able to go straight from WD to PR  
without having another CR
... i prefer to publish a WD sooner, perhaps with a list of issues  
that we're trying to resolve (and appropriate solicitation for help)
<AndyS> I do not agree with Bijan's summary of DISTINCT.
<bijan> Slight rephrasing of what LeeF scribed: I think putting in a  
nailed definition of DISTINCT is sufficient to trigger another LC.  
(There may be no other ramifications.)
kendallclark: my preference is to publish rq24 as is modulo pubrules  
-- in status of the document section I want to point people to  
editorial changes and to point to issues lists, particularly open  
issues, and say that the WG is working to close issues, but we're not  
sure whta changes if any the issues will make in this document
ericP: don't think we have an open issue for whether bnodes have  
different semantics from variable
kendallclark: think I overloaded and reopened bnoderef for that issue
<kendallclark> PROPOSAL: To publish rq24 as a Working Draft,  
including SOTD section written by EricP.
<kendallclark> LeeF, AndyS: no strong opinion
SimonR: Would prefer one more editorial pass
<kendallclark> SimonR: Ideally, after a brief editorial pass, but  
immediately is fine
kendallclark: prefers immediate publication, also happy with  
editorial pass if it took a day or two
FredZ: no opinion
JanneS: no opinion
<EliasT> EliasT: no strong opinion
ericP: no strong opinion other than wanting to put big red text in
<bijan> I prefer immediate, but am willing to defer to the editors,  
if they want to do some minor changes in a small timeframe
<bijan> I'm happy to do that review
<kendallclark> PROPOSAL: To publish rq24 on or shortly after 19  
September, after a sanity-check review by BijanP, and after SOTD  
updates by EricP.

.....

<AndyS> We will need another WD after this one for SPARQL/language.
"""

Clearly the second was a rephrasing of the straw poll and was even  
taken by you as such. There was, as I recall, no discussion of the WD  
vs not point after the straw poll. I would have objected, on process  
grounds, if we had.

http://www.w3.org/2005/10/Process-20051014/tr.html#cfi
"""After gathering implementation experience, the Working Group may  
remove features from the technical report that were identified as  
being "at risk" and request that the Director Call for Review of a  
Proposed Recommendation. If the Working Group makes other substantive  
changes to the technical report, the Director must return it to the  
Working Group for further work."""

Nailing DISTINCT alone is a substantive change.

http://www.w3.org/2005/10/Process-20051014/tr.html#substantive-change

"""A substantive change (whether deletion, inclusion, or other  
modification) is one where someone could reasonably expect that  
making the change would invalidate an individual's review or  
implementation experience. Other changes (e.g., clarifications, bug  
fixes, editorial repairs, and minor error corrections) are minor  
changes."""

I think it's reasonable for me to expect that the change to DISTINCT  
(which is not even complete) invalidates my review, as is evidenced  
by the amount of work and thinking I put into what makes answers  
"equal". I think it's perfectly reasonable to think that a results  
set should be "lean" in the sense of a "lean graph", and there were  
other positions held (at times) by others that conflict with where we  
went on BNode distinctness (e.g., you and pat on source leanness).

If anyone really thought that this wasn't going to be a working  
draft, I'd be very interested for them to speak up.

Cheers,
Bijan.
Received on Thursday, 21 September 2006 16:03:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:27 GMT