W3C

Disposition of Comments on "CC/PP: Structure and Vocabularies" Last Call

This version
http://www.w3.org/2003/07/ccpp-SV-PR/issues-20030915/
Latest version
http://www.w3.org/2003/07/ccpp-SV-PR/issues/
Authors:
Johan Hjelm, CC/PP WG chair
Kazuhiro Kitagawa, CC/PP WG Staff Contact
Mark H. Butler, CC/PP WG chair
Luu Tran, DIWG

This document contains the responses of the CC/PP Working Group to the comments sent to the mailing list http://lists.w3.org/Archives/Public/www-mobile during the Last Call period for the CC/PP:Structure and Vocabularies Working Draft.

The CC/PP WG published 2 documents, CC/PP Implementors Guide: Privacy and Protocols to satisfy issues 57 and 58 and CC/PP Implementors Guide: Harmonization with Existing Vocabularies and Content Transformation Heuristics to satisfy issue 143.

"CC/PP Implementors Guide: Privacy and Protocols" descibes how to protect the privacy of a CC/PP user, and outlines how this can be applied using P3P in HTTP with the CC/PP Exchange protocol.

"CC/PP Implementors Guide: Harmonization with Existing Vocabularies and Content Transformation Heuristics" describes how existing vocabularies for different classes of devices and user agents can be used in CC/PP components, and how to create schemas that encapsulate existing vocabularies. It discusses the results of the coordination with the IETF CONNEG Working Group, as well as the WAP Forum UAPROF Working Group and several other groups.

Please note, we have simply added editorial comments (Classified Editorial) to the document and mainly raised and discussed what seemed to be more substantive issues here.

Open Issues

No. Originator Date Category Action Status

Post Last Call Issues (since 28 July 2003)

No. Originator Date Category Action Status
[240] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix
[241] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix
[242] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix
[243] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix
[244] Francesco Cannistrà 2 Aug 2003 Minor Agreed by Requester Disagree
[245] Francesco Cannistrà 2 Aug 2003 Minor Dissent Overruled Disagree
[246] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix
[247] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix
[248] Francesco Cannistrà 2 Aug 2003 Editorial Agreed by Requester Fix
[249] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix
[250] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix
[251] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix
[252] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix
[253] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix
[254] Francesco Cannistrà 2 Aug 2003 Major Dissent Overruled Disagree

Latest Last Call Issues (since 25 March 2003)

No. Originator Date Category Action Status
[212] Brian McBride (RDF Core) 07 April 2003 Editorial Request Approved Fix
[213] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix
[214] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix
[215] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix
[216] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix
[217] Brian McBride (RDF Core) 07 April 2003 Minor Duplicate Issue Fix
[218] Brian McBride (RDF Core) 07 April 2003 Editorial Request Approved Fix
[219] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix
[220] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix
[221] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix
[222] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix
[223] Masayasu Ishikawa (HTML) 16 April 2003 Editorial Request Approved Fix
[224] Masayasu Ishikawa (HTML) 16 April 2003 Editorial Request Approved Fix
[225] Masayasu Ishikawa (HTML) 16 April 2003 Editorial Request Approved Fix
[226] Masayasu Ishikawa (HTML) 16 April 2003 Editorial Request Approved Fix
[227] Masayasu Ishikawa (HTML) 16 April 2003 Editorial Request Approved Fix
[228] Masayasu Ishikawa (HTML) 16 April 2003 Editorial Request Approved Fix
[229] Masayasu Ishikawa (HTML) 16 April 2003 Editorial Request Approved Fix
[230] Claudia Alvarez Rolins 04 April 2003 Editorial Request Approved Fix
[231] Claudia Alvarez Rolins 04 April 2003 Minor Agreed by Requester Outside charter
[232] Claudia Alvarez Rolins 04 April 2003 Minor Agreed by Requester Disagree
[233] Al Gilman (WAI PF) 16 April 2003 Minor Agreed by Requester Hold to next version
[234] Lynne Rosenthal (QA) 16 Apr 2003 Minor Request Approved Fix
[235] Lynne Rosenthal (QA) 16 Apr 2003 Minor Request Approved Fix
[236] Lynne Rosenthal (QA) 16 Apr 2003 Minor Request Approved Fix
[237] Lynne Rosenthal (QA) 16 Apr 2003 Minor Request Approved Fix
[238] Lynne Rosenthal (QA) 16 Apr 2003 Minor Request Approved Fix
[239] Francesco Cannistrà 5 Jun 2003 Minor Request Approved Fix

All Issues

No. Originator Date Category Action Status Open
[1] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[2] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[3] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[4] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[5] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[6] Aaron Swartz 20 March 2001 Fairly Major Request Approved Fix No
[7] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[8] Aaron Swartz 20 March 2001 Fairly Major Request Approved Fix No
[9] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[10] Aaron Swartz 20 March 2001 Fairly Major Request Approved Fix No
[11] Aaron Swartz 20 March 2001 Minor Request Approved Fix No
[12] Aaron Swartz 20 March 2001 Minor Request Approved Fix No
[13] Aaron Swartz 20 March 2001 Minor Request Approved Fix No
[14] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[15] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[16] Aaron Swartz 20 March 2001 Minor Request Approved Fix No
[17] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[18] Aaron Swartz 20 March 2001 Major Request Approved Fix No
[19] Aaron Swartz 20 March 2001 Minor Agreed by Requester Fix No
[20] Aaron Swartz 20 March 2001 Minor Agreed by Requester Fix No
[21] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[22] Aaron Swartz 20 March 2001 Minor Request Approved Fix No
[23] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[24] Aaron Swartz 20 March 2001 Minor Agreed by Requester Disagree No
[25] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[26] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[27] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[28] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[29] Aaron Swartz 20 March 2001 Minor Request Approved Fix No
[30] Aaron Swartz 20 March 2001 Minor Agreed by Requester Disagree No
[31] Aaron Swartz 20 March 2001 Minor Request Approved Fix No
[32] Aaron Swartz 20 March 2001 Major Request Approved Fix No
[33] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[34] Aaron Swartz 20 March 2001 Minor Request Approved Fix No
[35] Aaron Swartz 20 March 2001 Minor Request Approved Fix No
[36] Aaron Swartz 20 March 2001 Minor Agreed by Requester Fix No
[37] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[38] Aaron Swartz 20 March 2001 Minor Agreed by Requester Disagree No
[39] Aaron Swartz 20 March 2001 Editorial Request Approved Disagree No
[40] Aaron Swartz 20 March 2001 Minor Request Approved Fix No
[41] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[42] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[43] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[44] Aaron Swartz 20 March 2001 Minor Dissent Overruled Disagree No
[45] Aaron Swartz 20 March 2001 Minor Request Approved Fix No
[46] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[47] Aaron Swartz 20 March 2001 Major Agreed by Requester Disagree No
[48] Aaron Swartz 20 March 2001 Editorial Agreed by Requester Disagree No
[49] Aaron Swartz 20 March 2001 Major Request Approved Fix No
[50] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[51] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[52] Aaron Swartz 20 March 2001 Editorial Request Approved Fix No
[53] Art Barstow 20 March 2001 Minor Request Approved Fix No
[54] Art Barstow 20 March 2001 Editorial Agreed by Requester Fix No
[55] Art Barstow 20 March 2001 Major Request Approved Fix No
[56] Art Barstow 20 March 2001 Editorial Request Approved Fix No
[57] Lorrie Cranor 21 March 2001 Editorial Agreed by Requester Fix No
[58] Lorrie Cranor 21 March 2001 Minor Agreed by Requester Fix No
[59] Dan Connolly 22 March 2001 Major Agreed by Requester Disagree No
[60] Dan Connolly 22 March 2001 Major Agreed by Requester Disagree No
[61] Dan Connolly 22 March 2001 Minor Agreed by Requester Disagree No
[62] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[63] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[64] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[65] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[66] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[67] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[68] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[69] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[70] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[71] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[72] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[73] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[74] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[75] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[76] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[77] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[78] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[79] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[80] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[81] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[82] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[83] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[84] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[85] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[86] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[87] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[88] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[89] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[90] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[91] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[92] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[93] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[94] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[95] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[96] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[97] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[98] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[99] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[100] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[101] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[102] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[103] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[104] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[105] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[106] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[107] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[108] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[109] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[110] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[111] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[112] Susan Lesch 25 March 2001 Editorial Request Approved Fix No
[113] Dan Connolly 26 March 2001 Major Request Approved Fix No
[114] Dan Connolly 26 March 2001 Editorial Request Approved Fix No
[115] Tom Worthington 28 March 2001 Minor Request Approved Fix No
[116] Holger Blasum 23 March 2001 Editorial Request Approved Fix No
[117] Holger Blasum 23 March 2001 Minor Request Approved Fix No
[118] Holger Blasum 23 March 2001 Editorial Request Approved Fix No
[119] Holger Blasum 23 March 2001 Editorial Agreed by Requester Disagree No
[120] Holger Blasum 23 March 2001 Editorial Agreed by Requester Disagree No
[121] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[122] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[123] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[124] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[125] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[126] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[127] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[128] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[129] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[130] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[131] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[132] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[133] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[134] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[135] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[136] Dave Beckett 4 April 2001 Minor Agreed by Requester Disagree No
[137] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[138] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[139] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[140] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[141] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[142] Dave Beckett 4 April 2001 Editorial Request Approved Fix No
[143] Larry Masinter 1 March 2001 Major Dissent Overruled Disagree No
[144] Venu Vasudevan 4 April 2001 Minor Request Approved Hold to next version No
[145] Lalitha Surayanarayana 5 March 2001 Editorial Request Approved Fix No
[146] Lalitha Surayanarayana 5 March 2001 Major Request Approved Fix No
[147] Martin Duerst 9 April 2001 Major Agreed by Requester Fix No
[148] Renato Ianelia 19 March 2001 Editorial Request Approved Fix No
[149] Toni Penttinen 5 Jan 2001 Editorial Request Approved Fix No
[150] Toni Penttinen 28 June 2001 Editorial Request Approved Fix No
[151] Mark H. Butler 01 July 2002 Major Dissent Overruled Disagree No
[152] Mark H. Butler 01 July 2002 Fairly Major Request Approved Fix No
[153] Mark H. Butler 01 July 2002 Fairly Major Request Approved Fix No
[154] Mark H. Butler 01 July 2002 Minor Agreed by Requester Disagree No
[155] Mark H. Butler 01 July 2002 Major Dissent Overruled Disagree No
[156] Mark H. Butler 01 July 2002 Fairly Major Agreed by Requester Disagree No
[157] Mark H. Butler 01 July 2002 Fairly Major Agreed by Requester Fix No
[158] Mark H. Butler 01 July 2002 Major Agreed by Requester Fix No
[159] Mark H. Butler 01 July 2002 Minor Agreed by Requester Hold to next version No
[160] Mark H. Butler 01 July 2002 Fairly Major Agreed by Requester Hold to next version No
[161] Mark H. Butler 01 July 2002 Fairly Major Agreed by Requester Supplementary document No
[162] Mark H. Butler 01 July 2002 Fairly Major Agreed by Requester Disagree No
[163] Mark H. Butler 01 July 2002 Fairly Major Duplicate Issue Disagree No
[164] Mark H. Butler 01 July 2002 Fairly Major Agreed by Requester Hold to next version No
[165] Mark H. Butler 01 July 2002 Fairly Major Agreed by Requester Fix No
[166] Mark H. Butler 01 July 2002 Minor Agreed by Requester Disagree No
[167] Mark H. Butler 01 July 2002 Minor Dissent Overruled Outside charter No
[167b] Mark H. Butler 01 July 2002 Fairly Major Dissent Overruled Outside charter No
[168] Mark H. Butler 01 July 2002 Fairly Major Agreed by Requester Outside charter No
[169] Mark H. Butler 01 July 2002 Fairly Major Agreed by Requester Supplementary document No
[170] Mark H. Butler 01 July 2002 Minor Agreed by Requester Disagree No
[171] Mark H. Butler 01 July 2002 Fairly Major Agreed by Requester Disagree No
[172] Mark H. Butler 01 July 2002 Fairly Major Agreed by Requester Disagree No
[173] Mark H. Butler 01 July 2002 Fairly Major Duplicate Issue Hold to next version No
[174] Andreas Schade 30 August 2002 Fairly Major Agreed by Requester Outside charter No
[175] Andreas Schade 01 July 2002 Minor Request Approved Fix No
[176] Andreas Schade 01 July 2002 Fairly Major Dissent Overruled Disagree No
[177] Andreas Schade 01 July 2002 Fairly Major Agreed by Requester Supplementary document No
[178] Mark H. Butler 06 September 2001 Fairly Major Agreed by Requester Outside charter No
[179] Mark H. Butler 06 September 2001 Fairly Major Agreed by Requester Supplementary document No
[180] Mark H. Butler 06 September 2001 Fairly Major Request Approved Fix No
[181] Art Barstow 03 June 2002 Editorial Request Approved Fix No
[182] Andreas Schade 23 July 2002 Fairly Major Request Approved Fix No
[183] Johannes Koch 20 November 2002 Minor Request Approved Fix No
[184] Johannes Koch 20 November 2002 Editorial Agreed by Requester Hold to next version No
[185] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[186] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[187] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[188] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[189] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[190] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[191] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[192] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[193] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[194] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[195] Art Barstow 26 November 2002 Major Dissent Hold to next version No
[196] Art Barstow 26 November 2002 Major Dissent Disagree No
[197] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[198] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[199] Art Barstow 26 November 2002 Major Dissent Hold to next version No
[200] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[201] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[202] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[203] David Ezell (XML Schema) 11 February 2003 Editorial Request Approved Fix No
[204] David Ezell (XML Schema) 11 February 2003 Minor Request Approved Fix No
[205] David Ezell (XML Schema) 11 February 2003 Minor Request Approved Fix No
[206] David Ezell (XML Schema) 11 February 2003 Minor Request Approved Fix No
[207] David Ezell (XML Schema) 11 February 2003 Minor Request Approved Fix No
[208] David Ezell (XML Schema) 11 February 2003 Minor Request Approved Fix No
[209] David Ezell (XML Schema) 11 February 2003 Editorial Request Approved Fix No
[210] David Ezell (XML Schema) 11 February 2003 Editorial Request Approved Fix No
[211] Philipp Hoschka 29 March 2003 Editorial Request Approved Fix No
[212] Brian McBride (RDF Core) 07 April 2003 Editorial Request Approved Fix No
[213] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix No
[214] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix No
[215] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix No
[216] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix No
[217] Brian McBride (RDF Core) 07 April 2003 Minor Duplicate Issue Fix No
[218] Brian McBride (RDF Core) 07 April 2003 Editorial Request Approved Fix No
[219] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix No
[220] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix No
[221] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix No
[222] Brian McBride (RDF Core) 07 April 2003 Minor Request Approved Fix No
[223] Masayasu Ishikawa (HTML) 16 April 2003 Editorial Request Approved Fix No
[224] Masayasu Ishikawa (HTML) 16 April 2003 Editorial Request Approved Fix No
[225] Masayasu Ishikawa (HTML) 16 April 2003 Editorial Request Approved Fix No
[226] Masayasu Ishikawa (HTML) 16 April 2003 Editorial Request Approved Fix No
[227] Masayasu Ishikawa (HTML) 16 April 2003 Editorial Request Approved Fix No
[228] Masayasu Ishikawa (HTML) 16 April 2003 Editorial Request Approved Fix No
[229] Masayasu Ishikawa (HTML) 16 April 2003 Editorial Request Approved Fix No
[230] Claudia Alvarez Rolins 04 April 2003 Editorial Request Approved Fix No
[231] Claudia Alvarez Rolins 04 April 2003 Minor Agreed by Requester Outside charter No
[232] Claudia Alvarez Rolins 04 April 2003 Minor Agreed by Requester Disagree No
[233] Al Gilman (WAI PF) 16 April 2003 Minor Agreed by Requester Hold to next version No
[234] Lynne Rosenthal (QA) 16 Apr 2003 Minor Request Approved Fix No
[235] Lynne Rosenthal (QA) 16 Apr 2003 Minor Request Approved Fix No
[236] Lynne Rosenthal (QA) 16 Apr 2003 Minor Request Approved Fix No
[237] Lynne Rosenthal (QA) 16 Apr 2003 Minor Request Approved Fix No
[238] Lynne Rosenthal (QA) 16 Apr 2003 Minor Request Approved Fix No
[239] Francesco Cannistrà 5 Jun 2003 Minor Request Approved Fix No
[240] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix No
[241] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix No
[242] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix No
[243] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix No
[244] Francesco Cannistrà 2 Aug 2003 Minor Agreed by Requester Disagree No
[245] Francesco Cannistrà 2 Aug 2003 Minor Dissent Overruled Disagree No
[246] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix No
[247] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix No
[248] Francesco Cannistrà 2 Aug 2003 Editorial Agreed by Requester Fix No
[249] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix No
[250] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix No
[251] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix No
[252] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix No
[253] Francesco Cannistrà 2 Aug 2003 Editorial Request Approved Fix No
[254] Francesco Cannistrà 2 Aug 2003 Major Dissent Overruled Disagree No

Comments have been classified into several categories:

Comments have been classified into several actions:

The current status of the issues is as follows:

The following issues are currently open:

Comments have been submitted by different people:

Aaron Swartz http://lists.w3.org/Archives/Public/www-mobile/2001Mar/0001.html

Editorial and other corrections 20 March 2001
Issue 1:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
>Other xml document types

I believe XML should be capitalized here.
Action Class: Fix
WG Action:
No details
Issue 2:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> this document is created from merge of

I believe you mean "this document is created from the merge of" (notice the
added "the").
Action Class: Fix
WG Action:
No details
Issue 3:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> HTML <alt> tags
There is no HTML <alt> tag (that I know of). I believe you mean the alt
attribute.
Action Class: Fix
WG Action:
No details
Issue 4:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> any new attribute vocabularies defined MUST conform to the RDF schema
in appendices B and C.
I don't believe RDF schema supplies any definition of conformance, so you will
have to explain what you mean by conformance here. How do make a vocabulary
that conforms to your schema?
Action Class: Fix
WG Action:
Fix: add link to definition
Issue 5:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> Section 2 provides [...]

It would be nice if these section references were links.
Action Class: Fix
WG Action:
No details
Issue 6:
Title: Editorial and other corrections
Class: Fairly Major
Status: Request Approved
Subject:
> The term "CC/PP attribute" [...]

It may be a little too late to change this, but the term attribute conflicts
with the XML syntactical element of the same name. FWIW, Dublin Core and SWAG 
use the term "term" to refer to properties and classes, etc. Since attributes 
appear to be just RDF properties, you may just want to call them properties 
also.
Action Class: Fix
WG Action:
use the phrase "CC/PP attributes" rather than just "attributes"
Comment: This issue was Request not approved / no response from requester. I have changed the status because I believe the document has been changed to address Aaron's concerns
Issue 7:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> another RDF resource names 'Object-resource'.

I believe you mean "named" not "names".
Action Class: Fix
WG Action:
No details
Issue 8:
Title: Editorial and other corrections
Class: Fairly Major
Status: Request Approved
Subject:
You also use rdf:about attributes with relative URIs that reference other
documents. (like rdf:about="xxx") I believe this is a clear mistake. These
should be replaced with either rdf:id or rdf:about="#xxx"
Action Class: Fix
WG Action:
The examples check out in SiRPAC. Use entity reference 
syntax (&xxx;) to indicate that the names are placeholders
Comment: This issue was marked Request not approved / no response from requester. I have changed the status because I believe the document has been changed to address Aaron's concerns
Issue 9:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
In Figure 2-1b, you omit the rdf: prefix on the about attribute of the third
ccpp:component.
Action Class: Fix
WG Action:
No details
Issue 10:
Title: Editorial and other corrections
Class: Fairly Major
Status: Request Approved
Subject:
In Figure 2-2b (and other examples), you show an rdf:type property with a value
of "BrowserUA" (and other similar values). This seems like a mistake, since such
a value would mean that the type of the property would change every time the 
document was parsed by an RDF parser. Surely this is not what you want. It
seems like it would be more effective if you used the typedElt syntax, like:

<ccpp:component>
        <BrowserUA
                rdf:about="#xxx">
                <!-- ... -->
        </BrowserUA>
</ccpp:component>

Of course, you provide no default namespace, so all of your unprefixed
attributes have no way to live. I'm not quite sure what happens when you don't
provide this default namespace, but I do not it's not a good idea.
Action Class: Fix
WG Action:
The examples check out in SiRPAC & Use entity reference syntax (&xxx;) to indicate that 

the names are placeholders

Mark Butler:
> Aaron's concerns have been partly addressed, but the typeElt syntax 
> he suggest has not been adopted.

Aaron:
> 10: Despite what the issues list says you did take my advice and fix 
> this in the new version. Resolved.
Issue 11:
Title: Editorial and other corrections
Class: Minor
Status: Request Approved
Subject:
For section 2.1.3 you again use unprefixed references and do not explain how a
client would find these defaults and connect them to the references in the 
profile. ... Oh, wait. You explain this later. Perhaps this explanation should
come sooner.
Action Class: Fix
WG Action:
Add the following sentence: Default values for a component 
of a CC/PP profile are indicated by a ccpp:default arc from the component concerned 
to a component that describes the default values.
Issue 12:
Title: Editorial and other corrections
Class: Minor
Status: Request Approved
Subject:
In section 2.1.4, you describe how proxies can provide their own profiles, but do
not explain how this should be integrated with the client profile. Furthermore,
the example shows the proxy passing along its own OS (Linux) and other
information that seems irrelevant to the server. Is this a mistake or is more
explanation needed to make this use case clearer?
Action Class: Fix
WG Action:
Offer better example
Issue 13:
Title: Editorial and other corrections
Class: Minor
Status: Request Approved
Subject:
> refer to the RDF Schema specification [4].

It seems that some references are linked, but some (like to [4] in section 2.3.1
as quoted above) are not. Is this a normative/non-normative reference
distinction? If so, it should be clearer.
Action Class: Fix
WG Action:
Fix consistency
Issue 14:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> see Section 6.2.1.

In the same section, this reference is also unlinked.
Action Class: Fix
WG Action:
No details
Issue 15:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
Figure 2-12 is a broken image (404).
Action Class: Fix
WG Action:
No details
Issue 16:
Title: Editorial and other corrections
Class: Minor
Status: Request Approved
Subject:
>> RDF Model and Syntax specification [3] defines two ways to name RDF resources, 
>namely "id" and "about". RDF resources named by "about" are fully identified, 
>whereas those named by "id" can not be referenced from outside the containing 
> document, unless some additional information is available that allows the full 
> (absolute) base URI to be determined. The RDF specification is not currently 
> clear about how a base URI should be determine [34]. 

Actually, I think you misunderstood Ralph's letter. RDF clearly defines how
to determine the absolute URI, and how a base URI should be determined is
clear. The problem is that there is no mapping from a fragment identifier
to the id attribute in RDF. However, most people assume this mapping, 
although it is not officially specified. Especially since the spec refers to
the value of id attributes using fragment identifiers itself! So, while you 
may continue to require that the about attribute is used, please correct your
statements about the RDF spec.
Action Class: Fix
WG Action:
Fix: Ralph or others about RDF fragment naming makes sense
Discussion URLS:
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0070.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0071.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0073.html
Issue 17:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> the namespace identifier <http://www.w3.org/2000/07/04-ccpp-proxy#>.


You don't really need to wrap that in angle brackets if it's surrounded by tags.
It'll probably just confuse people.
Action Class: Fix
WG Action:
No details
Issue 18:
Title: Editorial and other corrections
Class: Major
Status: Request Approved
Subject:
With the proxy chaining described in 3.2.1, how would an implementation 
find the outmost layer in the chain? How should implementations deal with 
nextProxy cycles, dead-ends etc. Perhaps you could provide an algorithm to 
make this easier.
Action Class: Fix
WG Action:
Add "A valid CC/PP profile MUST NOT contain any loop in 
the request chain, and the request
 chain MUST terminate in a client profile. " Handling invalid 
profiles depends on the implementation. CC/PP does not
 specify whether they are rejected or 
ignored.
Issue 19:
Title: Editorial and other corrections
Class: Minor
Status: Agreed by Requester
Subject:
Also, why do you make a separation between request profiles and proxy profiles? 
It seems this just adds unnecessary bulk. It would make more sense just to have
chains of proxyProfiles pointing down towards the client.
Action Class: Fix
WG Action:
Add the extra structure to satisfied with Issue 18 requirement.

Mark Butler: 
> As far as I can see, this issue is unresolved as the specification still 
> distinguishes between request profiles and proxy profiles. This is the 
> same as issue 157.

Aaron:
> 19: Not essential. Can live with.
Issue 20:
Title: Editorial and other corrections
Class: Minor
Status: Agreed by Requester
Subject:
In Figure 3-13b:
> <rdf:li>text/xml</rdf:li>

I remember some discussion about this, so maybe it's been decided, but why 
don't you just use the content-type URIs and stick them in the schemas section.
It seems much simpler. The official URIs are:

ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/

as defined in ftp://ftp.isi.edu/in-notes/rfc2048.txt
(I keep track of this at: http://logicerror.com/contentType)
Action Class: Fix
WG Action:
Clarify this issue would only add confusions. It is quite normal and usual to refer to

MIME types by defined textual syntax.
Philipp:
>this is ok - the issue of what URI to use for identifying MIME types is still 
being debated/
Aaron:
> 20: Can live with.
Issue 21:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> <rdf:li>http://example.org/example/XHTML-1.0>
Are you sure you don't mean:
<rdf:li rdf:resource="http://example.org/example/XHTML-1.0" />

These mean two totally different things. One is a string of characters, the other
is a URI. I'm pretty sure you mean to use a URI here.
Action Class: Fix
WG Action:
change URI strings to URIs
Issue 22:
Title: Editorial and other corrections
Class: Minor
Status: Request Approved
Subject:
With an example, like:
> +--type---------> { "text/xml", "application/xml"}
> +--type---------> { "text/html", "application/html"}
> +--schema-------> { "http://example.org/example/XHTML-1.0" }
> +--uaprof:HTMLVersion--> { "3.2", "4.0" }

I'm not clear about the semantics of a container here.
- Why are there two separate lists of types?
- Are these terms anded or ored together (i.e. text/xml [and|or] HTML 3.2)?
Does the support of application/xml mean it can read any XML? How is it to be
interpreted?
Action Class: Fix
WG Action:
Add a paragraph in 3.2.2 to explain in the case of if a component has any properties

that are applied to more than one type.
Issue 23:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
In 4.1.1.1:
> A URI is represented as a text string, but is subject to
comparison rules set
> out in RFC 2396 [28], which may require 'absolutisation' of the URI as
> described there.

You should be careful there, RDF recognizes URIs as something special, not
just strings.
Action Class: Fix
WG Action:
Change URI strings URIs
Issue 24:
Title: Editorial and other corrections
Class: Minor
Status: Agreed by Requester
Subject:
WRT 4.1.1: How come there's no decimal? It'd be really nice to say HTMLVersion
> 2.1 or some such.
Action Class: Disagree
WG Action:
Versions are not always decimals. If versions were numbers and could use arithmetic

relations (<, >, etc.)
Philipp:
> Introducing decimals sounds like good idea, but ok not to do it
Mark Butler: 
> CC/PP can cope with decimals via the 
> rational data type, but version numbers have their own 
> complexities and should be a different data type. For 
> example UAProf uses literals for version numbers.
Aaron: 
> 24: Makes sense. Resolved.
Issue 25:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
In A.1 the term Anonymization isn't bolded like the rest.
Action Class: Fix
WG Action:
No details
Issue 26:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> Some communication process that provides definite and tamper-proof > information
about the identity of a communicating party. Why is there a line break there?
Action Class: Fix
WG Action:
No details
Issue 27:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> This term has been the subject of much dispute. Broadly speaking, it is
> a process that prevents a party to a communication from subsequently denying
> that the communication took place, or from denying more line breaks...
Action Class: Fix
WG Action:
No details
Issue 28:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> rdfs:Literal

> ccpp:URI {A URI value of a CC/PP attribute}
A URI is not a literal, but a resource
Action Class: Fix
WG Action:
No details
Issue 29:
Title: Editorial and other corrections
Class: Minor
Status: Request Approved
Subject:
> accessed, the parties with
> whom communication occurs, etc. yet another!
Action Class: Fix
WG Action:
Change URI string to URIs
Issue 30:
Title: Editorial and other corrections
Class: Minor
Status: Agreed by Requester
Subject:
With Figure B-3, the RDF spec recommends not using entities as you do for your namespaces

since they might be removed in a future version of XML.
Action Class: Disagree
WG Action:
Entity references stay.
Philipp:
> not sure why this is hard to satisfy, but ok
Mark Butler: 
> Actually I like entities as they mean you do not have to repeat
> the same namespace everywhere. Some UAProf schemas have the 
> problem that they use different namespaces to refer to the same
> thing (e.g. RDF Schema) so using entities is a good way of 
> avoiding this error. If the RDF spec is going to outlaw entities, 
> they need to provide a replacement. It's basic good practice in 
> computer science to provide short-hand ways of expressing such
> things in case entry by hand in necessary.
Aaron:
> 30: Can live with.
Issue 31:
Title: Editorial and other corrections
Class: Minor
Status: Request Approved
Subject:
Also, why do you declare your own ccpp:Resource? It doesn't seem you get any
benefit from that, but simply pollute the namespaces.
Action Class: Fix
WG Action:
CC/PP for resource and other types can be embedded in other 
documents. It isolates the CC/PP
 from other things. The only change is a statement 
of this as a rational. Add a statement to this idea effect.

Aaron Swartz: 
> Dissent. You have a very confusing practice of defining the entities 
> and then essentially not using them, and in fact mixing them with full 
> URIs. This makes no sense.

Franklin Reynolds:
> I checked the arch schema documents and ccpp:Resource is 
> not actually used in anyway I can understand. I don't see how 
> it can hurt anything, but I don't understand how it helps us 
> either.

Mark Butler:
>To paraphrase:
>It hurts because rdf defines a resource class. So Aaron's argument is why
>define something new when you can just use the rdf class. The contrary
>argument (from Graham) is that we need to refer to resources in the schema,
>and as RDF seems to change all the time it's a good idea to have some
>insulation from RDF. 

Mark:
>Hi all,
>
>If I remember correctly, one of the outcomes of the move-to-CR conference
>call was to resolve Issue 31 from Aaron about whether we need ccpp:Resource.
>I think this issue should be fairly easy to resolve so I think we should
>close it.
>
>Graham, is it okay if I update the WD and the schemas accordingly?

Graham:
Yes, we agreed that ccpp:Resource, though "mostly harmless", was not needed 
and could be removed.
Issue 32:
Title: Editorial and other corrections
Class: Major
Status: Request Approved
Subject:
Also, you may not want to use rdf:id in these schemas, unless you specify the base
URI since you'll effectively be defining all these terms with the namespace of the
specification itself!
Action Class: Fix
WG Action:
Remove an xml base URI within the schema document.
Issue 33:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> A proxy profile has an arbitrary number of ccpp:proxy-behavior
> properties, each of which indicates an individual
> ccpp:Proxy-behavior value.
Actually, there is no proxy-behavior property. I believe you mean proxyBehavior.
BTW, why the inconsistent naming of that one property? -- you're right to be
confused.
Action Class: Fix
WG Action:
No details
Discussion URLS:
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0070.html
Issue 34:
Title: Editorial and other corrections
Class: Minor
Status: Request Approved
Subject:
> When this type is
> used, the value of the CC/PP attribute is the URI
rather than the 

> resource identified by the URI. I'm a little confused -- when would you ever
use this? I can't expect that you'll need to talk about URIs.
Action Class: Fix
WG Action:
Change URI string URIs
Issue 35:
Title: Editorial and other corrections
Class: Minor
Status: Request Approved
Subject:
> This class is used to represent any CC/PP attribute value that
> is arbitrary text. How is this different from literals?
Action Class: Fix
WG Action:
literals is atomic string values.
Comment: [Status: Request not Approved/No response from Requester]
Issue 36:
Title: Editorial and other corrections
Class: Minor
Status: Agreed by Requester
Subject:
You may also want to declare that the Defaults property is deprecated, or
some such.
Action Class: Fix
WG Action:
Default property may appear in a separate document specified by absolute path.
Philipp:
> question seems to be misunderstanding of defaults property ?
Aaron:
> 36: Don't remember what I meant. Can live with.
Issue 37:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> This is one of three properties to describe a proxy behavior.
This is unnecessary, and sort of limits extensibility. You can keep it in the
text, but you don't need it in the schema.
Action Class: Fix
WG Action:
Remove this sentence.
Aaron: 
> 37: Hm, you said you removed the sentence but you did not. I wonder how 
> many other issues you did not follow through on. Please fix.
Mark Butler:
> Yes one instance remained. I've now fixed it.
Issue 38:
Title: Editorial and other corrections
Class: Minor
Status: Agreed by Requester
Subject:
> If this property is present, the behavior associated with the corresponding
ccpp:Proxy-behavior resource is applied only if the outbound request profile
indicates capabilities that match all those of the Component that is the object
of this property.
This is a bit confusing. Isn't a request profile inbound, not outbound? Second,
if this is true, why even bother to specify applicability. The proxy should just
look at the profile and provide the information that's appropriate. I
think you really mean something different (i.e. that for this type of data, this
is what's done) and this should be specified.
Action Class: Disagree
WG Action:
Clarify
Philipp:
> text has changed
Aaron:
> 38: Don't remember what I meant. Can live with.
Issue 39:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> URIs and optional fragment identifiers

According to the URI spec, a "URI reference" includes a fragment identifier, so
I don't think you need to be so explicit about this.
Action Class: Disagree
WG Action:
No action
Issue 40:
Title: Editorial and other corrections
Class: Minor
Status: Request Approved
Subject:
> All properties used as CC/PP attributes must be instances of the class
ccpp:Attribute, which itself is a subclass of rdf:Property.

How should this be defined? Should the subclass declaration be included in
every CC/PP request? Should it be at the namespace? Should it be mailed in
to the W3C? Please elaborate. I wouldn't complain, but this is a MUST
requirement, which it seems is effectively useless. ("Yeah, it's a subclass."
"Where is that defined?" "Well, I wrote it down on this stickie note, you 
see!") Also note that some clarifications of this could prevent the use of
terminology created for another purpose (and thus, wasn't specified as a
subClassOf ccpp:Attribute) which would be a bad thing.
Action Class: Fix
WG Action:
>Editorial Clarifications
Issue 41:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> NOTE: the proxy vocabulary described later [...]

Actually, I believe it was defined "above".
Action Class: Fix
WG Action:
No details
Issue 42:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
>[...] of attribute names in a profile.NOTE: if there a [...]

You're missing a paragraph break and a cAPItal at the beginning of the
second sentence.
Action Class: Fix
WG Action:
No details
Issue 43:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> We recommend [interCap style] be used for CC/PP attribute names

Then how come all your attributes are hyphenated?
Action Class: Fix
WG Action:
Fix (allow hyphenating attributes)
Issue 44:
Title: Editorial and other corrections
Class: Minor
Status: Dissent Overruled
Subject:
> An attribute defined very broadly might be subject to different privacy
or security concerns when applied in different circumstances. For example,
having a text-to-voice capability on a mobile phone type of device might be a
generally useful feature, but a similar feature in a PC might be indicative of
a personal disability.


This doesn't make sense. It seems if anything, a specific attribute would be
more of a privacy concern. supportsScreenReader is a disability giveaway, where
as the broader textToSpeech is less revealing. Having well-defined attributes is
good practice, but the reasons provided should be sound
Action Class: Disagree
WG Action:
Editorial Clarification

(M is me, G Graham Klyne, F Franklin Reynolds, K Kaz Kitagawa)
M: Issue 44. Current draft seems identical to original document, has 
change been made?
G: Haven't seen relationship between two parts: general principle how to 
define attributes that are closely define; need to point out there are 
issues when privacy is a concern.
F: I think Aaron is wrong here, he has read the text incorrectly. It is 
true that combinations of properties may be used to infer something. 
Example is sound.
M: Add something so that 2nd para is not seen as a consequence of 1st 
para. Kaz?
K: Disagree with requestor.
M: Move to 'held'.

Aaron:
> 44: This could be fixed by removing the words "defined very broadly". 
> Please fix.

Mark Butler:
>Actually this point caused some controversy as detailed in the minutes 
>of one of the telecons:
>http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0070.html
Aaron:
>Yes, reading these minutes I thought I'd go with G and F's comments and 
>split it into two things. One is about defining specific terms, the 
>other is about privacy issues.
Mark: 
> In summary the WG disagreed with you, with the exception of myself. So I
> suggest we mark it as dissent. Would you like to add any further 
> comments to this issue?
Aaron:
> From my reading it looks like only Kaz disagrees.
Mark:
> For the record, I agree with Aaron. 

Franklin Reynolds:
> I am not convinced I understand the issue or the comments. 

Mark Butler:
>To paraphrase:
>The WD seems to say "you ought to adopt different vocabularies for 
>different types of devices otherwise people may be able to infer 
>whether you are disabled". Aaron replies that "that's not the most 
>important issue. We need to pick property names that are sufficiently 
>specific to describe our property, but yet sufficiently generic to 
>make it hard to discriminate". Whether you agree with Aaron or the
>WD partly depends on how paranoid you are.
>Personally I think promoting the idea we should different vocabularies 
>just because people are paranoid is a bad idea. Because at the end of 
>the day, if people are going to discriminate, there's very little we 
>can do about it. I'm afraid I don't believe we can stop discrimination
>with a protocol or by adopting a particular coding scheme.

Philip Hoschka (from CR Telecon) resolution: minor, leave as is
Discussion URLS:
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0070.html
Issue 45:
Title: Editorial and other corrections
Class: Minor
Status: Request Approved
Subject:
In Appendix E, you mention a large number of formats without providing URIs,
or really any information applicable to CC/PP. Why? If there's no good reason,
this section should be removed. Even so, you may want to say it's non-normative.
Action Class: Fix
WG Action:
No details
Issue 46:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
Also, why don't talk about CCPP in HTTP, or at least point to the note?
Action Class: Fix
WG Action:
Add reference to the mailing list to show that is ongoing work, instead of the Note.
Issue 47:
Title: Editorial and other corrections
Class: Major
Status: Agreed by Requester
Subject:
The use of a special textual syntax to make the RDF graph more clear,
but it might be better to use an established format like Notation3
(which has software to convert it to RDF XML) rather then
inventing yet another syntax. It may also be smart to eliminate the
textual version in some examples, and just go with RDF document
fragments (not full documents). 
http://www.w3.org/DesignIssues/Notation3

For example, using N3, this:

[Profile]
+--ccpp:component-->[TerminalHardware]
+--ccpp:component-->[TerminalSoftware]
+--ccpp:component-->[TerminalBrowser]

becomes:

:Profile
ccpp:component :TerminalHardware ;
ccpp:component :TerminalHardware .

or, optionally:

:Profile
>- ccpp:component -> :TerminalHardware ;
>- ccpp:component -> :TerminalHardware .

The use of examples is nice, but there is no need to illustrate every point with
both a textual and XML representation. It quickly gets repetitive. I suggest
that you explain as clearly as you can in prose and possibly refer to an
appendix with more complicated examples that demonstrate many features.
Action Class: Disagree
WG Action:
Using N3 is bad idea. Nobody except a few RDF aficionados 
knows anything about N3. No action and continue to use the current system.
Philipp:
> suggests major editorial change (e.g. use N3) - could help, but probably ok 
> not to go into this
Aaron: 
> 47: I think the response is rude and incorrect but: Can live with.
Mark:
> I'm sorry you think the response is rude. I thought the issue you 
> raised was interesting although I do think the use of RDF is a 
> considerable barrier to the adoption of CC/PP. One of the things 
> causing this barrier is the XML serialisation of RDF.
Aaron:
> Yes, it is quite unfortunate IMO, which is why I'm trying to 
> encourage the use of N3 and the new WG-specified N-Triples. Sadly 
> though, there are many WG and W3C members who won't budge on this 
> issue and insist we must use RDF/XML.
Mark: 
> However standardising the XML serialisation of RDF has been painful so
> people working on it are not receptive to these comments. Furthermore I 
> do have sympathy for people who are frustrated with RDF or the RDF 
> community, which may have led to the use of the term "RDF aficionados": 
> I try to explain my own frustration here
> http://lists.w3.org/Archives/Public/www-mobile/2002Jun/0034.html
> although if you thought the WG response was rude, you'll probably find 
> this really inflammatory so apologies in advance.
Aaron:
>No, not at all. I think this is again because of the poor perception 
>that's been sent out by RDF/XML and the other positioning of RDF. I 
>believe that by itself RDF is actually very simple, very standard 
>(people have been using graphs and tuples and URIs for years, RDF just 
>puts them together) and very useful but with the XML guys pushing for an 
>unusable syntax and the AI guys pushing all this hype, I'm beginning to 
>wonder if the RDF "image problem" is unrepairable.
>However, I appreciate CC/PP's bravery in this area and I hope it is 
>rewarded.
Issue 48:
Title: Editorial and other corrections
Class: Editorial
Status: Agreed by Requester
Subject:
Furthermore, the seemingly arbitrary separation of "architecture" and "structure"
makes the spec confusing and hard to follow, as well as very repetitive. Actually,
it might be best to rethink the whole structure of the document. You should probably
start with some simple RDF explanations, then demonstrate extensibility,
and _then_ demonstrate the specific feature of CC/PP. I feel this would
significantly simplify and shorten the document while making it more
understandable.
Action Class: Disagree
WG Action:
This is a question of style. No actions and no changes. We may 
revise it this in the future to create a CC/PP for dummies.
Aaron:
> 48: Simplifying the spec does not imply that the reader is a 
> dummy but: Can live with.
Issue 49:
Title: Editorial and other corrections
Class: Major
Status: Request Approved
Subject:
You will of course want to stick copies of your schema in your namespaces.
Action Class: Fix
WG Action:
Putting schemas and examples in separate files and added pointers to them.
Publication issue
Discussion URLS:
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0070.html
Issue 50:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
> World Wide Web Consortium Recommendation: http://www.w3.org/TR/PR-rdf-schema
I believe the correct URI is: http://www.w3.org/TR/rdf-schema/
Action Class: Fix
WG Action:
No details
Issue 51:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
Also, in terms of URI tidiness, you may want to have:
http://www.w3.org/TR/CCPP-vocab/
http://www.w3.org/TR/CCPP-struct/
redirect (instead of just providing) to the new draft. That way people won't
continue to give out bad URIs.
Action Class: Fix
WG Action:
Fix: publication issue
Discussion URLS:
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0070.html
Issue 52:
Title: Editorial and other corrections
Class: Editorial
Status: Request Approved
Subject:
Phew, all done. Does this mean I get to go in the acknowledgments section? ;-)
Action Class: Fix
WG Action:
Thank him 52 times.

Art Barstow http://lists.w3.org/Archives/Public/www-mobile/2001Mar/0002.html

Check examples with RDF parser and editorial change 20 March 2001
Issue 53:
Title: Check examples with RDF parser and editorial change
Class: Minor
Status: Request Approved
Subject:
1. This document contains over 20 pieces of RDF with the following label at the
top:
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->

You should be aware that the W3C's SiRPAC has many defects documented at:
http://www.w3.org/RDF/Implementations/SiRPAC/SiRPAC-defects.html
There are several other RDF parsers documented at:
http://www.w3.org/RDF/
Action Class: Fix
WG Action:
Done our party by SiRPAC. Other people are welcome to 
run it throught other processors and share the result.

Mark Butler: I have checked all RDF in document using ARP validator.
Issue 54:
Title: Check examples with RDF parser and editorial change
Class: Editorial
Status: Agreed by Requester
Subject:
2. The document contains several references to:
http://www.wapforum.org/UAPROF/ccppschema-20000405#
I get a