W3C

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

Author: Johan Hjelm, CC/PP WG chair

Revised: Kazuhiro Kitagawa, CC/PP WG Staff Contact

Revised: Mark H. Butler, CC/PP WG chair

Revised: Luu Tran, DIWG CC/PP subgroup lead

Date: 20 March 2003

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.


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 Dissent Overruled Disagree 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 Agreed by Requester 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 Outside Charter 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 Duplicate Issue No
[174] Andreas Schade 30 August 2002 Fairly Major Outside Charter 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 Outside Charter 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 Publication Issue Publication Issue Yes
[185] Art Barstow 26 November 2002 Editorial Request Approved Fix No
[186] Art Barstow 26 November 2002 Editorial Dissent Disagree 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 Dissent Disagree 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 Dissent Disagree No
[194] Art Barstow 26 November 2002 Editorial Dissent Disagree 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

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 404 error when I try to access that doc.
Action Class:Fix
WG Action:
Send liaison to WAP Forum UAPROF group with request to Fix
Art Barstow: 
>WRT issue #54:
>
> [1] http://www.w3.org/2002/03/CCPP-disposition.html#no54
>
>the NOTEs in 2.2 address the fact that:
>
> [2] http://www.wapforum.org/UAPROF/ccppschema-20000405#
>
>does not exist and that one should see the following instead:
>
> [3] http://www.wapforum.org/profiles/UAPROF/ccppschema-20000405

>However, to someone new to RDF[S], this factoid just gets lost as it's 
>likely to seem esoteric.  Why not just change all occurrences of [2] to 
>[3]?

Mark Butler:

> Unfortunately the UAProf spec says UAProf profiles have to 
> use 2, not 3, to be UAProf compliant. See the table just above 
> section 8.2.2 page 28 in WAP-248-UAPROF-20010530-p, Proposed 
> Version 30 May 2001 available from 
> http://www1.wapforum.org/tech/terms.asp?doc=WAP-248-UAProf-20011020-a.pdf

> This matter has been raised with the WAP Forum a number of times 
> by a number of different people (including yourself if I remember 
> correctly!). However they have not addressed it. I am currently talking 
> to Alistair Angwin, chair of the WAP-WAG Group who now have responsibility 
> for UAProf, to determine how this and other related issues with UAProf 
> can be addressed. However I think it is wrong to further delay CC/PP due 
> to this issue. 

Art Barstow:

> Hi Mark - wrt issue #54, frankly, I don't understand the WG's
> reluctance to change the URI.  However, I don't think this should
> block the spec so consider the related text in:
>
> http://www.w3.org/Mobile/CCPP/Group/Drafts/WD-CCPP-struct-voca
> b-20020716/#ExtensibilityNamespaces
> 
> acceptable.

Mark Butler:

> Actually, I've just checked this again and I am wrong. The latest
> version of the UAProf spec (which I referred to our last 
> discussion, so I have made a mistake here) does give the 
> correct URI. I must have been referring to an old version of the 
> spec, and I apologise for this error. Therefore it is possible
> to correct in the CC/PP draft also.

> I'll update the CC/PP WD and mark up the issue as being
> addressed. 

Mark Butler:

> Hi Art, I might have spoken too soon. 
> The UAProf spec says profiles should use
> [1] http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#
> but there is no document at that address.
> (As I'm sure you know, there is a schema at
> [2] http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#)
> So I'm happy to change the URL in the CC/PP WD to [1], but that
> doesn't solve the problem you originally raised that there
> is no schema there. We need the WAP Forum to put a schema at [1]. 
> Like you, ideally I'd like to see this problem solved.  
> Can you think of any quick solution?

Art Barstow:

> Mark - how about changing the following note in 2.2 from:
> [[
> NOTE: namespace URIs do not have to correspond to schema URLs. 
> For example although UAProf uses the namespace 
> "http://www.wapforum.org/UAPROF/ccppschema-20000405#" 
> the schema for that namespace is actually located at
> "http://www.wapforum.org/profiles/UAPROF/ccppschema-20000405".
> ...
> ]]
> to:
> [[
> NOTE: although namespace names are identified by URI references, 
> there is no requirement that a schema be available at that URI. 
> In the above example, the "uaprof" namespace name is
> "http://www.wapforum.org/UAPROF/ccppschema-20000405#"
> yet there is no schema at that URI.
> ...
> ]]
> Regardless, the W3C should not block its specs because the WAPF/OMA 
> site has outstanding issues.  Kevin's new CR will result in sync'ing
> the spec with a real URI so we're getting some improvements ...
> Anyhow, there's no need to be-labor this issue - either leave the
> text as in the 2002-07-16 draft or consider my changes above.  Either
> of these will be acceptable to close #54.
Discussion URLS:
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0070.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0072.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0074.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0076.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0081.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0082.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0083.html
Comment: [Status: Request Approved] @@ PH: URL still broken at WAP forum - did you get any response ?
Issue 55:
Title: Check examples with RDF parser and editorial change
Class: Major
Status:Request Approved
Subject:
3. Why isn't there an RDF schema at:
http://www.w3.org/2000/07/04-ccpp#
Action Class:Fix
WG Action:
Add links to those documents.
Discussion URLS:
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0070.html
Issue 56:
Title: Check examples with RDF parser and editorial change
Class: Editorial
Status:Request Approved
Subject:
4. The image "constraints.png" seems to be missing.
Action Class:Fix
WG Action:
No details
Issue 181:
Title: Use of references in WD
Class: Editorial
Status:Request Approved
Subject:
I think using [nnnn] instead of [AAAA] to refer to the References 
(e.g. [3] vs. [RDF]) is anti-social.  Please fix this (and follow
the W3C pub style) before the next public release.  It would also be good 
to state whether the References are normative or informative.
Action Class:Fix
WG Action:
Graham Klyne: Use of references in WD.  That's a new one on me.  (
Especially the pubrules bit.)

Mark Butler: I think Art is right - see 
http://www.w3.org/2001/06/manual/#References
I propose we update WD accordingly. 
Issue 185:
Title: Use of the term profile is confusing
Class: Editorial
Status:Request Approved
Subject:
1 - first par, first sentence - a frequent point of confusion
 is that "profile" is frequently used to denote a subset of a
 specification (i.e. CSS Mobile "Profile").  The spec should
 explicitly state that "profile", in the context of this document,
 is not the same as the more common usage of the word.
Action Class:Fix
WG Action:
Mark: Add 
"Here profile does not refer to a subset of a particular specification, for example 
the CSS Mobile profile, but refers to the document(s) exchanged between devices 
that describe the capabilities of a device."

Franklin:
The proposed change seems reasonable to me.

Graham:
That's the first time in several years of CC/PP I've heard that raised as a 
problem.

Your fix seems OK.
Issue 186:
Title: RDF Primer is unnecessary
Class: Editorial
Status:Dissent
Subject:
1.3.2 - remove the RDF tutorial info and instead refer to the
 relevant RDF specs/docs (e.g. RDF Primer).
Action Class:Disagree
WG Action:
Mark: I'm happy to accept this proposed change, but no strong feelings either way.

Franklin: I agree that the RDF primer should be unnecessary, but several 
readers over the course of the last couple of years have indicated
that they thought the primer was useful. So unless it is wrong,
I vote we leave it in. (However, it really should not be necessary
and I have no serious objection to removing it if it can be removed 
easily and quickly.)

Graham:
Well, I think it *was* necessary when it was written.  Maybe now there's 
enough other material around.  I think the decision should be be made by 
canvasing views of folks who haven't been steeped in RDF for the past 
couple of years.

Art: the tutorial info should be removed.  If you don't want
to remove it now, log the issue for the next version of CC/PP.
Issue 187:
Title: Get RDF Primer to acknowledge CC/PP
Class: Editorial
Status:Request Approved
Subject:
Get CC/PP added to the RDF Primer's list of RDF Applications.
Action Class:Fix
WG Action:
Issue 188:
Title: Use of casing for RFC2119
Class: Editorial
Status:Request Approved
Subject:
The use of casing for RFC2119 is inconsistent.  In 1.1
 upper case is used whereas in other sections (e.g. 2.1.4
 "optional", lower case is used.
Action Class:Fix
WG Action:
Check that all occurences of the words 
"MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", "MAY NOT", "REQUIRED", "RECOMMENDED" and "OPTIONAL"
are in upper case in the document.
Issue 189:
Title: Status of appendicies
Class: Editorial
Status:Request Approved
Subject:
Should explicitly state whether Appendices are Normative
 or Informative.
Action Class:Fix
WG Action:
Issue 190:
Title: Remove redundancy is section 2 and 3
Class: Editorial
Status:Dissent
Subject:
2- there is too much redundancy with the info in this section
 and section 3.  In the spirit of "less is more" and simplicity
 is good:

  * 2.1.1 - move everything in this section to 3.1.1

  * 2.1.2 - move everything in this section to 3.1.2

  * 2.1.3 - move everything in this section to 3.1.3

  * 2.1.4 - move everything in this section to a new
   INFORMATIVE chapter on Proxies.  [I'd be OK if all of
   the proxy stuff was completely removed and perhaps
   put in a W3C Note.]
Action Class:Disagree
WG Action:
Mark: I'm happy to accept this proposed change, but no strong feelings either way.

Franklin: This is an editorial style question. Graham and others thought this 
was a good way to present the material. I don't think we will be
able to make everyone happy, so I vote to leave it alone.

Graham:
I've no time to look into the details, but when I previously tried to do 
this it really wasn't easy.  The present structure is an attempt to 
describe the overall picture before getting into the low-level detail, and 
I still think that's a useful approach.  The early use of RDF/XML examples 
tends to obscure that a bit.  Do we really want to be getting into this 
kind of editorial revision at this stage?

Franklin:
I agree. This change has been debated in the past and we are unlikely
to come up with a quick solution that satisfies everyone. Art made it 
very clear to me that none of his complaints were serious enough to 
warrant slowing the process, so I think we should not make any changes.

Art: the redundancy adds nothing to the spec and makes it difficult
to read.  If you don't want fix this now, log the issue for the next 
version of CC/PP.
Issue 191:
Title: What is a CC/PP expression
Class: Editorial
Status:Request Approved
Subject:
2.2 - define "CC/PP expression"
Action Class:Fix
WG Action:
Mark: Suggest we change the text as follows

Current text:
Any CC/PP expression can use terms drawn from an arbitrary number 
of different vocabularies, so there is no restriction caused by re-using 
terms from an existing vocabulary rather then defining new names to 
identify the same information. Each vocabulary is associated with 
an XML namespace, as are the names that describe the underlying RDF 
and CC/PP structures.

Change to
Any CC/PP profile can use terms drawn from an arbitrary number 
of different vocabularies, so there is no restriction caused by re-using 
terms from an existing vocabulary rather then defining new names to 
identify the same information. Each vocabulary is associated with 
an XML namespace, as are the names that describe the underlying RDF 
and CC/PP structures.

Franklin:
The recommended change seems reasonable to me.

Graham:
Yes, that probably works.
Issue 192:
Title: RDF Schema Reference
Class: Editorial
Status:Request Approved
Subject:
2.2 - add [RDFSCHEMA] to the RDF Schema reference to clarify
 the reference is to the Mar 2000 CR (and not any of the WDs
 in progress).
Action Class:Fix
WG Action:
Issue 193:
Title: Unnecessary RDF tutorial information
Class: Editorial
Status:Dissent
Subject:
 2.3 - remove all of the RDF tutorial info in this section (and
 subsections); alternatively, add references to the relevant RDF 
 specs/docs.
Action Class:Disagree
WG Action:
Same as issue 186

Graham:
Yup.

Art: same as 186
Issue 194:
Title: Move proxy information
Class: Editorial
Status:Dissent
Subject:
* 3.2 - move all of this stuff to a new chapter on Proxies
 (include any info from 2.1.4 that is not redundant).
Action Class:Disagree
WG Action:
Same as issue 190.

Graham:
It already is separate, I thought.

Art: log it for next version
Issue 195:
Title: CC/PP should not define datatypes
Class: Major
Status:Dissent
Subject:
* 4. - CC/PP is going beyond its scope to define specific 
 datatypes.  It should only define a framework (e.g. the 
 structure) and leave vocabulary and datatype definitions
 to applications or instances of the CC/PP framework. 
Action Class:Hold to next version
WG Action:
Mark: I disagree with this. If CC/PP does not define datatypes, then
this means it is impossible to create CC/PP processors that can process
any vocabulary. All processors will be vocabulary specific. We already
have this problem with issues like protocol and resolution, we don't
want to make it any worse.

Franklin:  As I recall, the rationale for defining CC/PP types was
to simplify processing when CC/PP documents were embedded in 
other documents or when other documents were embedded within 
CC/PP documents. I understand Art's position, but I don't
think the spec "goes beyond its scope" by defining date types
and I don't think there is any need to eliminate CC/PP types 
from the spec. 

In addition, I have discussed this with Art and he is was very
clear that the most important issue for him was finalizing the
specification. He would prefer that all of his issues were 
ignored rather than delay the finalization of the spec.

Graham:
I don't see how it can be described as "beyond scope".  (A claim that it's 
unnecessary content might be more sustainable.)  The motivation for the 
datatypes was to provide some groundwork for implementing a CONNEG-style 
matching framework in a future development.  If folks charge off and define 
new vocabularies all inventing their own datatypes, that becomes much 
harder to achieve.  So I agree with you, but I would also say it is a 
debatable point.

Also, the use of datatypes matching CONNEG was, in my view, one of the 
things we did to achieve a degree of commonality (as required by the charter).

Art: I stand by my original assertion but Franklin disagrees so
I am OK with any decision the WG makes.  Note, I don't think
the schema in B.3. is correct based on the latest WDs from the
RDF Core WG in case that's important :-).  Graham should know
for sure.

CR telecon:
Hold this issue until next version, with the undertaking that when RDF
reaches a decision on datatyping, that will be adopted in subsequent
versions of CC/PP. Here we note Art Barstow's concern that there is a danger
CC/PP and RDF will be out of step, so we will add some boilerplate text to
the CC/PP WD explaining this.
Issue 196:
Title: CC/PP attribute vocabulary should be removed
Class: Major
Status:Dissent
Subject:
 Given there are no instances of CC/PP profiles (AFAIK)
 and no community has adopted the Attribute Vocabulary (AFAIK)
 remove this section and explain that defining Attribute 
 Vocabulary is application-specific (and perhaps add references to
 applications that have defined such vocabularies).
Action Class:Disagree
WG Action:
Franklin:    
It is my understanding that the vocabulary is a) non-normative
and b) part of our effort to accommodate CONNEG and c) useful as
an example vocabulary.

Again, I don't think the document should change.

Graham:
Me too.  My experience is that with a generic technology it is important to 
have at least some examples of how it is expected to be used.

The examples are also an early (of itself insuffcient) step to maintaining 
some correspondence with CONNEG.  I'm hoping we'll be have URIs to tap the 
CONNEG registry at some stage, so the example vocabulary may be displaced 
by terms that are traceably linked to the registry.

Art: I also stand by this assertion.  And I don't buy the
argument that section 4 is "informative".  Log it for next 
version.

Mark / Roger: There are two reasons for putting in the example vocabulary.
The first is to steer people to adopting a standard set of terms. This
will soon be superseded by the DI-WG work on Core Presentation Attributes.
However this fact has been addressed in the CC/PP doc by making this
example vocabulary non-normative. The second reason is for a given 
vocabulary demonstrating how it is defined in RDFS. Therefore
it is our view there is still some value in retaining the sample vocabulary
as long as it clearly non-normative. 

CR telecon:
Art Barstow's primary objection here is that CC/PP shouldn't include
datatyping, which is used in the example vocabulary. However given the
decision on issues 195 and 199 this is moot, Art said he is happy for the WD
to keep the example vocabulary, but stressed his view is that the CC/PP WD
could be simplified by avoiding a discussion of datatypes, and cited the
remaining issues to be reviewed as evidence.
Issue 197:
Title: RDF Schema Reference
Class: Editorial
Status:Request Approved
Subject:
* 6.1 - RDFSCHEMA - add this doc is a Candidate Recommendation 
Action Class:Fix
WG Action:
Issue 198:
Title: UAProf reference
Class: Editorial
Status:Request Approved
Subject:
* 6.2 - there appears to be a formatting bug in the UAPROF ref
Action Class:Fix
WG Action:
Issue 199:
Title: Remove datatype definitions from schema
Class: Major
Status:Dissent
Subject:
* B.3 - remove the datatype definitions from the core schema.
 I would not define these datatypes anywhere but if they must 
 be defined, put them in a separate schema.
Action Class:Hold to next version
WG Action:
Mark:
Same as issue 195. For now, I think CC/PP
should retain datatype definitions for the reasons outlined above.

Franklin:
I agree with Mark.

Graham:
Yes.

Art: I stand by my original assertion but Franklin disagrees so
I am OK with any decision the WG makes.  Note, I don't think
the schema in B.3. is correct based on the latest WDs from the
RDF Core WG in case that's important :-).  Graham should know
for sure.

CR telecon:
Hold this issue until next version, with the undertaking that when RDF
reaches a decision on datatyping, that will be adopted in subsequent
versions of CC/PP. Here we note Art Barstow's concern that there is a danger
CC/PP and RDF will be out of step, so we will add some boilerplate text to
the CC/PP WD explaining this.
Issue 200:
Title: anyURI class
Class: Editorial
Status:Request Approved
Subject:
* B.3 - why are there two definitions of the anyURI Class?
 Which definition is resolved when an application refers to
 ccpp:anyURI?  
Action Class:Fix
WG Action:
Mark:
There are a few errors in this schema, particularly
duplications and errors in comments. Check and fix.
Issue 201:
Title: Use of language in document
Class: Editorial
Status:Request Approved
Subject:
* C. - instead of using "mandatory", use RFC2119 language.
Action Class:Fix
WG Action:
Issue 202:
Title: definition of CC/PP parser
Class: Editorial
Status:Request Approved
Subject:
* D.1 - add a definition of "CC/PP parser" 
Action Class:Fix
WG Action:
Kaz:
And my definiton of the CC/PP parser is:
anyalize CC/PP syntax and expand the CC/PP information into memory space
of the particular software.  Only analize syntatical information of the CC/PP.

Franklin:
Mark's (I think you mean Kaz's?) definition of a CC/PP parser is fine, but I 
have included an alternate definition:

A CC/PP parser transforms a CC/PP document from its RDF format 
into some other format. A CC/PP parser understands CC/PP syntax and structure, 
including "defaults", but it does not understand application semantics 
associated with Attributes of CC/PP Components.

Graham:
Er, why do we need the term "CC/PP parser"?  I don't remember where it 
appears.  As CC/PP is based on RDF, I think that there should not be a 
separate CC/PP parser from the RDF parser.

Mark:
It's because we use it here:
"A simple CC/PP parser is not
required to be schema-aware, and its implementation does not need
to have knowledge of the RDF class of any attribute or resource,
nor is the profile required to carry RDF type information. The
discussion of classes and schema-aware processing is in relation to
possible future developments of generic RDF processors that may
deal with CC/PP and other RDF vocabularies and schemas, possibly
mixed in a single document".
Suggest we replace the term "CC/PP parser" with the term
"CC/PP processor" that we use elsewhere, then add Franklin's definition
above in the glossary as a "CC/PP processor"?

Lorrie Cranor http://lists.w3.org/Archives/Public/www-mobile/2001Mar/0003.html

CC/PP and Privacy: harmonization of CC/PP and P3P 21 March 2001
Issue 57:
Title: CC/PP and Privacy: harmonization of CC/PP and P3P
Class: Editorial
Status:Agreed by Requester
Subject:
P3P is listed in Appendix A.2 Abbreviations -- but there is no mention of P3P
anywhere else in the spec. It would be relevant to mention P3P where privacy
concerns are discussed, and perhaps in other places as well. Somewhere in this
spec it should probably mention that CC/PP vocabulary elements can also be
represented in a P3P data set -- with an explanation as to how. You might also
note that both P3P and CC/PP involve comparisons of preferences and policies.
Typically P3P would have the client do the comparison and CC/PP would have the
server do the comparison, but we could imagaine other scenarios. Perhaps CC/PP
could be used to facilitate sending P3P user preferences to servers (this in
and of itself raises privacy concerns, but with the user's permission, this
could potentially be useful).
Action Class:Fix
WG Action:
The basic problem is the use of non-URI valuses to 
identify elements of a P3P policy. 
 The core P3P data elements are defined 
in a non-URI form. CC/PP can't incorporate them without some mapping being

defined. CC/PP doesn't have HTTP mapping. So P3P would be premature. The privacy 
document introduce this adaptation
 of an integrated framework. These go 
into the trust model document. It just goes away. Published W3C WD, CC/PP

Implementors Guide: Privacy and Protocol. Added a link to that document to the 
current WD.
Issue 58:
Title: CC/PP and Privacy: harmonization of CC/PP and P3P
Class: Minor
Status:Agreed by Requester
Subject:
In appendix F there is a discussion of HTTP request processing. It would be good 
to discuss how CC/PP would fit in here when P3P is used as well. There's no one 
right answer, but some guidelines and/or an example might be useful.
Action Class:Fix
WG Action:
Same as Issue 57. Published W3C WD, CC/PP Implementors Guide: Privacy and Protocol.

Dan Connolly http://lists.w3.org/Archives/Public/www-mobile/2001Mar/0007.html

Editorial changes in rdf examples 22 March 2001
Issue 59:
Title: Editorial changes in rdf examples
Class: Major
Status:Agreed by Requester
Subject:
I took the cc/pp schema http://www.w3.org/2000/07/04-ccpp.rdf and converted it
to Notation3 
http://www.w3.org/DesignIssues/Notation3 
since looking at things from a different angle often uncovers things... 
I see: 
        <#Value>
        :subClassOf ccpp:Integer,
        ccpp:Rational,
        ccpp:Set,
        ccpp:Text,
        ccpp:URI.

This is backwards, no? x subClassOf y means that every X is a Y, right? So 
every ccpp:Value is a ccpp:Rational and a ccpp:Set and a ccpp:Text at the
same time? I think you mean the subClassOf relationships to be the other
way around; otherwise, I think there are no ccpp values, since Text and 
Set are disjoint (aren't they?).
Action Class:Disagree
WG Action:
Seems to be based on his using an old document. Reported issue does not arise 
in the current public version.
Issue 60:
Title: Editorial changes in rdf examples
Class: Major
Status:Agreed by Requester
Subject:
Also, for Integer, URI, etc. please use the names from XML Schema data types
part 2 rather than making up new class names:
http://www.w3.org/2001/XMLSchema#int
http://www.w3.org/2001/XMLSchema#anyURI

(see appendix A 
http://www.w3.org/TR/2001/PR-xmlschema-2-20010316/#schema)
Action Class:Disagree
WG Action:
Same as Issue 59.
Comment: Due to recent decisions in the RDF-core working group, it is no longer possible to use XML Schema data types in RDF Schema in this way. Therefore the CC/PP WG has had to revert to making up class names.
Issue 61:
Title: Editorial changes in rdf examples
Class: Minor
Status:Agreed by Requester
Subject:
looking at
http://www.w3.org/TR/CCPP-struct-vocab/#xtocid-33666558
http://www.w3.org/TR/2001/WD-CCPP-struct-vocab-20010315/#xtocid-33666558
http://www.w3.org/2000/07/04-ccpp.rdf     

I see rdfs:Property in 3 places:
        <rdfs:Property
        rdf:id='component'>
        <rdfs:Property
        rdf:id='defaults'>
        <rdfs:Property
        rdf:id='Defaults'>
it's rdf:Property, not rdfs:Property. (I'm not sure why, but it is.)
Action Class:Disagree
WG Action:
Same as Issue 59.
Issue 113:
Title: Inform users what accept headers they need to use to get the schema
Class: Major
Status:Request Approved
Subject:
In the cc/pp spec,

http://www.w3.org/TR/2001/WD-CCPP-struct-vocab-20010315/

I see three namespaces:
<!ENTITY ns-ccpp 'http://www.w3.org/2000/07/04-ccpp#'>
<!ENTITY ns-ccpp-proxy 'http://www.w3.org/2000/07/04-ccpp-proxy#'>
<!ENTITY ns-ccpp-client 'http://www.w3.org/2000/07/04-ccpp-client#'>

and I see that there are schemas available at those addresses, if I dig around. 
If I visit them with my browser, I get an HTML document that links to the spec,
but not to the schema(!). I can get the schemas by doing: 
wget --header="Accept:text/xml" http://www.w3.org/2000/07/04-ccpp-client

but there are no clues to that effect anywhere in the spec. Please inform users 
what accept headers they need to use to get the schema. (Unfortunately, the RDF 
specs don't yet specify things like format negotiation and MIME types for RDF; 
we plan to address that soon: 
http://www.w3.org/2000/03/rdf-tracking/#mime-types-for-rdf-docs
)
Action Class:Fix
WG Action:
Fix: publication issue
Discussion URLS:
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0070.html
Comment: Inform users what accept headers they need to use to get the schema
Issue 114:
Title: Inform users what accept headers they need to use to get the schema
Class: Editorial
Status:Request Approved
Subject:
Please add a link from the spec
http://www.w3.org/TR/2001/WD-CCPP-struct-vocab-20010315/
to the archive of comments
http://lists.w3.org/Archives/Public/www-mobile
Action Class:Fix
WG Action:
No details
Comment: Add to link to the comments

Susan Lesch http://lists.w3.org/Archives/Public/www-mobile/2001Mar/0008.html

Editorial Changes 25 March 2001
Issue 62:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
HTML Tidy set to not indent will reduce the file size by 10%. 
(see http://www.w3.org/People/Raggett/tidy/)
Action Class:Fix
WG Action:
No details
Issue 63:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
Appendix A is full of security terms that are never used. They raise and
do not answer questions. I would remove these terms from Appendix A unless
you plan to address them: Anonymization, Assurance of origin, Assurance 
of receipt, Authentication, Authorization, Channel security, Confidentiality,
Integrity, Non-Repudiation, Non-Repudiation of Origin, Non-Repudiation of 
Receipt, Object security, Proof of receipt or Proof of delivery, 
Receiver-initiated Transmission, and Sender-initiated transmission. There 
might be a few more, like Variant Content that are unused and can be cut.
Action Class:Fix
WG Action:
No details
Issue 64:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
Also in Appendix A, I would try to reword anything borrowed from WAP
or other sources unless it was W3C's content originally.
Action Class:Fix
WG Action:
No details
Issue 65:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
Some tables have a border attribute with no value, which means it is 
a value of the attribute frame. They could all be table border="1".
(see http://www.w3.org/TR/html401/struct/tables.html#h-11.3.1)
Action Class:Fix
WG Action:
No details
Issue 66:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
You might link to the Namespaces in XML reference [2] the first time 
namespaces are mentioned in 1. par. 3 rather than wait until 2.2 par. 4.
Action Class:Fix
WG Action:
No details
Issue 67:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
In 3.1.2, the last two paragraphs refer to other sections by name. All 
other references to other sections are by number with no link. These 
references to other sections should all match.
Action Class:Fix
WG Action:
No details
Issue 68:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
Globally, web -> Web
Action Class:Fix
WG Action:
No details
Issue 69:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
Also globally in prose, UAPROF or UAprof -> UAProf (according to WAP
http://www1.wapforum.org/tech/documents/WAP-174_100-UAProf-20000621-a.pdf). 
That includes the E.2 heading.
Action Class:Fix
WG Action:
No details
Issue 70:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
In its first occurrence in 1. par. 3, "user agent profiles" is lowercase. 
Later it is inexplicably cAPItalized. Maybe the term could be introduced 
here as "WAP User Agent Profiles (UAProf)" with later occurrences all 
"UAProf"? Also in A.1, maybe the definition could mention the short form 
"(UAProf)"?
Action Class:Fix
WG Action:
No details
Issue 71:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
The p following Figure 3-10 should start outside the dl.
Action Class:Fix
WG Action:
No details
Issue 72:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
Abstract list item 3: "xml" should be "XML".
Action Class:Fix
WG Action:
No details
Issue 73:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
Status section:
"working group" (five times) should be "Working Group" (see
cAPItalization in the W3C Process Document http://www.w3.org/Consortium/Process/).
Action Class:Fix
WG Action:
No details
Issue 74:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
Status par. 2: "November 14 ," should be "November 14,"
Action Class:Fix
WG Action:
No details
Issue 75:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
Status par. 4: "this document is created from merge of CC/PP Structure and CC/PP
Vocabularies." should be "this document was created by merging CC/PP Structure 
and CC/PP Vocabularies." (I think)
Action Class:Fix
WG Action:
No details
Issue 76:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
Status par. 4: "minutes(Member-only link)" should be "minutes (Member-only link)"
Action Class:Fix
WG Action:
No details
Issue 77:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
Status par. 3: "W3CDevice Independence activity" should be "W3C Device Independence
Activity" (two changes)
Action Class:Fix
WG Action:
No details
Issue 78:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
1. par. 5: "in the Appendix F" should be "in Appendix F"
Action Class:Fix
WG Action:
No details
Issue 79:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
In 1.3.1 par. 4, the key words REQUIRED, RECOMMENDED and OPTIONAL are missing.
Action Class:Fix
WG Action:
No details
Issue 80:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
2.1.4 par. 4: "each of which, needs" should be "each of which needs"
Action Class:Fix
WG Action:
No details
Issue 81:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
2.1.4 par. 5: "To indicate sequence of proxies" should be "To indicate a sequence 
of proxies"
Action Class:Fix
WG Action:
No details
Issue 82:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
2.3.1 par. 6: "meaning, defines" should be "meaning, and defines"
Action Class:Fix
WG Action:
No details
Issue 83:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
2.3.1 par. 6: "[4]" should be
"<a href="#%5B4%5D">[4]</a>"
Action Class:Fix
WG Action:
No details
Issue 84:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
2.3.1 par. 7: "data type" should be "data type"
Action Class:Fix
WG Action:
No details
Issue 85:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
2.3.2 par. 5: ""basic RDF serialization syntax." should be ""basic RDF 
serialization syntax."" (note the quotes)
Action Class:Fix
WG Action:
No details
Issue 86:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
2.3.2 par. 6: "abbreviation forms" should be "abbreviated forms"
Action Class:Fix
WG Action:
No details
Issue 87:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
2.3.2 par. 6: "XML forms. using" should be "XML forms. Using"
Action Class:Fix
WG Action:
No details
Issue 88:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
2.3.3 par. 2: "RDF schema" should be "RDF Schema" (shorthand name of the 
spec. would be cAPItalized, otherwise schema would be lowercase)
Action Class:Fix
WG Action:
No details
Issue 89:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
2.3.3 par. 4: "Specific" should be "Specific"
Action Class:Fix
WG Action:
No details
Issue 90:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
2.3.3 par. 6: "The RDF Schema" should be "RDF Schema" or 
"The RDF Schema specification"
Action Class:Fix
WG Action:
No details
Issue 91:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
2.3.3 Figure 2-12 img alt text: "RDF Schema" should be "RDF schema"
Action Class:Fix
WG Action:
No details
Issue 92:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
3.1.3 par. 5
Inline defaults are logically equivalent to defaults contained in
externally referenced document, and external documents would be normal way of 
referencing default values. The following is the external the XML serialization
of the same profile using externally referenced defaults: [minor changes:]
Inline defaults are logically equivalent to defaults contained in externally 
referenced documents, and external documents would be the normal way of 
referencing default values. The following is the external XML serialization
of the same profile using externally referenced defaults: 
(This comes out wrong in the table, see the original for correct placing 
of correction marks)
Action Class:Fix
WG Action:
No details
Issue 93:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
4.1.1.2 Case-insensitive text par. 2: "upper and lower case" should be 
"upper- and lowercase" and "upper- and lower- case" should be "upper- and 
lowercase
Action Class:Fix
WG Action:
No details
Issue 94:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
4.1.1.2 Case-insensitive Note: "any specific language, in these contexts,
the protocol" should be "any specific language. In these contexts, the protocol"
Action Class:Fix
WG Action:
No details
Issue 95:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
4.1.1.2 Tokens par. 2: "upper and lower case" should be "upper and lowercase"
Action Class:Fix
WG Action:
No details
Issue 96:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
4.2 par. 2
Thus, use of an existing extension vocabulary is encouraged wherever
possible, or publication of a new vocabulary definition containing detailed 
descriptions of the various CC/PP attribute names. [could read:]
Thus, use of an existing extension vocabulary or publication of a new 
vocabulary definition containing detailed descriptions of the various CC/PP 
attribute names is encouraged wherever possible.
Action Class:Fix
WG Action:
No details
Issue 97:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
6. [1]: "Extensible Markup Language (XML) 1.0;" should be "Extensible Markup
Language (XML) 1.0 (Second Edition)"
"Tim Bray, Jean Paoli, C. M. Sperberg-McQueen;" should be "Tim Bray, Jean Paoli,
 C. M. Sperberg-McQueen, Eve Maler;"
Action Class:Fix
WG Action:
No details
Issue 98:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
6. [7]: "Internet draft" should be "Internet-Draft"
Action Class:Fix
WG Action:
No details
Issue 99:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
6. [12], [13], [14]: "XML schema" should be "XML Schema" [also these are PRs
as I imagaine you know]
Action Class:Fix
WG Action:
No details
Issue 100:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
A.1: "<dd>Anonymization</dd>" should be "<dt>Anonymization</dt>" 
[This term is never used.] 
Authentication is broken into two dd's and could be one. [This term is never used.]
Action Class:Fix
WG Action:
No details
Issue 101:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
A.1 Cacheable: "sever" should be "server"
Action Class:Fix
WG Action:
No details
Issue 102:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
A.2 HTML: "Hyper Text Markup Language" should be "HyperText Markup Language"
Action Class:Fix
WG Action:
No details
Issue 103:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
A.2 HTTP: "Hyper Text Transfer Protocol" should be "Hypertext Transfer Protocol"
Action Class:Fix
WG Action:
No details
Issue 104:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
A.2 P3P: "Project for Platform for Privacy Preferences" should be "Platform 
for Privacy Preferences Project", or "Platform for Privacy Preferences"
Action Class:Fix
WG Action:
No details
Issue 105:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
A.2 XHTML: "Extensible Hyper-Text Markup Language" should be "Extensible HyperText 
Markup Language"
Action Class:Fix
WG Action:
No details
Issue 106:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
A.2 XSL: "Extensible Style Language" should be "Extensible Stylesheet Language"
Action Class:Fix
WG Action:
No details
Issue 107:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
D.3.1 heading: "don't: reuse" should be "reuse"
Action Class:Fix
WG Action:
No details
Issue 108:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
D.3.2 Notes: "in a profile.<b><i>NOTE</i>:</b> 
if there a" should be "in a profile.</p>
<p><b><i>
NOTE</i>:</b> if a"
Action Class:Fix
WG Action:
No details
Issue 109:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
D.3.5 par. 1: "lower case" should be "lowercase"
Action Class:Fix
WG Action:
No details
Issue 110:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
.3.5 par. 2: "upper case" should be "uppercase"
Action Class:Fix
WG Action:
No details
Issue 111:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
E. par. 1: "vocabularies" should be "vocabularies."
Action Class:Fix
WG Action:
No details
Issue 112:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
W.: "20010223 Published as First Working Draft." should be "20000223 ? Published 
as first Working Draft."
Action Class:Fix
WG Action:
No details

Tom Worthington http://lists.w3.org/Archives/Public/www-mobile/2001Mar/0012.html

Add accessibility features 28 March 2001
Issue 115:
Title: Add accessibility features
Class: Minor
Status:Request Approved
Subject:
The document appears to be weighted towards device capabilities, rather than 
user needs. While "user preferences" is in the introduction, there appears to 
be no further mention of it. This could be easily added to complement the Web 
Content Accessibility Guidelines
;<http://www.w3.org/TR/WCAG20/>.

Without this there is the risk that the CC/PP will make the web less usable, 
by making it more difficult to tailor to the needs of the user. We have the 
opportunity to improve the user interface with mobile devices, as well as 
overcome some of their technical limitations with accessibility features

<http://www.tomw.net.au/2000/scsp.html>.
Action Class:Fix
WG Action:
Add section addressing this: including the use cases
Discussion URLS:
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0070.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0075.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0077.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0080.html

Holger Blasum http://lists.w3.org/Archives/Public/www-mobile/2001Mar/0016.html

Editorial corrections 23 March 2001
Issue 116:
Title: Editorial corrections
Class: Editorial
Status:Request Approved
Subject:
Section 2.1.3 Defaults, Figure 2-3b: CC/PP profile using defaults in XML 
[see also Aaron Swartz]

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp">
<rdf:Description rdf:about="HWDefault">

<rdf:type resource="HardwarePlatform" />
<display>320x200</display>

</rdf:Description>
[SoftwarePlatform, UABrowser]
</rdf:RDF>

To which default namespace does the "display" Attribute belong ? Is it 
intentional that no default namespace had been declared ? If so, why ? (Note: 
In the corresponding figure 3-4a (Section 3.1.3 Defaults) these Attributes 
belong the xmlns 

prf="http://www.wapforum.org/UAPROF/
ccppschema-20000405#")
Action Class:Fix
WG Action:
There is no default namespace, no namespace prefix
Issue 117:
Title: Editorial corrections
Class: Minor
Status:Request Approved
Subject:
Appendix C, second paragraph
"The client attribute names defined below may be used to identify some common 
feature associated with client devices that print or display visual information, 
such as text or graphics". Does "common features" refer to hardware, operating 
system or the browser (e.g. pix-x could refer to the browser that has less 
pixels than the display)? With regard to demand D.3.2. that an "attribute name 
must be unique in a profile" such unclearness gives unsure feelings.
Action Class:Fix
WG Action:
Delete D.3.2 - Components used in proxy description is typed.
Issue 118:
Title: Editorial corrections
Class: Editorial
Status:Request Approved
Subject:
Also in Appendix C, is "charHeight" really the "number of lines of text" that 
can be displayed ?
Action Class:Fix
WG Action:
No details
Issue 119:
Title: Editorial corrections
Class: Editorial
Status:Agreed by Requester
Subject:
As far as I understand App C (from the "subliminal feeling") the WG still wants 
to honor the former IETF-CONNEG work, but does not really encourage one to use 
it...
Action Class:Disagree
WG Action:
There is more to this than just spreading the word. Same as 143.
Holger writes:
>Thanks for your mail regarding the resolution of CC/PP issues.
>unlike last year, currently I am not a stakeholder in CC/PP and 
>also do not have access to 
>http://www.w3.org/Mobile/CCPP/Group/Drafts/WD-CCPP-struct-vocab-20020716/.
>When I sent the comments to the group that was meant as feedback; 
>I do fully trust the WG that the measure taken were appropriate.
>So the default action from my side would be just not to do a further
>round of handshaking; otherwise iff you need any more formal response 
>pls just send me the documents I have to agree to ;-)

>(Had a look at the documents, but honestly do not feel "into it" 
>enough at the moment to sustain a well-founded argument, and do 
>not want to delay the process...)

Franklin Reynolds:
> I don't really understand why this comment is an issue 
> requiring any action from the WG. 
> Was the CONNEG connection described to everyone's satisfaction?
Issue 120:
Title: Editorial corrections
Class: Editorial
Status:Agreed by Requester
Subject:
Profile subclassing in 
http://www.w3.org/TR/2001/WD-CCPP-struct-vocab-20010315/
Although Request-profile, Client-profile and Proxy-profile all inherit from 
"Profile" there are no properties (composing elements) or methods that they 
share (e.g. if sb was to implement this as classes in an OO language).
Is it at least planned that they share some common accessors in future ? 
have I overlooked something very elemental in the spec ? Otherwise leaving the 
spec (what does polymorphism help a developer when (s)he has no common 
methods/data structures to access the contents?) without explanation seems 
misleading. In other words, one should decide whether proxyBehavior should 
become a subclass of Component, currently it is not (in 3.2.2 and B.3) or 
explain why one has (not) done this.
Action Class:Disagree
WG Action:
RDF allows different kinds of statement about a resource to be mixed. 
This can be done with schemas without placing additional demands on 
single-use. Clarify.

See Holger's reply in Issue 119.

Franklin Reynolds:
> I think the WG action comments are inscrutable... As I
> recall, the rationale for subclassing different types of 
> profiles from a single profile is partly stylistic. It just 
> seemed to be good practice to try to derive classes from base 
> classes. If there is ever aneed to define base properties for 
> profiles, then the necessary class hierarchy is already in 
>place.
Discussion URLS:
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0070.html

Dave Beckett http://lists.w3.org/Archives/Public/www-mobile/2001Apr/0006.html

Editorial changes (most of comments pointed out previously) 4 April 2001
Issue 121:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
Firstly I'd like to second Dan Connolly's comments in
http://lists.w3.org/Archives/Public/www-mobile/2001Mar/0006.html
http://lists.w3.org/Archives/Public/www-mobile/2001Mar/0007.html
- rdf:Property not rdfs:Property
- the subclassing for ccpp:Value is the wrong way round
- think about using XML schema definitions of some terms
Action Class:Fix
WG Action:
No details
Comment: See issue 60 for decisions relating to the adoption of XML Schema definitions in CC/PP.
Issue 122:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
I tried parsing http://www.w3.org/2000/07/04-ccpp.rdf with 6 different RDF/XML
parsers and that worked OK giving the same answers. I tried the example just at
the end of section 1 and it failed on a few parsers because the first element 
<RDF..> element should have been <rdf:RDF> Correct
that caused most of them to work but the stanford one failed - 
http://www-db.stanford.edu/~melnik/rdf/API.html
> Don't assume that if it works with SiRPAC (W3C), it is correct :-)
Action Class:Fix
WG Action:
No details
Discussion URLS:
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0070.html
Issue 123:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
Figure 2-1b: CC/PP profile components in XML Inconsistent use of rdf:about / 
about. Get different answers here from different parsers (3 statements, 0 
statements, crash), but I suspect a conformance issue not anything else.
Action Class:Fix
WG Action:
No details
Issue 124:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
Figure 2-2b: Complete CC/PP profile example in XML
No default namespace defined, but it is used for <display> etc. elements. 
RDF parsing rules mean the entire content can be ignored so I suspect you need 
to add another xmlns: The parsers accept this and generate illegal RDF statements 
with properties of the XML element names.
Action Class:Fix
WG Action:
No details
Issue 125:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
2.1.3 Defaults
Figure with no label, visually looks OK but examples 2-3 contain no
default xmlns so display etc. elements are not guaranteed to generated RDF 
statements.
Action Class:Fix
WG Action:
No details
Issue 126:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
figure 2-4b: Overriding a default value in XML Ditto default xmlns in both 
examples
Action Class:Fix
WG Action:
No details
Issue 127:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
In 'Note' just at end; relative URIs can be used in RDF but not recommended 
for namespaces - the latter is my opinion.
Action Class:Fix
WG Action:
Fix namespace reference
Issue 128:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
Section 2.2

Fragment:

-----------------------------------------------
<?xml version="1.0"?>

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"

xmlns:uaprof="http://www.wapforum.org/

UAPROF/ccppschema-20000405#">

------------------------------------------------

Why are there two references to the RDF namespace? This is strange in the following 
sections since all rdf concepts are used and there is no use of elements in the 
default namespace. Maybe note that the namespace prefixes will change as the 
document changes, and shouldn't be used in products blah blah like boilerplate 
at the top
Action Class:Fix
WG Action:
Uniform examples are used
Issue 129:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
2.3.1 Basic RDF Model

In definition of Resources it says "plus optional anchor ids" whereas the box above 
uses #fragment-id - make this consistent and change any references to it.
Action Class:Fix
WG Action:
No details
Issue 130:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
2.3.1 Basic RDF Model

Properties definition section has reference [4] that isn't a hyperlink, change that 
and references to Sections such as under definition Statements to be links.
Action Class:Fix
WG Action:
No details
Issue 131:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
Figure 2-9a: XML fragment containing RDF resource description

It may be a fragment but shouldn't those be <rdf:Description> blocks
like used all the previous examples?
Action Class:Fix
WG Action:
No details
Issue 132:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
Figure 2-10: RDF serialization

Has a different RDF header again, not like previous ones but similar to the
fragment in an earlier section. Again use <Description> here (and 
<type>) with default namespace versus <rdf:Description> in previous
examples
Action Class:Fix
WG Action:
Same as issue 128
Issue 133:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
2.3.3 RDF schema
Can you add a link to the RDF schema document here since this is
the first discussion of it.
Action Class:Fix
WG Action:
No details
Issue 134:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
3.1.3 Defaults
In examples here using no rdf: prefixes on Description, type elements
or about, resource attributes. So why declare xmlns:rdf ?
Action Class:Fix
WG Action:
Same as issue 128
Issue 135:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
3.1.3 Defaults
One note after an un-numbered figure says:

[[NOTE: A default document uses a <Description> element as its root node. 
The <Description> is named using an about= attribute whose value is a URI.
This URI MUST correspond to the value in the rdf:resource= attribute ...]]
however you don't use rdf:resource attribute in the example!
Action Class:Fix
WG Action:
Old document problem. (fixed in this version)
Issue 136:
Title: Editorial changes (most of comments pointed out previously)
Class: Minor
Status:Agreed by Requester
Subject:
3.1.3 Defaults
This kind of thing is used to label bare URIs:
<http://www.w3.org/2000/07/04-ccpp-proxy#>

and although this is recommended by the URI spec, I suggest you add a note 
somewhere early on explaining what this encoding means
Action Class:Disagree
WG Action:
Do not need to do anything special about this particular case.
Mark Butler: 
> In the disposition of comments, there is an issue you have raised
> (issue 136) that is marked potential dissent. However I believe this issue
> is 
> misclassified as URLs with angle brackets
> >http://www.w3.org/2000/07/04-ccpp-proxy#>
> now do not have angle brackets in the WD e.g.
> http://www.w3.org/2000/07/04-ccpp-proxy#
> 
> Therefore I would be grateful if you could look at the issue and the WD
> and if you are happy let me know so we can reclassify the issue as 
> agreed by requester. Alternatively if you think the WG has not resolved your
> issue i.e. dissent please let me know also.
Dave Beckett:
> I am happy with the WG action to issue 136 as 
> shown in the WD draft above.
Issue 137:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
3.2.1 Capability chaining examples back to rdf: everywhere again
Action Class:Fix
WG Action:
Same as issue 128.
Issue 138:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
3.2.2.1 Example: XHTML to WML transcoding

has example with line
<rdf:li>http://example.org/example/XHTML-1.0>
probably should be:
<rdf:li rdf:resource="http://example.org/example/
XHTML-1.0"/>
unless you wanted it as a string?
Action Class:Fix
WG Action:
Same as issue 121
Issue 139:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
Appendixes

Can you add the URIs of all schema, attribute vocabulary documents into the spec. 
near where they are textually included examples so that it is clear what the 
included document is.
Action Class:Fix
WG Action:
No details
Issue 140:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
Overall, need I say use consistent rdf: or not throughout? I suggest
using rdf: everywhere and removing default namespace. I this makes the results 
too verbose, and it might, choose the other alternative -no rdf: prefix and 
set it as the default namespace throughout.
I've been over this before in:
http://www.redland.opensource.ac.uk/
notes/concepts.html which provides a ready reference for them.
Action Class:Fix
WG Action:
Same as 128
Issue 141:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
Also, try a couple of RDF/XML parsers, you can do that at my demo which I've 
been using here to try things out:
http://www.redland.opensource.ac.uk/demo
or try some of the other online demos. Maybe automate checking the fragments 
and examples standalone and then build the document from the bits? (after 
encoding in XHTML).
Action Class:Fix
WG Action:
Send the URI to him and ask him to do it.
Mark Butler: I'm satisfied the RDF in the WD is compatible with 
RDF Filter and ARP, if we need to check it with other parsers 
I think that is an issue for RDF compliance not CC/PP
Issue 142:
Title: Editorial changes (most of comments pointed out previously)
Class: Editorial
Status:Request Approved
Subject:
Add more links around document, make sure all figures and examples
have <a name> and captions/labels/numbers so they can be cited 
and linked to in potential CC/PP validators
Action Class:Fix
WG Action:
Put them all in separate files so they can be referenced.

Larry Masinter http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001JanMar/0060.html

Relationship to CONNEG 1 March 2001
Issue 143:
Title: Relationship to CONNEG
Class: Major
Status:Dissent Overruled
Subject:
I would much prefer if the document for CC/PP did a 
thorough job of (a) justifying why the IETF work in device capabilities is 
inadequate for the purpose of W3C protocols and (b) more directly mapping
between the IETF work and CC/PPs framework, As it is, no mechanism has been put 
in place to keep these mechanisms from diverging. It is insufficient that the
core CC/PP attributes are "based on" RFC 2534. I would expect normative reference 
(and not merely a comparison index) to:

RFC 2506 Media Feature Tag Registration Procedure
RFC 2533 Syntax for Describing Media Feature Sets (and RFC 2738 corrections
thereto)
RFC 2703 Protocol-independent Content Negotiation Framework
RFC 2534 Media Features for Display, Print, and Fax
RFC 2913 MIME Content Types in Media Feature Expressions
RFC 2912 Indicating Media Features for MIME Content
RFC 2938 Identifying Composite Media Features
RFC 2987 Registration of Charset and Language Media Features

As it stands, it's unclear why this work has been undertaken at all.
Action Class:Disagree
WG Action:
Clarify the difference content and context. Published W3C Note which 
identify the technical areas of difference, state rationale and what
if anything can be done to archive convergence. And add a link to that 
W3C Note to the WD.

Franklin Reynolds:
>This sort of discussion belongs in the charter or the "requirements" 
> document. 
> 
> As I recall the original thinking behind the CC/PP note was:
> 1. CONNEG was more complex than needed and required too many things 
>    to change at once to be practical (this may have been a mistake)
> 2. We needed to use XML to satisfy the WAP community
> 3. We needed to use RDF to be compatible with the P3P work
> 4. We wanted to be able to use APPEL 
> 5. There was no incentive to use CONNEG (it was a work-in-progress,
>    and at the time, the fax community seemed to be the only customer)
> 
> By the time the W3C got around to a CC/PP WG, we had to deal with
> UAProf compatibility. There were no equally strong incentives to adopt
> CONNEG. Furthermore, Graham and I convinced ourselves that 
> if needed, we could use RDF and CC/PP to encode CONNEG style matching 
> rules.

Larry:
My original comment was motivated by an observation that
there had been insufficient coordination with an existing
structure and vocabulary for Client Capabilities and Preferences
Profiles, namely the ones created by the IETF. From the
response, it seems as if my comment wasn't understood
in that context.

Moving the CC/PP Client Vocabulary to an Appendix (Appendix C)
instead of a part of the specification
http://www.w3.org/TR/2000/WD-CCPP-vocab-20000721/#ClientVocabulary
hasn't helped much, since the main document still creates a
new structure and the appendix still creates a new vocabulary.

At present, the situation has gotten worse: the W3C
itself also has a Candidate Recommendation for Media Queries
  http://www.w3.org/TR/css3-mediaqueries/
which is yet ANOTHER structure and vocabulary for describing
Client Capabilities and Preferences Profiles, not coordinated
with this specification.

It seems unwise for W3C to publish yet another structure and
vocabulary for client capabilities and preferences as a
Candidate Recommendation. Three standards are worse than two,
two standards are worse than one.

There may be legitimate reasons for supporting multiple syntactic
representations (RDF, BNF-based strings with or without "<"),
but there is no apparent reason for having incompatible vocabularies
or structures other than insufficient attention to coordination.
At least the document points to the other specification, but
it doesn't justify the differences.

One of the primary applications for CC/PP seems to be
"client expressing capabilities to server within HTTP"
(since this is the only application described in any detail
within Appendix F: CC/PP Applications). However, the concerns
of the HTTP implementing community for avoiding high-overhead
syntactic representations within HTTP headers might lead one
to choosing one of the alternative syntactic representations.
The IETF CONNEG work was, after all, originally motivated to
support content negotiation within HTTP and the syntax designed
with that application in mind. Further, many in the HTTP community
at the time CONNEG was started was skeptical about adding
preferences and capabilities in the HTTP stack, preferring
instead to do this level of media queries: active content
that conditionally queries the environment.

At a minimum, W3C needs to adopt a consistent structure
and vocabulary coordinated between Media Queries and
Device Independence, and to coordinate with the updating of the
IETF documents to insure a consistent vocabulary and structure
is defined and Recommended in all contexts.

Franklin:
Perhaps I am misreading Larry's note, but it sounds to
me like he is suggesting that CC/PP should go away and
the Media Query crew should coordinate their work 
with Device Independence and the IETF (and presumably, 
OMA, 3GPP, etc.). But unless I misunderstand the Media
Query spec, I think their work complements CC/PP rather
than replaces it. CC/PP sends hints to
the origin server, and Media Queries are sent by the
origin server to the client to facilitate rendering.

The only real issue I see is defining a common vocabulary 
used by Media Queries and CC/PP. Since Media Queries are 
constrained to be backwards compatible
with HTML4 and we are constrained by UAProf I am sure
there will be some problems. "color" is an obvious problem
but this is really a CONNEG vs Media Queries issue. 
On the other hand, it might
be worth looking at their vocabulary and trying to
decide if there is a reasonable proposal for merging.

Does anyone think this is worth the trouble?

Roger Gimson:
FYI, the Device Independence WG has a work item in its charter:
http://www.w3.org/2002/06/w3c-di-wg-charter-20020612.html#delcon-coredev
to look specifically at defining a set of core device attributes with 
mappings onto those of CONNEG, CC/PP, Media Queries etc. As you point 
out, there may be valid reasons for there being syntactic differences. 
However, these could be handled by software. The problem, especially for 
authors of adaptive content, is that the semantics of the attributes may 
be under-defined or inconsistent.

Graham:
I'm still hopeful that we will define (in the IETF) a mechanism that can be 
used to embed CONNEG feature vocabularies in URI space, via URNs.  One key 
registry proposal is currently in IESG review:

- http://search.ietf.org/internet-drafts/draft-mealling-iana-urn-03.txt

I have also drafted a registration document to use this to render CONNEG 
feature tags as URIs:

- http://www.ninebynine.org/IETF/URNs/draft-klyne-urn-ietf-conneg.html

The internet draft has expired, but a copy is available at the above 
address.  I plan to reissue this if and when I see progress on the other one.

If these were in place, it may be appropriate to rework the non-normative 
appendix C.  Currently, lacking a defined syntactical specification to draw 
upon, that appendix is trying to prevent "semantic drift" for some common 
features/attributes.  That's surely not ideal.  Maybe it would be better to 
replace this appendix with a work-in-progress report referencing the drafts 
cited above?  That too seems rather unsatisfactory.

From CR telecon:
It was decided that the example client schema already demonstrates
how to use the CONNEG vocabulary in CC/PP. Future work by the
device independence working group will address the current
proliferation of vocabularies for describing device capabilities.

This is the same issue as 160. 

Venu Vasudevan http://lists.w3.org/Archives/Public/www-mobile/2001Apr/0010.html

Include transcoding proxy capability descriptions 4 April 2001
Issue 144:
Title: Include transcoding proxy capability descriptions
Class: Minor
Status:Dissent Overruled
Subject:
It is also appropriate for this work to include transcoding proxy capability 
descriptions, as they are part of the service chain between client and content
server. However, different people are defining this box in different ways ( even 
within the IETF there is Middlebox, Webi, OPES and ICAP), you need to make some
statement about what kind of box architecture you will be compatible with. On a 
related note: It is not always the case that you want the proxy capability to be 
advertised to the origin server. What if the CC/PP client wants to provision a 
proxy to remove advertisements, but does not want to inform the content provider
of his intent. Let's say that these proxies aren't free and start billing you for 
services. I don't think you want to trust the content provider to optimize the 
proxy provisioning for minimum cost. (S)he is going to focus on how to make
their job easier, i.e serve you the content as easily as possible. This may be 
incompatible with cost minimization. The proxy proposals in the IETF, notably 
OPES (Open Pluggable Edge Services), are beginning to define their own
profile vocabulary. Some coordination in that space is needed. 
The self-imposed restriction to transcoding proxies seems unnecessary. It would 
seem that you want caching proxies or NAT related proxies to also forward their 
profiles to the origin server.
Action Class:Disagree
WG Action:
The current framework is very extensible if new requirements 
are identified. A lot depends on the vocab. Add additional explanation about why proxy 
profile differs from the proxy component.

Venu Vasudevan:
> I parsed out two answers to the issue from the pointers you sent me. First,
> that this issue might be out of scope until the committee was rechartered.
> Second, that the CC/PP framework was flexible enough to handle any middlebox
> proposal once the requirements were known.

> If so, I am fine with the first and disagree with the second. The CC/PP
> framework is equally flexible to do things that are inconsistent with current
> OPES et al. directions. I view this not as flexibility, but as under-specification.
> 
> cheers VV

Graham Klyne:
> I think this comment is way off the mark as far as CC/PP is concerned.

> (a) CC/PP is specifically about describing capabilities and preferences, 
> not architectural attributes like caching, etc., so it's completely 
> inappropriate for caching proxies non-capability-affecting systems to 
> participate in CC/PP.  (I don't know what a "NAT related proxy" is.)

> (b) Nothing in CC/PP says it's restricted to transcoding proxies.  In 
> particular, content filters are also covered.  But as noted above, CC/PP is 
> not scoped to cover intermediaries that don't affect deliverable content in 
> some way.

> (c) IETF OPES WG isn't out of the requirements phase yet.  (I was at the 
> OPES WG meeting at the IETF this week.)  When they do, the profile will be 
> about defining rules for intercepting and passing content to OPES service, 
> a function that faces a completely different direction than CC/PP.

> (d) IETF middlebox is about systems that operate at the network level, and 
> don't affect content, so are completely transparent to CC/PP and content 
> adaptation issues.

> (e) there is no WEBI working group in the IETF (check out 
> http://www.ietf.org/html.charters/wg-dir.html)

> (f) there is no ICAP working group in the IETF (check out 
> http://www.ietf.org/html.charters/wg-dir.html)  ICAP has been requested for 
> informational RFC publication (similar status to a W3C NOTE).  The OPES 
> group has been asked to evaluate ICAP, but it currently has no official 
> IETF status.

> (g) box is irrelevant CC/PP:  all that counts is observable affects on the 
> kind of content that a content provider can usefully send to a content 
> consumer.

> (h) I agree that conversion capability is not always advertised to the 
> server.  This is up to the intermediary concerned:  CC/PP nowhere requires 
> that proxies advertise their capabilities.  If a client uses a proxy, then 
> the choice to do so would take into account whether or not the proxy 
> advertises its content adaptation capabilities to the server.  (This isn't 
> quite so clear-cut in the case of push content delivery, but in that case 
> the capability information would have to come by some different means than 
> the request path, so the content receiver should have some other way to 
> control the advertised capabilities.)

> I could go on, but I'd be repeating myself.

> Short answer:  I don't recognize any of these vague, handwaving claims of 
> inadequacy in CC/PP.  I think the complainant should provide at least one 
> concrete example (test case) of something that CC/PP can't do that it 
> clearly should be able to do.

> Maybe using the term "middlebox" in our original response wasn't helpful, 
> since that means more than just content handling proxies to network and 
> protocol people.  I believe that CC/PP is capable of describing 
> capabilities to a content provider as affected by most (if not all) 
> transmission-path components.  Components that don't modify or block 
> content don't affect capabilities, so there's nothing to do.  Components 
> that do affect content are, I think, covered.  (Of course there may be 
> specific cases that have ben overlooked, but nobody's offered any as yet.)

Franklin Reynolds:
> I am not sure how to respond to this. I view the strategy as flexible
> via intentional under-specification. The author seems to wish for
> explicit details for how specific middlebox proposals will be
> supported. I am not convinced the current spec should be changed, but
> if any of these proposals are mature enough, perhaps a separate
> document is warranted?

Mark Butler:
> Yes, but VV disagrees with this and I also disagree. I don't
> believe that under specification leads to flexibility. It leads to
> lack of interoperability. 

Franklin Reynolds:
> But is there specific issue we need to address? Is there some specific 
> middlebox specification that we need to deal with?

This issue is classed as minor, so Dissent Overruled. 
Discussion URLS:
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002AprJun/0070.html

Lalitha Surayanarayana http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001JanMar/0056.html

Improve explanation to be more clear 5 March 2001
Issue 145:
Title: Improve explanation to be more clear
Class: Editorial
Status:Request Approved
Subject:
E.2 "Although its RDF schema used is more restrictive in terms of classes and property

usage that UAPROF, the design of CC/PP is backwards compatible.
" Perhaps some typo? What are we trying to say?
Action Class:Fix
WG Action:
No details
Issue 146:
Title: Improve explanation to be more clear
Class: Major
Status:Request Approved
Subject:
.1.2 Complex CC/PP attribute data states:
"In addition to the simple values described above, a CC/PP attribute may have a 
complex value expressed in the form of a resource with its own collection of RDF 
properties and associated values. Specific data types represented in this way are:
Set of values 4.1.2.1 Set of values
A set consists of zero, one or more values, all different and whose order is not 
significant. "

What about the use of other RDF containersfor values whose order is indeed significant?
specifically rdf:Seq. Please note that not including this as a valid set type currently 
BREAKS compatibility with UAProf
Action Class:Fix
WG Action:
Add section 4.1.2.2, "Sequence of values".
Philipp Hoschka: 
> don't see any change in document - can't judge whether this is important or not.

Lalitha Surayanarayana:
> I agree.
> But I am not clear on the comment in red though "Comment: [Status: Request
> not Approved (?) /No response from Requester] @@ PH: don't see any change in
> document - can't judge whether this is important or not"
> 1. Was I supposed to do anything on this that I might have not before (must
> have fallen through the cracks or deluge of emails :-( )
> 2. In response to Phillip's comment, I do note section 4.1.2.2 in the
> document.

Mark Butler:
> I think we can regard this issue as satisfied. 

Martin Duerst http://lists.w3.org/Archives/Public/www-mobile/2001Apr/0012.html

I18N issues 9 April 2001
Issue 147:
Title: I18N issues
Class: Major
Status:Agreed by Requester
Subject:
Correction of xml:lang handling 
Further discussion 
Action Class:Fix
WG Action:
we agree to make it so. Change em to en
Discussion URLS:
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001JulSep/0025.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001JulSep/0026.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001JulSep/0035.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001JulSep/0035.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001OctDec/0003.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001OctDec/0004.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001OctDec/0005.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001OctDec/0006.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001OctDec/0007.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001OctDec/0008.html
http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001OctDec/0018.html

Renato Ianelia http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001JanMar/0066.html

Editorial change 19 March 2001
Issue 148:
Title: Editorial change
Class: Editorial
Status:Request Approved
Subject:
Editorial changes
Action Class:Fix
WG Action:
No details

Toni Penttinen http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2001JanMar/0003.html

Editorial Changes 5 Jan 2001
Issue 149:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
Editorial changes
Action Class:Fix
WG Action:
No details
Issue 150:
Title: Editorial Changes
Class: Editorial
Status:Request Approved
Subject:
Editorial changes
Action Class:Fix
WG Action:
No details

Mark H. Butler http://lists.w3.org/Archives/Member/w3c-ccpp-wg/2002JulSep/0003.html

Why does CC/PP use the XML serialisation of RDF? 01 July 2002
Issue 151:
Title: Why does CC/PP use the XML serialisation of RDF?
Class: Major
Status:Dissent Overruled
Subject:
CC/PP uses the XML serialisation of RDF. I believe this is unnecessary 
and leads to profiles that are unnecessarily long, complicated and difficult 
to edit by hand. I believe:
i) Ideally CC/PP should adopt a pure XML serialisation
ii) if i) is not possible, CC/PP should adopt a "canonical" serialisation 
i.e. a tightly constrained serialisation that can be processed by RDF processors 
or by XML processors. Such an approach has been adopted by other working groups 
such as the EARL group.

For an example of the problem compare this profile in Figure 2-2.b in the 
CC/PP WD

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2002/05/20-ccpp#"
         xmlns:ex="http://www.example.com/schema#">
  <rdf:Description
      rdf:about="http://www.example.com/schema#MyProfile">
    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/schema#TerminalHardware">
        <rdf:type
            rdf:resource="http://www.example.com/schema#HardwarePlatform" />
        <ex:display>320x200</ex:display>
      </rdf:Description>
    </ccpp:component>
    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/schema#TerminalSoftware">
        <rdf:type
            rdf:resource="http://www.example.com/schema#SoftwarePlatform" />
        <ex:name>EPOC</ex:name>
        <ex:version>2.0</ex:version>
        <ex:vendor>Symbian</ex:vendor>
      </rdf:Description>
    </ccpp:component>
    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/schema#TerminalBrowser">
        <rdf:type
            rdf:resource="http://www.example.com/schema#BrowserUA" />
        <ex:name>Mozilla</ex:name>
        <ex:version>5.0</ex:version>
        <ex:vendor>Symbian</ex:vendor>
        <ex:htmlVersionsSupported>
          <rdf:Bag>
            <rdf:li>3.0</rdf:li>
            <rdf:li>4.0</rdf:li>
          </rdf:Bag>
        </ex:htmlVersionsSupported>
      </rdf:Description>
    </ccpp:component>
  </rdf:Description>
</rdf:RDF>

with the equivalent profile in XML

<?xml version="1.0"?>
<prf:Profile xmlns:prf="http://www.example.com/schema#">
    <prf:HardwarePlatfom>
        <prf:displayWidth>320x200</prf:displayWidth>
        <prf:displayHeight>320x200</prf:displayHeight>
    </prf:HardwarePlatform>
    <prf:SoftwarePlatform>
        <prf:name>EPOC</prf:name>
        <prf:version>2.0</prf:version>
        <prf:vendor>Symbian</prf:vendor>
    </prf:SoftwarePlatform>
    <prf:BrowserUA>
        <prf:name>Mozilla</prf:name>
        <prf:version>5.0</prf:version>
        <prf:vendor>Symbian</prf:vendor>
        <prf:htmlVersionsSupported>
            <prf:li>3.0</prf:li>
            <prf:li>4.0</prf:li>
        </prf:htmlVersionsSupported>
    </prf:BrowserUA>
</prf:Profile>

Representing profiles in pure XML would have a number of advantages:
1. The profile is shorter.
2. It is easier to understand. At present, CC/PP profiles are generally 
entered directly in text editor rather than in a custom tool. Using XML 
would also mean that the profile author would not need to understand RDF.
2. Existing validation tools can be used with such profiles, such as 
DTDs, XML Schema, Relax-NG, Schematron etc. It is possible to perform 
validation on RDF, but this is not common practice and some people using 
RDF regard it as violating one of the tenets of RDF. Validation is 
particularly important as profile authors enter profiles directly.
3. It is possible to process the profile with existing APIs such as DOM.
Note that representing that a pure XML serialisation would not mean you 
cannot use RDF; it is still possible to treat the profile as RDF by 
using an XML to RDF mapping.
Action Class:Disagree
WG Action:
Kaz Kitagawa: CC/PP is not for human, it is for machine. And RDF allows 
shorter description (but I don't like that).  So Issue 1,2 doesn't 
matter. Issue 3 is out of our scope.  Mark, you are creating Java API 
for CC/PP under JCP.

Franklin Reynolds: I sympathize with the complaints about the use of 
RDF, but I think the benefits of moving to XML are dwarfed by the 
disadvantages of being incompatible with UAPROF. I am opposed to 
this - unless the UAPROF people also converted to XML.

In fact, if we throw out RDF and compatibility with UAPROF, I think 
we should reconsider the CONNEG language. It is much more 
concise and readable than anything based on XML.

I am not sure what you mean when you talk about backwards 
compatibility. It sounds like you are suggesting that a profile
could be written in XML without RDF and still be backwards compatible.
I don't see how would be true.

I am sure we can get a cleaner design by starting over. I am sure
we can get a cleaner design by avoiding XML. (By the way, I thought
CONNEG had a feature comparable to XML namespaces - Graham?) But 
unless we can convince the OMA (the WAP Forum changed into OMA last 
week.) to adopt a new design, I think backwards compatibility with 
UAProf is more important than a new, cleaner design.

I have to admit that I am not convinced we need to simplify 
CC/PP profiles. On the other hand, simplicity is a good thing. I
am definitely in favor of simplifying CC/PP if we can do it
without breaking anything (or at least, anything important).

I agree that using XML without RDF would be a simplification, but
I think it would break something important - UAProf compatibility. 
I think it is worth a little effort to consider if we can specify
a useful subset of RDF, but it could be that any subset of RDF 
would also break UAProf compatibility.

Graham Klyne: .. As far as I can tell, that *is* a valid XML 
serialization of RDF, with the exception of the html versions 
supported, which could be presented as:

 <prf:htmlVersionsSupported>
  <ccpp:set>
   <prf:li>3.0</prf:li>
   <prf:li>4.0</prf:li>
  </ccpp:set>
 </prf:htmlVersionsSupported>

So I submit that any space savings would be illusory.

>- CC/PP profiles could be processed with existing XML tools, e.g. XML parsers.

.. And they would be inaccessible to the growing range of RDF tools.

>- CC/PP profiles would be much easier to use in XSLT as XSLT is a standard
>approach to content adaptation.

.. This seems to me to be non sequitur;  CC/PP describes the capabilities 
of a client but I don't see how it is directly involved in the transformation.

>- Profile authors would not be required to understand RDF.

.. I think this could be achieved without abandoning RDF.

>- Existing validation tools such as XML Schema could be used to validate
>that profiles conform to specific vocabularies.

.. and the use of such tools would obstruct the deployment of new CC/PP 
vocabularies (one of the strengths of using RDF).  I think it is quite 
reasonable and proper to define a notion of validity for CC/PP in RDF (and 
I understand some of your colleagues are working on just this).  I, too, am 
working on software which will carry a notion of validity in RDF without 
losing the advantages.

>- Note this does not mean that CC/PP can not be treated as RDF. It should
>still be possible to process CC/PP as RDF by defining a way of mapping the
>XML serialisation of CC/PP on to RDF.

.. I think mapping is bad news, that it is a barrier to deployment.  We 
encountered this problem when discussing integration of CC/PP with P3P, 
precisely because P3P did what you are now proposing to do for CC/PP;  i.e. 
give up on RDF.  And the P3P group defined a "mapping" to RDF, but it 
turned out to be a "lossy".  The benefits of using RDF are not most 
apparent in a single application (though there are some).

Mark:
I would like to see this changed to "Hold until next version", then I will
mark it "agreed by requester". 

From CR Telecon: 
It was decided that the CC/PP working group did the right thing by using 
RDF because in the future everything would be represented by RDF. 

It was also decided that CC/PP should not create its own non-standard "simplified" 
version of the XML serialisation of RDF, but if a general purpose simplified 
version of the XML serialisation of RDF was proposed by the W3C then
CC/PP could adopt that. 

RESOLVED: Dissent Overruled with sympathy.
Issue 152:
Title: CC/PP should discourage the use of composite literals
Class: Fairly Major
Status:Request Approved
Subject:
The CC/PP WD uses composite literal values i.e. multiple values in a 
single literal separated by ASCII characters. I believe this is an 
incorrect use of XML and RDF as it means that

i) there must be an additional parsing stage to separate the values
ii) there is no standard way to refer to the individual values e.g. 
distinguish the second value from the first. For example how do you 
distinguish these two values?
<ex:display>320x200</ex:display>

iii) as a result of ii), it difficult to apply standard operators to 
the values e.g. greater than, less than etc. This means that CC/PP 
processors may need to create non-standard operators to cope with 
composite literals.

I think it would be better to remove examples of composite literals 
from the WD. For example in Figure 2-2.b, you use characters to 
separate multiple values in a single literal field e.g.
<ex:display>320x200</ex:display>
Wouldn't it be better to use
<ex:displayWidth>320</ex:displayWidth>
<ex:displayHeight>200</ex:displayHeight>

I know UAProf uses composite literals, and CC/PP is meant to be 
backward compatible with UAProf so CC/PP can't say you can't have 
composite literals, but I believe CC/PP should strongly encourage 
vocabulary authors not to use them and not use them in any example 
profiles as examples of good practice as they are clearly not good 
practice.

Unfortunately UAProf has decided to widely adopt composite literals. 
For example current UAProf devices declare properties like this

<prf:SecuritySupport>WTLS class 1/2/3/signText</prf:SecuritySupport>

when they should be declared like this

<prf:SecuritySupport>
  <rdf:Bag>
   <rdf:li>WTLS class 1</rdf:li>
   <rdf:li>WTLS class 2</rdf:li>
   <rdf:li>WTLS class 3</rdf:li>
   <rdf:li>signText</rdf:li>
 </rdf:Bag>
</prf:SecuritySupport>

which makes life very difficult for the processor!
            
Action Class:Fix
WG Action:
Kaz Kitagawa: I think eventually CC/PP with type system would solve 
this problem. At this time, it is hard to do this, but not impossible.

If it is easier to read, we had better to use this example.

Franklin Reynolds: I agree that composite values is a bad style, 
but I am not convinced composite values should be made illegal. 
There are serious questions regarding backwards compatibility and 
the value of enforcing such a restriction.

Graham Klyne: composite literals.  I don't think this is a CC/PP 
problem.  Indeed,  CC/PP discourages such use, but UAPROF has 
some attribute vocabulary that uses them.  I agree that composite 
literals are best avoided.

Conclusion: Make minor editorial change to document to remove 
examples using composite literals.
Issue 153:
Title: Error in Figure 2-2.B
Class: Fairly Major
Status:Request Approved
Subject:
In Figure 2-2.b, why do the about's point to the schema? If 
they do this, then they say that the following properties apply to all 
instances of that schema. Surely the following properties only apply to 
this particular profile instance so they should point to the base of 
the document accompanied by a local name i.e. the correct way of doing 
it is as follows:

<rdf:Description
          rdf:about="http://www.example.com/myProfile#TerminalBrowser">
        <rdf:type
            rdf:resource="http://www.example.com/schema#BrowserUA" />
        <ex:name>Mozilla</ex:name>
        <ex:version>5.0</ex:version>
        <ex:vendor>Symbian</ex:vendor>
        <ex:htmlVersionsSupported>
Action Class:Fix
WG Action:
Franklin Reynolds: It seems to me that we debated this topic on and off for years. 
Is this a little detail in the spec?

Graham Klyne: abouts point to schema.  I disagree that the about= attributes 
reference the schema.  Rather, they reference relative URIs which strictly 
must be resolved relative to the containing document.  I would agree that 
it would probably style in the examples given to use absolute URIs along 
the lines of http://www.example.com/myProfile#TerminalHardware.  (The 
intent of this was to exemplify the structure rather the detail, but since 
the question arises I guess it's best fixed.)

Conclusion: make editorial change.
Issue 154:
Title: If we are to write CC/PP in RDF, we should use abbreviations such as typedNodes wherever possible
Class: Minor
Status:Agreed by Requester
Subject:
If CC/PP must use the XML serialisation of RDF, then it should use 
typedNodes. In Figure 2-2.b, if it is absolutely necessary to use the 
XML serialisation of RDF for CC/PP, wouldn't it be easier to use the 
typedNode construction e.g.

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2002/05/20-ccpp#"
         xmlns:ex="http://www.example.com/schema#">
  <rdf:Description
      rdf:about="http://www.example.com/schema#MyProfile">
    <ccpp:component>
      <ex:HardwarePlatform rdf:about="TerminalHardware">
        <ex:display>320x200</ex:display>
      </ex:HardwarePlatform>
    </ccpp:component>
    <ccpp:component>
      <ex:SoftwarePlatform rdf:about="TerminalSoftware">
        <ex:name>EPOC</ex:name>
        <ex:version>2.0</ex:version>
        <ex:vendor>Symbian</ex:vendor>
      </ex:SoftwarePlatform>
    </ccpp:component>
    <ccpp:component>
      <ex:BrowserUA rdf:about="TerminalBrowser">
        <ex:name>Mozilla</ex:name>
        <ex:version>5.0</ex:version>
        <ex:vendor>Symbian</ex:vendor>
        <ex:htmlVersionsSupported>
          <rdf:Bag>
            <rdf:li>3.0</rdf:li>
            <rdf:li>4.0</rdf:li>
          </rdf:Bag>
        </ex:htmlVersionsSupported>
      </ex:BrowserUA>
    </ccpp:component>
  </rdf:Description>
</rdf:RDF>

These features are in RDF for a reason, why not use them?
Action Class:Disagree
WG Action:
Franklin Reynolds: Maybe, but does it really matter?
I guess I am willing to bother with this sort of detail if 
we decide to make a major effort to streamline the syntax. 
(For example, if we were to try to eliminate redundant 
RDF encodings to simply CC/PP parsing via XML tools.)

I do not have any serious concrete suggestions. I think it might be 
worth a little effort to consider subsetting RDF. For example. we 
do not need to use the abbreviated form, aboutEach or other 
constructs that permit multiple serializations of a single graph. 

I think you are right about our different viewpoints. I don't think
human readability is important. 

(Pardon me while I rant for a moment,
but if I did think human readability was important, I certainly would 
not suggest we use XML. It has managed to combine the worst features 
of COBOL and Lisp. It is extremely verbose, it provides insufficient
easily recognizable landmarks to aid understanding and it has 
obscure, subtle and infrequently used rules. If we add tools like
XPath, XSLT and XQuery then we get to add the complexity sins of 
Common Lisp - except much worse...)

Graham Klyne: use RDF typedNodes.  This is a case of restricting 
profile format to specified RDF syntax features, which the original 
WG discussed at some length.  Personally, I'm not vehemently in 
favour of or opposed to this, as long as it remains valid RDF.  
I also agree with Franklin's comments.

Franklin Reynolds:
> I think as long as both forms generate the same graph, this is a
> trivial editorial issue. I don't have any objection to someone making
> the suggested changes to the RDF examples in the document. My only
> point is that it should not be characterized as a "fairly major"
> issue.

Mark:
I don't think we can reach agreement on this, so I think we need to keep it
as "dissent". Note there is general feeling in UAProf and JSR that CC/PP
should  define a simplified canonical format for the XML serialisation of
RDF that is easier to process with XML processors.
Issue 155:
Title: CC/PP is less powerful than existing XML profile formats
Class: Major
Status:Dissent Overruled
Subject:
Many existing standards perform some form of capability description / 
capability negotiation e.g. UPnP, SyncML, the Wireless Village 
Initiative, etc. See
http://www.syncml.org/
http://www.wireless-village.org/
Most of these standards use an XML format for storing capability 
information. Generally the XML profiles used by the standards consist 
of two types of elements:
i) descriptive elements e.g. profile properties such as the screen 
width in pixels.
ii) structural elements. Typically the structural elements have 
two roles: a) to group related descriptive elements together b) to 
distinguish the context of a particular descriptive element when the 
profile contains multiple instances of that element.

To illustrate this, consider two sample profiles from two typical 
standards (note I've abbreviated the profiles for brevity). This is 
a profile from the Wireless village initiative:

<WV-CSP-Message xmlns="http://www.wireless-village.org/CSP1.0">
  <Session>
    <Transaction>
      <TransactionContent xmlns="http://www.wireless-village.org/TRC1.0">
      <ClientCapability-Request>
      <CapabilityList>
        <ClientType>MOBILE_PHONE</ClientType>
        <InitialDeliveryMethod>P</InitialDeliveryMethod>
        <AcceptedContentType>text/plain; charset=us-ascii</AcceptedContentType>
        <AcceptedContentType>application/x-sms</AcceptedContentType>
        <AcceptedContentType>text/x-vCard; charset=us-ascii</AcceptedContentType>
        <AcceptedContentType>text/x-vCalendar; charset=us-ascii</AcceptedContentType>
        <AcceptedTransferEncoding>BASE64</AcceptedTransferEncoding>
        <AcceptedContentLength>32767</AcceptedContentLength>
        <MultiTrans>1</MultiTrans>
        <ParserSize>32767</ParserSize>
        <UDPPort>91</UDPPort>
        <ServerPollMin>2</ServerPollMin>
      </CapabilityList>
      </ClientCapability-Request>
      </TransactionContent>
    </Transaction>
  </Session>
</WV-CSP-Message>

As you can see, the WVI profile uses several layers of structural 
elements e.g. Session, Transaction, ClientCapability-Request and 
CapabilityList. In CC/PP the only type of structural elements available are 
components. Therefore the WVI profile uses a much richer set of structural 
elements because it can have multiple layers of structural elements. CC/PP is 
being proposed as a general capability description format, it is severally 
restricted compared to the type of profiles people are currently using in XML. 
I believe CC/PP should offer arbitrarily deep nesting of structural elements not 
just a single level of components.

Also in the WVI example, you could argue that the structural elements were 
unnecessary. This is also true for components in CC/PP as in CC/PP it is not 
mandatory for people to type components. This means that many UAProf profiles 
define components in the following way:

<rdf:Description
      rdf:about="http://www.example.com/schema#MyProfile">
     <rdf:Description
          rdf:about="#TerminalHardware">
        <ex:display>320x200</ex:display>
      </ex:HardwarePlatform>
    </ccpp:component>

However, if you are using RDF correctly, it is not possible to determine the 
component type, as TerminalHardware is a local name and so is not associated 
with a schema. I refer to this as a component being "untyped". If a component 
is untyped, the only way of determining a component is by examining the 
properties in it and inferring the parent component from the schema. In my 
opinion, having a structural element where we cannot guarantee to determine 
the name if we are following a strict interpretation of RDF is of little use. 
Therefore I think it would be better if CC/PP adopted a totally flexible like 
SyncML or WVI where it was guaranteed that the RDF processor could determine 
the name of the structural element without having to refer to the schema.

Secondly consider this profile in SyncML:

<DevInf xmlns='syncml:devinf'>
  <VerDTD>1.1</VerDTD>
  <Man>Big Factory, Ltd.</Man>
  <Mod>4119</Mod>
  <OEM>Jane's phones</OEM>
  <FwV>2.0e</FwV>
  <SwV>2.0</SwV>
  <HwV>1.22I</HwV>
  <DevID>1218182THD000001-2</DevID>
  <DevTyp>phone</DevTyp>
  <DataStore>
    <SourceRef>./contacts</SourceRef>
    <DisplayName>Phonebook</DisplayName>
    <MaxGUIDSize>32</MaxGUIDSize>
    <Rx-Pref>
      <CTType>text/vcard</CTType>
     <VerCT>3.0</VerCT>
    </Rx-Pref>
    <Tx-Pref>
      <CTType>text/vcard</CTType>
      <VerCT>3.0</VerCT>
    </Tx-Pref>
  </DataStore>
</DevInf>

In the SyncML profile shown above, the structural elements are used in a 
slightly different way i.e. to disambiguate context. For example in the 
profile there are two instances of a MIME type specification indicated by 
the CTType element. The first instance is the RX-Pref context (Receiving) 
and is associated with a version number 3.0. The second instance is in the 
Tx-Pref context and is associated with a version number. When processing the 
profile, SyncML needs to know the context in order to know which value to 
use. Therefore there are situations in profiles where structural elements 
are necessary in order to disambiguate. I think this functionality is 
necessary in CC/PP.

I think it is important to compare CC/PP with other standards, because it 
is not yet being adopted as an application independent approach to 
capability description. For example why didn't WVI use UAProf - nearly all 
the information they needed was already in the UAProf profile? One possible 
cause of this is that CC/PP is less flexible than using XML for storing 
profiles.
Action Class:Disagree
WG Action:
Kaz Kitagawa: No.  XML is simple labeling which cannot present 
relationships. I think simple labeling is not enough.  Also, CC/PP is not 
only to present device capabilities, also other device informations. 

Graham Klyne: CC/PP less powerful?  In its bare form, maybe.  But through 
RDF extensibility, I think it can be a basis for considerably greater 
expressive power.  I think that trying to shoehorn CC/PP into predefined 
XML structures will do more to restrict its eventual expressive power.

Franklin Reynolds:
> It seems to me that CC/PP only has a couple of structural elements. I
> can't think of any problem with allowing components and other
> structural elements to nest. 

> The schema would have to be changed, but I think this would not be a 
> big problem. On the other hand, I am not sure that nesting components 
> solves any interesting problems (consequently, I am not convinced we 
> should do anything).
> 
> CC/PP does not define the sort of things (transactions, etc.) that
> warrant the other structural elements. Application specific structure
> and structured data can be provided by using an application specific
> vocabulary. These can nest. Unlike SyncML, CC/PP attempts to avoid
> dependency or specific knowledge of applications or protocols that use
> CC/PP.
> 
> In the absence of a concrete example of why components need to nest or
> why CC/PP needs more structural elements (and a list of those elements) 
> I don't think it is worth the effort to change the current spec. If there 
> is a second version of the specification, it would probably be worth 
> reviewing SYNCML and other specifications to see if there is something 
> we want to add to CC/PP.  But at this point, I don't see a clear problem 
> that needs to be solved.

Mark Butler: 
> I disagree and I think I provide plenty of examples. 
> For another example, UAProf wants to define new properties for
> Java libraries e.g.
>
> >prf:javalib>a.long.classpath/2.22>prf:javalib>
>
> i.e. using composite literals. As I've said before, I think we should
> avoid using composite literals and use structural elements instead e.g.
> >prf:javalib>
>    >prf:classpath>a.long.classpath>/prf:classpath>
>    >prf:versionNumber>2.22>/prf:versionNumber>
> >/prf:javalib>

Franklin Reynolds:
>Composite literals may be bad style, but in this case the simple 
>alternative is to use two attributes instead of one.

>Even if multiple attributes is undesirable, I think a better 
>solution to this problem would be to define a structured type in 
>the application vocabulary. As far as I can tell, structured values 
>are not necessary if you can have long names. But I realise it is an 
>important coding style issue for some people. 

>We already have examples of structured types that use RDF Bags. 
>I cannot think of any reason CC/PP cannot support other structured 
>types. I think the UAProf WG wanted to avoid structured types 
>because of the complexity it caused when merging profiles, but CC/PP 
>only has to deal with Defaults. We would probably need to revisit the 
>default overriding language in the spec just to make sure it was 
>unambiguous.

Mark:
I would like to see this changed to "Hold until next version", then I will
mark it "agreed by requester".

I've merged this issue with Issue 156. 
Issue 156:
Title: CC/PP represents structural elements in different ways
Class: Fairly Major
Status:Agreed by Requester
Subject:
Ideally, I think CC/PP should represent all structural elements in the 
same way. Currently CC/PP has the following structural elements: 
components, defaults, capability chaining and proxy behavior. However 
components are represented in quite a different way to the other 
structural elements e.g.

<ccpp:component>
   <rdf:Description
      rdf:about="http://www.device.com/profile#TerminalHardware">
     <rdf:type
       rdf:resource="http://www.example.com/schema#HardwarePlatform" />
     <ex:display>320x200</ex:display>
   </rdf:Description>
</ccpp:component>

i.e. the following RDF graph (please excuse ASCII art)

resource -ccpp:component-> #TerminalHardware -ex:display-> 320x20
                                  |
                               rdf:type
                                 |
              http://www.example.com/schema#HardwarePlatform

whereas defaults are represented like this

<ccpp:component>
   <rdf:Description
      rdf:about="http://www.example.com/schema#TerminalHardware">
      <rdf:type
         rdf:resource="http://www.example.com/schema#HardwarePlatform" />
      <ccpp:defaults
         rdf:resource="http://www.example.com/schema#HWDefault" />
         <ex:memory>32Mb</ex:memory>
      </ccpp:defaults>
   </rdf:Description>
</ccpp:component>

resource -ccpp:component -> #TerminalHardware -ccpp:defaults-> #HWDefault -ex:memory-> 32Mb
                                  |
                               rdf:type
                                 |
              http://www.example.com/schema#HardwarePlatform

I think it would be better just to use properties to denote structural 
elements e.g.

resource -ex:HardwarePlatform -> anon -ex:displayWidth-> 320

or

resource -ex:HardwarePlatform -> anon -ccpp:defaults-> anon -ex:displayWidth ->320

Also I think that strictly the intermediate resources should be 
anonymous. In fact the whole method of associating URLs with profiles needs 
some quite careful thought. A profile or set of profiles in a request, is 
associated with a particular instance of a device at a particular time / 
date. The time/date constraint is important as it is possible for the user 
to change a setting which will change the profile-diff. This makes it difficult 
to come up with an appropriate URL. Also I think CC/PP should identify the 
root node of a profile or set of profiles with a concrete resource, but where 
possible CC/PP should try to avoid giving names to intermediate resources. The 
point here is all these properties are properties of a particular instance of 
a device, but the additional structural elements indicate the properties have 
different contexts e.g. sometimes the property is a default value, sometimes 
it is from a proxy, etc and these contexts need to be labelled so the processor 
can chose the correct value. By adding intermediate resources, it looks like 
the properties are properties of another resource, not the device, which is 
confusing.
Action Class:Disagree
WG Action:
Kaz Kitagawa: Is this a serious problem ?

Graham Klyne: CC/PP represents structural elements in different ways.   
I think this is the same as 154, in a slightly different guise.

Franklin Reynolds: This issue has several issues tangled up in it.
 
a. I can no longer remember why there are component properties. Maybe
they were created by the UAProf WG? I am pretty sure that getting rid
of them breaks UAProf compatibility. I don't see a real problem with
the current structure, though I agree that getting rid of component
properties might be a good thing if we can get the UAProf people to
agree.

b. I agree that intermediate resources should tend to be anonymous,
though is more of a style issue rather than anything important. But at
one point, component resources had labels so they could be targets for
profile merging.

c. It is expected that different protocols will define different ways
to define profile URIs that are associated with specific messages or
transactions. We probably don't want to standardize this in the CC/PP
structure spec.

d. I don't really understand the comment about "adding intermediate
resources". I don't understand how this applies to the original
comment about component properties and anonymous resources.

Mark: 
This is the same issue as 154: I propose we merge these issues. 
Issue 157:
Title: Capability chaining by proxies
Class: Fairly Major
Status:Agreed by Requester
Subject:
In the WD, it is possible to specify proxy capabilities. The capability 
chaining method tries to duplicate functionality in the CC/PP protocol. I 
think this is unnecessary and should be avoided.
Action Class:Fix
WG Action:
Kaz Kitagawa: There may exist proxy chain in real internet.

Franklin Reynolds: Perhaps you are right and the proxy stuff 
should be removed from the current document and deferred to the 
protocol work. However, the last I heard, the device independence 
group was going to issue a Note, not a spec. Yet another CC/PP 
protocol Note might not be very useful. What would be the effect 
of removing the proxy support from the current document?

A case was made by representatives of middlebox vendors that corporate
network access policies might be implemented and enforced by middleboxes
(proxies). It was suggested that rather than  simply discarding the
content, the proxy might warn the server than types of content would be
discarded. The proxy would still discard the content, but at least the
server would have been warned.

This sort of content blocking functionality already exists in various 
firewalls.

Graham Klyne: proxy chaining.  This was a response to requirements on CC/PP, 
particularly trust-related requirements in the presence of active 
proxies.  If the requirement isn't there, then maybe it's superfluous.  The 
specification only requires use of these elements when proxies change the 
effective capabilities; e.g. by blocking certain capabilities or performing 
content adaptation.

Franklin Reynolds: 
"The capability chaining method tries to duplicate functionality in
the CC/PP protocol. I think this is unnecessary and should be avoided."

Since there is no CC/PP protocol specification, and dealing with
proxies was one of the requirements, the proxy chaining work in the
spec is probably warranted.

After the CR telecon, the WG agreed to make proxy chaining and proxy
behavior non-normative because i) the processing model is not fully
defined ii) currently available implementations do not implement
this. This resolves this issue.
Issue 158:
Title: Proxy issues: proxy behavior
Class: Major
Status:Agreed by Requester
Subject:
The capability matching / blocking / allowing is complex from an RDF 
point of view. If this is normative, then it needs further discussion a
bout how it should be done i.e. provide a processing model.

In the current CC/PP WD, a structural element called proxyBehavior is 
defined that can contain three structural elements, applicability, 
proxyAllow and proxyBlock. However it is not clear how these elements work. 
Specifically consider the following profile set represented using a 
context path view (See 
http://www-uk.hpl.hp.com/people/marbut/proposal/ccpp_proposal.html
for more details):

PropertyValue          ContextPath
[text/wml, image/wbmp]  Profile/ClientProfile/SoftwarePlatform/CcppAccept
Yes                     Profile/ClientProfile/HardwarePlatform/SoundOutputCapable
8                       Profile/ClientProfile/HardwarePlatform/BitsPerPixel
Yes                     Profile/ClientProfile/HardwarePlatform/ColorCapable
[text/wml]              Profile/ProxyProfile/Proxy-Behaviour/Applicability/SoftwarePlatform/CcppAccept
[text/html]             Profile/ProxyProfile/Proxy-Behaviour/ProxyAllow/SoftwarePlatform/CcppAccept
No                      Profile/ProxyProfile/Proxy-Behaviour/ProxyAllow/HardwarePlatform/SoundOutputCapable
2                       Profile/ProxyProfile/Proxy-Behaviour/ProxyAllow/HardwarePlatform/BitsPerPixel
[text/wml]              Profile/ProxyProfile/Proxy-Behaviour/ProxyBlock/SoftwarePlatform/CcppAccept
4                       Profile/ProxyProfile/Proxy-Behaviour/ProxyBlock/HardwarePlatform/BitsPerPixel
Yes                     Profile/ProxyProfile/Proxy-Behaviour/ProxyBlock/HardwarePlatform/ColorCapable

As you can see there are some potential problems here. For example 
it's fairly straight forward to resolve CcppAccept:
  CcppAccept = [text/html, image/wbmp]
there's only one possibility here so this works.

however it is not clear how to resolve SoundOutputCapable as there 
are two possible behaviors:
  SoundOutputCapable = Yes
  SoundOutputCapable = No
or it could just return
  SoundOutputCapable = No
Now obviously we know the second result is correct, but the problem 
is how does the CC/PP processor infer it in the absence of schema 
information, as there is a limitation in CC/PP that a processor must 
be able to process a profile in the absence of a vocabulary description 
(schema). If the processor has a schema for the vocabulary, it will 
know that SoundOutputCapable is a Boolean so it will treat it 
appropriately. However without a schema it is not possible to make 
that judgment.

BitsPerPixel could also return two values
 BitsPerPixel = 8
 BitsPerPixel = 2
or it could just return
 BitsPerPixel = 2
Again the second result is more correct, but in this case it is 
possible for the processor to infer this in the absence of schema 
information as the processor can determine if a property is simple 
as multi-valued properties are indicated by Seq's or Bag's.

Then for ColorCapable does this return
 ColorCapable = No
or does it return nothing? This is important because the 
adaptation algorithm might do something quite different if a 
device says it is not color capable compared to if it receives 
no information.

In summary, although proxy-allow and proxy-block work for Bags 
I suggest that their behavior is indeterminate for simple values. 
Therefore I'd like to suggest the whereas applicability can contain 
simple and multi-valued properties, proxy-allow and proxy-block 
should only contain statements about properties that are multi-valued.

(An aside: furthermore, as I mention in a later issue, it's not really 
clear where resolution should occur. Does the processor do it? Does the 
application do it? If the processor does it, can the application get 
an unresolved version of the profile if it needs it e.g. to guard 
against malicious proxies?)
Action Class:Fix
WG Action:
Kaz Kitagawa:Isn't 
http://www.w3.org/TR/2000/WD-CCPP-ra-20000721/
enough ?

Graham Klyne: proxy behaviours.  I think the specification is about as 
simple as one can get and still convey information to the origin server 
about the effects of existing proxies (blocking, conversion) in the 
client's access path to the server.  As for a processing model, I 
think that is precisely something that should be avoided by *this* 
specification:  CC/PP is a descriptive format.  I believe that any 
processing model belongs in the protocol document (not part of the 
group's original charter).  Keeping the descriptive semantics 
separate from the processing (protocol) semantics is, I think, a mark 
of clean architectural design.

I think there's a fundamental architectural flaw in the attempt to map 
proxy descriptions into a static XPath-like structure.  Proxies in a chain, 
by their nature, have a dynamic relationship to the request.  In general, 
any two requests may have different proxy-chaining structures, different 
numbers of proxies, different orderings, different effects on capabilities 
from each proxy, etc.  The XPath-like description suggested is static in 
nature, and is not a good fit for describing dynamic proxy relationships.

I think the current design provides a perfectly good deterministic 
interpretation of proxy behaviour chains.

Franklin Reynolds:
I agree with Graham that the processing model for CC/PP should be
separate from the abstract data model.

I believe the spec is correct if it unambiguously describes how to
interpret a chain of proxy profiles. The problem with the "context
path view" is that it does not appear preserve the chain resolution
rules (for example, the ordinality rules) described in the document. 

I don't understand why the author believes proxy chains have
indeterminate behavior for simple values unless the point is that it
is possible to construct ambiguous profiles associated with a single
proxy (for example a profile that states "Sound" is both ON and OFF).

It is possible to construct those sorts of profiles, but is that a bug
or an example of a "sharp tool"?

Mark Butler:
It's not the context path view that does not preserve chain resolution
rules, thats a property of using RDF. If you need to preserve chain
resolution (as you do in UAProf) you shouldn't be using RDF. 

As for how proxies produce indeterminate behavior for simple values, 
I believe it does not make sense to apply allow and block sections to 
simple (i.e. single valued properties) as there are situations where 
this will result in a property being removed from a profile during 
resolution. Removing information from a CC/PP profile is a bad idea 
as an origin server may interpret a missing value differently to a 
property changing value. For example consider the two possible outcomes 
of a block section:
- The value of a property and the block match in which case the property 
does not return any value. 
- The value of a property and the block do not match in which case the 
property returns its existing value. 

A similar problem arises with allow sections:
- The value of the property and the allow value match in which case 
the property returns its existing value. 
- The value of the property and the allow do not match in which case 
the property returns no values. 

Therefore instead of blocks and allows, it makes more sense to use 
overrides within proxy-behavior sections if you are working with
simple values. 

Franklin Reynolds:
Maybe you are right. I was concerned about how multiple proxy profiles
were represented. It seems to me that the separate context of each
proxy profile needs to be preserved in order to correctly process
multiple proxy profiles. In your example, 
the client profile and the proxy profile are merged into a single 
profile which made me a little nervous. However, I don't think there
is any problem as long as statements associated with each proxy profile
can be unambiguously identified.

As a separate question, why don't you differentiate between nodes and arcs
(resources and properties) within the elements of a context paths?

I think that resolution of the blocks and allows rules are deterministic,
given a specific user profile and collection of proxy profiles. I don't
understand what is indeterminate about your examples. The different
outcomes you describe seem to me to be predictable given the rules and
the different starting conditions.

On the other hand, after rereading section 3.2.2, it seems to me 
that the intended semantics of allow, blocks and applicability are
not as clear as I would like.

The question that came up is whether proxy-profiles are intended to 
explicitly describe the behavior of proxies or are they intended 
achieve this implicitly by modifying client profiles? The difference 
may not be obvious, so I will try to explain.

When reading example 3.2.2.3, it sounds like a proxy that blocks 
jpeg is telling a server that the proxy will discard jpeg content.
This would be a case of the proxy advertising its own behavior.

However, if the blocks statement is supposed to be interpreted as
modifying a client profile so that explicit support for jpeg has 
been removed, we end up with different behavior. This is because a
server might not assume a client does not support jpeg just because
jpeg support is not explicitly mentioned. 

Mark: 
I don't think we can reach agreement on this, so I think we need to keep it
as "dissent". 

Outcome: WG decides to mae proxy optional. 
Issue 159:
Title: Limits on CC/PP structure means CC/PP cannot cope with multimodal use cases
Class: Minor
Status:Agreed by Requester
Subject:
This is related to Issue 155, but it is a concrete use case for a 
situation where the current CC/PP WD is insufficient. Consider a 
user with two devices, a PDA and a cellphone. The two devices can 
be used together to give a multimodal interface to a webserver via 
an aggregating proxy. This proxy aggregates the CC/PP profiles from 
each device. One of the devices, the PDA, is capable of being used 
in either landscape or portrait mode. The web server can instruct 
the PDA which format is most appropriate to use for the content. 
This means the PDA has to transmit two separate sets of capabilities 
to the web server: portrait capabilities and landscape capabilities. 
This means we need to be able to send a profile that has the 
following structure:

Profile
  PDAProfile
    LandscapePDAProfile
    PortraitPDAProfile
  PhoneProfile

It isn't possible to represent such a profile with the limited 
structural elements available in CC/PP, but it would be possible if 
CC/PP adopted a more flexible approach to structural elements.
Action Class:Hold to next version
WG Action:
Kaz Kitagawa: I am not sure.  There is no perfect technology. 

Graham Klyne: "multi-modal" capabilities.  I agree that the current 
profile format doesn't handle this very well.  I think the issue is 
lack of disjunction:  no way to say "capability-set-A" OR 
"capability-set-B".  This was a conscious simplifying assumption 
in the original working group discussions.  Based on CONNEG work, 
I can see how it might be extended with "logical" structures to 
provide such descriptive capabilities.  I think that should be 
tackled, if at all, by a future working group.

Franklin Reynolds:
Support for multimodal negotiation seems to me to be an unlikely
feature to rank as "fairly major" - especially since I don't use *any*
distributed applications that do this.

It is true that CC/P does not make the following sort of component
structure easy:

Profile
  PDAProfile
    LandscapePDAProfile
    PortraitPDAProfile
  PhoneProfile

But the following component structure is possible and it solves the
same problem:

Profile
  PDAProfileLandscapePDAProfile
  PDAProfilePortraitPDAProfile
  PhoneProfile

Mark:
I'm now in agreement that this is "Hold until next version" so I will mark
it "agreed by requester"
Issue 160:
Title: CC/PP is less powerful than media feature sets
Class: Fairly Major
Status:Agreed by Requester
Subject:
This is another use case related to the issues 155 and 159. 
In media feature sets (CONNEG), there is a distinction between 
properties joined with ANDs and properties joined with ORs. 
ANDs represent constraints whereas ORs represent choices. 
CC/PP does not offer the flexibility of media feature sets 
as it is not possible to have an OR of ANDs e.g.

(mediaType = image/jpeg) and (screenHeight = 600) and (ScreenWidth = 600) OR
(mediaType = image/svg) and (ScreenHeight = 800) and (ScreenWidth = 800)

indicates that a device can portray bigger svg images than 
jpg images. Again this could be achieved by adopting the flexible 
approach to element structure described before, but would require 
some careful thought in the API e.g. you would want to retrieve all 
the constraints at the same point in the path, but you might have 
multiple elements with the same name in a connective (e.g. the 
example above) so you need some way of distinguishing the first 
AND in an OR from the second AND in an OR. Determining an API is 
outside the scope of the current CC/PP WD, but it's important the 
WD doesn't create any problems for determining an API.

One interesting aspect of CONNEG standard is that it allows profile 
attributes to be joined explicitly by ANDs and ORs. Early drafts of 
the documents defining CC/PP also featured profiles with this type 
of structure, but the current version only features profiles that 
implicitly use ANDs and ORs i.e. all the attributes in a CC/PP 
profile represent constraints joined by ANDs except where an 
attribute contains multiple values in which case it is regarded 
as a choice. Here the processor decides whether to interpret the 
values as being joined by an AND or an OR. This means that CC/PP 
profiles can only possess ORs at leaf nodes so you cannot have 
ORs of ANDs.

Such profiles are limited in their expressive power. For example 
you might want to express that a device can accept landscape or 
portrait documents and these modes are associated with different 
screen resolutions. Alternatively you might want to associate 
MIME types with quality measures as in HTTP/1.1 content 
negotiation.
Action Class:Hold to next version
WG Action:
Kaz Kitagawa: No. CC/PP works with it.

Graham Klyne: CC/PP is less powerful than media feature sets.  
As above, this was a conscious working group decision.  (I lost 
that debate, but I don't think now is the time to reopen it -- 
I think the CC/PP design allows this to be added later;  maybe 
OWL will provide the requisite tools -- certainly, I think that 
DL subsumption calculations are very similar to the capability 
matching that is in the CONNEG work.)

Franklin Reynolds: I agree with Graham.

Mark:
I'm now in agreement that this is "Hold until next version" so I will mark
it "agreed by requester"
Issue 161:
Title: CC/PP needs validation
Class: Fairly Major
Status:Agreed by Requester
Subject:
CC/PP currently does not specify any way of validating profiles; 
furthermore it says that profiles may use namespaces where no 
schema exists. I think that CC/PP should consider validation to 
catch mistakes such as

1. profiles which reference schemas that do not exist
2. profiles that misspell attribute names e.g.
 <prf:PixelsAspectRatio>0.9</prf:PixelsAspectRatio>
when it should be
 <prf:PixelAspectRatio>0.9</prf:PixelAspectRatio>
3. profiles where attributes can contain a finite set of 
values and those values have been misspelled e.g.
 <prf:WmlScriptVersion>
  <rdf:Bag>
    <rdf:li>1.2.1/June 2000</rdf:li>
    <rdf:li>1.1</rdf:li>
  </rdf:Bag>
 </prf:WmlScriptVersion>
when it should be
 <prf:WmlScriptVersion>
  <rdf:Bag>
    <rdf:li>1.2.1</rdf:li>
    <rdf:li>1.1</rdf:li>
  </rdf:Bag>
 </prf:WmlScriptVersion>

Here validation should be performed by validating the profile 
against the schema. Specifically the schema should specify
- the names of all components available in the vocabulary
- the names of all attributes in a vocabulary
- the components that attributes may appear in
- the data types of each attribute
- where an attribute can contain a finite set of values 
(e.g. "1.0", "1.1", "1.2", "1.2.1", "2.0") it should be 
possible to define those values.

Therefore a CC/PP profile MUST meet the following criteria:
- It must be valid RDF.
- It must refer to a minimum of three namespaces, the RDF 
namespace, the CC/PP namespace and one or more vocabulary 
namespaces. The RDF and CC/PP namespaces MUST be the 
standard W3C namespaces.
- All vocabulary namespaces MUST be URLs that actually 
contain valid RDF schemas. A CC/PP profile can only use 
attributes that are defined in one of the RDF schemas it 
references.
- As well as defining the attribute name and its parent 
component, the RDF schema should also define the attribute 
type and whether it is simple or complex. When attributes 
in the vocabulary can use several different resolution 
policies, as in UAProf, it should also define the resolution 
rule. When suitable mechanisms for defining these properties 
are not available in the RDF schema namespace, a new 
standardised CC/PP schema namespace should be used rather 
than placing the information in comments fields.

It should be possible to use validation technology (e.g. DTDs, 
XML Schema etc, or perhaps RDF Schema, or even XML Schema 
extensions like DAML).

The validator would be an offline tool available to profile 
authors i.e. validation would not occur as part of processing 
every CC/PP request. Another developer working with UAProf, 
Johannes Koch at PixelPark has also been raising the issue of 
validation - see
http://lists.w3.org/Archives/Public/www-mobile/2002May/0026.html
If we want to do validation, we need to define vocabularies 
more completely as Johannes points out.
Action Class:Supplementary document
WG Action:
Kaz Kitagawa: I agree. The work during CR period showed in:
 http://www.w3.org/2002/06/ccpp-impl-report.html
will include development of validator(s) and test suite.

Franklin Reynolds: I am not opposed to the idea of making 
automatic validation possible, but I am not convinced it is 
important topic for the working group. Validation will not 
catch all profile errors or even all property name errors. 
Ultimately vendors have to inspect and test their profiles. 

Having said that, I thought the current vocabulary guidelines 
said that all CC/PP properties should be derived from CC/PP 
types? What more do we need to add to the spec to enable a 
validation program to catch possible "PixelsAspectRatio not 
PixelAspectRatio" bugs?

I appreciate the problem of verifying the type/format of RDF 
literal values, but I am reluctant to commit CC/PP to solving 
this problem ahead of the RDF community. Unless we know the 
RDF standards group isn't going to solve this problem, I think 
we should avoid inventing our own solution.

I don't know anything about DAML. Their strategy for using 
XML Schemas might do the job, but I would be uncomfortable adopting
this before the RDF Core or similar working group blessed the 
approach.

I would interested in understanding when people think validation 
should happen, and how "deep" the validation should be. I think
an offline validation tool should complement the vocabulary and 
schema design guidelines proposals that were suggested by others. 
On the other hand, I do not think per request validation will 
be popular, unless it is extremely lightweight. If it requires 
additional network traffic people will either: a) avoid validation
or b) avoid CC/PP.

I agree that an offline validation tool would be useful.
Why should we care if anyone approves it?

Graham Klyne: CC/PP validation.  I strongly believe this can be 
tackled as a future work item within the current CC/PP framework, 
and doesn't require CC/PP to be revisited.  The main challenge is 
to define clearly a notion of what it means to be "valid" CC/PP.

Franklin Reynolds: I agree with Graham.

Mark: I'm now in agreement with this as long as the 
supplementary document is produced. 
Issue 162:
Title: CC/PP Profiles should only be considered valid if they use namespaces that have schemas
Class: Fairly Major
Status:Agreed by Requester
Subject:
In UAProf phones often refer to schemas that do not exist so 
such a validation process is not possible. For example this 
profile
http://mobileinternet.ericsson.com/UAprof/T68R1.xml
references the namespace
http://www.wapforum.org/UAPROF/ccppschema-20000405#
Whereas the correct URL is
http://www.wapforum.org/profiles/UAPROF/ccppschema-20000405#

Even if you retrieve the latter schema there are a large 
number of errors in this schema - try running it though the 
W3C RDF validator - as I detail
http://www-uk.hpl.hp.com/people/marbut/someQuestionsOnCCPP.htm
In DELI, I 'fix' (bodge) this problem using a configuration file 
that maps the incorrect namespaces used by phones onto local 
corrected versions of the schemas. However when a manufacturer 
releases a new phone, there is a danger that they will use a 
different namespace. As namespaces have to be explicitly 
configured in DELI, if it encounters a new namespace it will 
fail. I could 'fix' this so if a profile uses a namespace 
that DELI has never heard of it adopts a fallback one, but 
this is patching the problem rather than solving it.

In the author's opinion, CC/PP should be sufficiently well 
specified so that it is possible to implement a CC/PP processor 
that when supplied with an appropriate CC/PP vocabulary schema, 
can process any possible CC/PP vocabulary. With the current 
generation of CC/PP processors, too much vocabulary specific 
knowledge is being hard-coded into CC/PP processors.

The requirement that CC/PP profiles should only be considered 
valid if they use namespaces that have schemas have a number 
of advantages:

1. It makes validation possible.
2. It means processors can process profiles in vocabularies 
they have never encountered before.
3. The previous point makes it easier to add new vocabularies, 
for example in UAProf instead of having to have a UAProf 
meeting every time another WAP group wanted to create a new 
vocabulary they could just publish a new schema in a new 
namespace.
4. This makes it easier to have profiles that use several 
vocabularies easier. In order to support multiple vocabulary 
processors, we need to move away from hardcoded processors 
as outlined in 2.
5. It helps content authors or application authors. If they 
encounter a device that uses a vocabulary they are unfamiliar 
with, they can retrieve the schema. If the schema contains 
appropriate comments, this can help them determine how to 
support that particular vocabulary.

Therefore although providing schemas is extra work, I can only 
see benefits by CC/PP making this a requirement.
Action Class:Disagree
WG Action:
Kaz Kitagawa: I think this is implementation issue, not 
specification.

Franklin Reynolds: I support the idea of a profile checking tool, 
but I am not convinced about some of the particulars in this item. 
For example, I think it makes sense to generate a warning if a 
profile references a schema that does not exist. But since a 
schema does not *have* to exist as a web document to be legal in 
RDF or UAProf, I am not convinced it should be treated as an error.

It sounds like this may be one of those cases where we may not be
able to reach agreement. For example, I worry about how a program
is supposed to tell the difference between a schema that does not
exist and a schema that is temporarily unreachable. I also have
some security concerns about *requiring* a schema to be reachable. 

But maybe we do not have to agree. As long 
as "validation" is a test that is performed offline, then maybe it
is not important.

Graham Klyne: CC/PP Profiles should only be considered valid if 
they use namespaces that have schemas.  Hmmm... I think this comes 
down to the point 161.  There are different possible notions of 
validity.  Is it reasonable that a CC/PP processor should fail 
simply because it cannot locate a corresponding schema -- I think 
not, and IIRC that goes against a recent TAG finding.

Franklin Reynolds:
I guess I don't understand what the problem is. If validation is
performed offline, what difference does it make whether a validator
prints the message "warning: schema not found" or "error: schema not
found"?

Mark:
Perhaps a different naming scheme like urn:// could be used
instead  of http:// could be used to define namespaces where there is no
associated schema.
Issue 163:
Title: CC/PP WD gives compliance criteria for processors but never says what a processor does
Class: Fairly Major
Status:Duplicate Issue
Subject:
If I understand the current WD correctly, conformance 
is indicated by "REQUIRED", "MUST" and "SHOULD". In the current 
WD the following points are made about conformance. I've numbered 
them so I can make further comments:

1. CC/PP profile components: support for these is REQUIRED.
2. CC/PP profile defaults: support for these is REQUIRED.
3. Support for the structured CC/PP attribute formats described, 
where relevant, is REQUIRED.
4. CC/PP applications are not required to support features 
described in the appendices, but any new attribute vocabularies 
defined MUST conform to the RDF schema in appendices B and C.
5. If a CC/PP profile uses any attribute that can appear on 
different component types, then the type of any component on 
which such an attribute appears MUST be indicated by an rdf:type 
property, or equivalent RDF. A CC/PP processor MUST be able to 
use this type information to disambiguate application of any 
attribute used.
6. A ccpp:Component resource MAY have an rdf:type property 
(or equivalent RDF structure) indicating what kind of client 
component it describes. The example in figures 3-4 is of a 
profile with an explicit indication of component subtype. 
However, CC/PP processors MUST be able to handle profiles 
that do not contain component type indicators. As long as the 
CC/PP attributes used are all specific to a given component 
type, a processor will have sufficient information to interpret 
them properly.
7. Default values are referenced by the property ccpp:defaults. 
This name conforms to the name format recommendations of the 
RDF model and syntax specification [3], appendix C.1. However, 
for compatibility with earlier versions of CC/PP used with 
UAPROF, CC/PP processors SHOULD recognize the property name 
ccpp:Defaults (i.e. with cAPItal "D") as equivalent.
8. The component resources in a profile are instances of 
components identified in the corresponding schema, which in 
turn MUST be subclasses of ccpp:Component. They MUST be 
identified as such, by means of the rdf:type property whose 
value matches the name of the component type in the schema.
9: NOTE: A default document uses a <Description> element 
as its root node. The <Description> is named using an 
about= attribute whose value is a URI. This URI MUST 
correspond to the value in the rdf:resource= attribute in 
the <Defaults> element in the referencing document. In the 
examples of default documents below, the URLs of the external 
default values documents are used. However the default resource 
URI does not have to be the document URL, as long as the URI 
is uniquely identified, the same URI is used in both the source 
document and the external default values document, and there is 
some way for the processing software to locate and retrieve the 
document containing the default resource.

Conformance issues 5, 6, 7 explicitly refer to the processor 
but the document never defines what a processor is so putting 
constraints on the processor doesn_t achieve much. Issues 1 - 4 
implicitly refer to a processor i.e. presumably the word "support" 
is being used to describe what the processor does. However 
"support" is not defined anywhere so could simply mean parse. 
In Point 5 "use" is not defined nor "handle" in points 6 and 7. 
As the document needs to define what it means by "support", 
"use" and "handle" or what a processor does: otherwise they 
could just mean parsing in which case any RDF parser can be 
regarded as a CC/PP implementation as long as it obeys point 7 
e.g. it regards the property defaults equivalent to Defaults. 
Is this all a CC/PP processor does? Is it just an RDF parser? 
Or do we expect it to do more specialized tasks such as 
resolution?
Action Class:Disagree
WG Action:
Kaz Kitagawa: See previous comment - this is covered in
 http://www.w3.org/2002/06/ccpp-impl-report.html

Graham Klyne: CC/PP WD gives compliance criteria for processors 
but never says what a processor does.  This sounds to me like a 
revisiting of a processing model.  See 158 above.

Franklin Reynolds:
I think we want to be very careful about what we say about CC/PP
processing. I think it is best for the spec to deal with the documents
that are exchanged and the abstract data model they represent. The
mechanics of how an application goes about parsing and interpreting
the document (as long as there are sufficient rules for unambiguously
interpreting the document) is not our job.

I don't think we should do anything about this unless there is some
ambiguity that needs to be cleared up.

Mark:
This issue is a duplicate of 165.
Issue 164:
Title: CC/PP WD should describe a data model for CC/PP
Class: Fairly Major
Status:Agreed by Requester
Subject:
Aaron Swartz commented that the CC/PP WD should use N3. 
I think this is a good comment, because it points to a 
problem with the CC/PP WD: the CC/PP WD never really reasons 
about CC/PP in a concrete way because it is hard to represent: 
the WD either uses a graph (ASCII art) or it uses the XML 
serialisation (which is very verbose) and these are both poor 
representations. So I think it would definitely help the WD to 
use a more concise notation, such as N3. Personally though, my 
preference for a notation would be a tree view or the context 
path view I have suggested. This is because I believe that 
CC/PP can be represented as tree. Now a tree can be represented 
by N3 or by RDF, but when you are thinking about CC/PP thinking 
about the extra complexity in N3 or RDF isn't helpful. In 
particular I think the context path view I have suggested is 
helpful because it allows you to think about resolution in a 
concrete way. Here is an explanation of the context path view. 
Consider this data model for CC/PP, which should be familiar as 
it is similar to the data models used in the current WD:

Profile
+--HardwarePlatform
|  +--defaults
|  |  +--ScreenWidth = 80
|  |  +--ScreenHeigth = 100
|  |
|  +-ColorCapable = Yes
|
+--SoftwarePlatform
   +--CcppAccept = [text/html, image/jpeg]

It's possible to rewrite this data model in a context path view 
i.e. the values are the leaf nodes and the context path is the 
path to that leaf nodes (obvious inspiration from XPath here).

PropertyValue          ContextPath
80                      Profile/HardwarePlatform/defaults/ScreenWidth
100                     Profile/HardwarePlatform/defaults/ScreenHeight
Yes                     Profile/HardwarePlatform/ColorCapable
[text/html, image/jpeg] Profile/SoftwarePlatform/CcppAccept

For an example of how this helps reasoning about CC/PP, see issue 158.
Action Class:Agreed by Requester
WG Action:
Graham Klyne: CC/PP WD should describe a data model for CC/PP.  I think the 
description of this point is at odds with its title.  I think CC/PP does 
describe a data model:  it's an RDF graph with some specified internal 
structure.  But I have much sympathy with the idea of using N3 to show 
examples of CC/PP graphs, and discuss how they may be combined, etc.  In 
this case, N3 came too late to be useful for this work, and I think it's 
too late to change in this round.  Next time, maybe?

Franklin Reynolds:
I think CC/PP does have a reasonable data model. And I think the
notational difficulty of discussing RDF graphs is more serious in
email than in the document. I don't think this is a major issue for
the spec. In fact, based on the current normative RDF references,
aren't we better off trying to draw our graphs?

N3 or some other notation may eventually become the de facto, human
friendly way to describe RDF graphs. But I think this is an issue for
a future version of the spec, not the current document.

Mark: 
I would like to see this changed to "Hold until next version", then I will
mark it "agreed by requester"
Issue 165:
Title: CC/PP WD should describe a processing model for CC/PP
Class: Fairly Major
Status:Agreed by Requester
Subject:
CC/PP needs to define a processing 
model. Currently the spec talks about "processors" and specifies 
some requirements. However there is a logical problem here because 
the spec never defines what they are. Defining a processing model 
would avoid this.

For example profile attributes can be embedded within blocks such 
as components or defaults. A processor may need to determine the 
"context" of an attribute i.e. which component it is in, whether 
it as default etc. This would be easy if CC/PP was written in XML a
s it could be done using XPath. However RDF APIs do not have 
something equivalent to XPath because RDF is a graph. Therefore it 
would be useful to have some discussion about the best way to do 
this. Specifically in my CC/PP implementation, DELI, I convert the 
profile from an RDF graph to a vector. I think this approach was a 
mistake: a better approach would be to convert the RDF graph to a 
tree e.g. a DOM tree. Therefore I think it would be good to provide 
some guidance in the spec, as this does potentially effect 
implementation interoperability.

I think we need to specify a processing model for CC/PP. If we 
don't specify a processing model, then we can't specify any 
conformance testing. If we don't do this, we can't test for 
interoperability. The processing model description could describe 
things such as

i) what is the data structure for CC/PP? Do we just store 
profiles as RDF, or do we parse them as RDF and convert them to 
another data structure?

ii) CC/PP does define some resolution rules. It would be good 
to be able to access the profiles prior to resolution, so an 
application could if necessary override the resolution rules, 
as well as after resolution. How does the processor support this?

iii) Should the processor provide any support for mapping 
between vocabularies i.e. allow schemas to say that two 
properties in different vocabularies are equivalent?

iv) What should processors do if they can't retrieve a schema?

v) how should processors support vocabulary specific resolution 
rules as in UAProf?
Action Class:Fix
WG Action:
Franklin Reynolds: I am not sure I understand the problem. I 
think the spec is in good shape as long as it includes rules 
for unambiguous interpretation of a CC/PP profile. You seem 
to be suggesting there is a  problem interpreting the graph, 
but I don't understand what it is.

Your argument points out that simply using triples 
for searching does not solve the "graph context" problem. I agree. 
My simple RDF APIs provide graph context, others may not.

I think the best way to help the developers is for the spec to be
unambiguous. Of course, clarity and simplicity would also be nice,
but we can't have everything ;) I have no object to providing additional 
guidance in an "implementation guide". 

Graham Klyne: 
>- One problem in CC/PP is determining the context of an attribute e.g. which
>component an attribute is in, whether it is a default. In XML this can be
>done using XPath.

.. I don't understand this.  Given a CC/PP profile, the component to which 
an attribute belongs is manifest in the profile.  I don't see how XPath 
will help here, and I think it would add more confusion.

>- The DOM data structure is a natural data structure for CC/PP as CC/PP
>profiles are trees and DOM is a tree; RDF models on the other hand are
>graphs so they are not the optimum data structure for CC/PP.

.. I disagree with the suggestion that RDF is somehow a less natural or 
less efficient way to convey a tree.   Most RDF data I have seen is mostly 
tree-structured, but there are times when this can be too constraining.

Also, much of the CC/PP design to work with proxies would be invalidated by 
a strictly tree-structured model.  Sooner or later, I predict that you'd 
end up re-inventing the graph structures.

Graham Klyne: CC/PP WD should describe a processing model for CC/PP.  I 
strongly disagree.  CC/PP is a format with some described semantics.  
It does not describe a process.  To describe CC/PP processing would, 
I believe, make correct interpretation of CC/PP profiles more difficult.  
If it belongs anywhere, a processing model should be part of a CC/PP protocol 
description.

Franklin Reynolds:
I think I agree with Graham that the current document should not
define CC/PP processors. If the WG needs to define CC/PP processors,
then we should do it in a different document.

Mark:
It is clear from early JSR discussions that the most contentious aspects of
CC/PP are protocol and processing. We need to try to resolve these issues. I
don't think we can reach agreement on this, so I think we need to keep it as
"dissent".

From CR Telecon:
It was proposed there were two ways of addressing this issue:
1. To take the document back to working draft stage to provide a new description
of how processing is performed.
2. To write a test case document, that supported the structure and vocabularies
document and removed any ambiguity.

After the telecon, the WG discussed a third solution: they determined there
was agreement on how to treat components and defaults, but not on proxy
support. In addition, most of the currently implemented CC/PP processors do
not provide the proxy support in the way outlined in the CC/PP spec. Therefore
it was decided that this problem could be resolved by making proxy support
optional. 
Issue 166:
Title: CC/PP vocabularies do not distinguish between mandatory and optional properties
Class: Minor
Status:Agreed by Requester
Subject:
In CC/PP, all properties are optional. This is very unhelpful 
for people creating content or webservices, as they have no 
guarantees that a device using a vocabulary will supply a 
specific property. Ideally, vocabularies should state which 
properties are optional and which properties are mandatory. 
This would allow validators to check profiles accordingly. T
his problem has been raised by IBM also - see section 3.1 of
http://www.w3.org/2002/02/DIWS/submission/aschadeCompositeProfileInformation.html

Note I am not saying that CC/PP should define what the mandatory
properties are, it should just give vocabulary authors the
possibility of indicating which properties are mandatory
and which are optional in their particular vocabulary.
Action Class:Disagree
WG Action:
Kaz Kitagawa: The aim of the CC/PP is not define vocabularies. 

Graham Klyne: CC/PP vocabularies do not distinguish between mandatory and 
optional properties.  This was another conscious decision.  The idea of a 
mandatory core vocabulary was discussed, but in the final analysis we 
couldn't agree on a core vocabulary that was applicable to all classes of 
device.  So, yes, this leaves some interoperability problems.  I think 
that defining core vocabulary profiles for certain device types may be a 
reasonable activity, but not one that should be party of the core CC/PP 
specification.  The nearest we got to this was appendix C.

Franklin Reynolds:
I don't think this is a "major" issue in the sense that it should hold
up the current version of the spec, but I think it might be hard to
define some sort of "Mandatory" key word that could be easily
implemented and used by CC/PP validators. For example, if a profile
uses multiple vocabularies and it only really needs one non-mandatory
property from vocabulary FOO, does the profile have to use the
mandatory properties from FOO? What if the non-mandatory property was
used in a default profile? What about a proxy-profile?

I think this issue, as well as all the other validation issues, should
be considered together as a future activity.

Mark:
I would like to see this changed to "Hold until next version", then I will
mark it "agreed by requester".
Issue 167:
Title: CC/PP uses a protocol based on HTTP-ex
Class: Minor
Status:Dissent Overruled
Subject:
There is a W3C note that describes a possible protocol for 
CC/PP based on HTTP-ex, the HTTP-extension framework. In the 
author's opinion the choice of HTTP-ex is unfortunate as it 
is an experimental protocol that is not widely supported. 
HTTP-ex has two important differences from HTTP/1.1: it 
defines a number of new methods e.g. M-GET (mandatory get) 
and it associates new request header fields with URI's via 
numerical namespaces.

The usefulness of M-GET is arguable. This instructs the 
server only to return content if it can interpret the 
enclosed CC/PP profile. If not it should return an error. 
Servers that are not HTTP-ex aware will also return an 
error, as they do not recognise the M-GET method. However 
the same functionality can be achieved without having to 
create new HTTP methods as demonstrated by the UAProf W-HTTP 
protocol. If a server is CC/PP aware, it can append an 
additional header to the response indicating if it has used 
the profile while processing the request. If a server is not 
CC/PP aware then it will not include this header. This allows 
a client to decide whether to try to display the content 
anyway or whether to report an error.

The usefulness of numerical namespaces is also arguable. 
HTTP-ex was proposed at a time when it seemed likely a 
large number of non-browser applications would use HTTP 
with non-standard header request fields. Numerical namespaces 
were seen as a way of preventing possible conflicts between 
these new request header fields. However the introduction of 
SOAP has shifted the argument up a layer in many of these 
applications. This has resulted in decreased interest in 
HTTP-ex: for example even now there are very few HTTP-ex 
capable webservers available apart from the Jigsaw server.

I believe this is a mistake as HTTP-ex as it is not widely 
supported: for example there is no support in Java servlets 
for HTTP-ex. Defining a protocol which is difficult to 
implement in Servlets is an unnecessary barrier to adoption. 
Recently there has been some discussion about interoperability 
testing for CC/PP, but this will require the interoperability 
testing of implementations using HTTP-ex. I believe this is 
a mistake, and I believe that CC/PP should move away from 
using HTTP-ex as soon as possible.
Action Class:Outside charter
WG Action:
Kaz Kitagawa: Under current charter, the wg cannot work on this.
DI WG will define CC/PP protocol.  

Graham Klyne: CC/PP uses a protocol based on HTTP-ex.  This was not part of the 
working group's original charter.  (I also happen to believe that the 
protocol proposal is deeply flawed -- my comments were posted to the 
CCPP-protocol mailing list some time ago.)

Franklin Reynold:
How can something, explicitly outside of the charter be 
"fairly major" or ranked "dissent"?

Mark Butler:
There is dissent on this issue, because I do not believe CC/PP can provide
interoperability unless it agrees on a protocol. Technological problems
cannot be solved by political dictats - they can only be ignored. See also 
Andreas Schade's comments on issue 174. 

Although this is outside charter, it is clear from early JSR discussions
that the most contentious aspects of CC/PP are protocol and processing. We
need to try to resolve these issues. I don't think we can reach agreement on
this, so I think we need to keep it as "dissent".

From CR Telecon: 
Adopt one of the existing protocols either from the CC/PP-ex note or
the WAP Forum UAProf specification for testing, then address the
protocol issue in the W3C DI working group.
Issue 167b:
Title: CC/PP Protocol appends diff numbers to request header fields, making it difficult to retrieve diffs
Class: Fairly Major
Status:Outside Charter
Subject:
In the servlet architecture it is difficult to retrieve header 
fields like this:
32-profile-diff-6: <?xml version="1.0">

because you don't necessarily know what the 2nd number is 
going to be. It is much easier to retrieve header fields like 
this:

32-profile-diff:6; <?xml version="1.0">

or even better still like this

profile-diff:6; <?xml version="1.0">

therefore having lots of numbers as in the first example should 
be avoided if possible.
Action Class:Outside charter
WG Action:
Graham Klyne: (again), more on protocol, out of scope.

Mark: See previous issue. 
Issue 168:
Title: CC/PP does not specify a mechanism for merging two vocabularies associated with different namespaces that use the same attributes
Class: Fairly Major
Status:Agreed by Requester
Subject:
CC/PP does provide on key advantage over other standards 
i.e. it allows profiles to support multiple vocabularies 
via namespaces. Unfortunately, processing multiple 
vocabularies presents additional problems beyond 
distinguishing between vocabularies. For example, at 
present, at least two vocabularies for UAProf exist, but 
the UAProf specification does not define how a processor 
should process a request that uses more than one UAProf 
vocabulary. Each vocabulary is associated with a different 
namespace so one possible interpretation could be for the 
processor to assume that the attributes, even if they have 
the same name, are totally different because they are in 
different namespaces. Other interpretations are possible. 
Current UAProf vocabularies contain some attributes that 
are identical in all vocabularies. Hence we might expect 
these attributes to be merged using conventional resolution 
rules. Other attributes are similar but have undergone 
changes e.g. they have moved component or have changed 
resolution rule. The required behaviour in these 
circumstances is even more uncertain. It seems that we 
need to decide how to merge different vocabularies and to 
define a way of describing this merge process.

Processing metadata described in multiple RDF namespaces 
is a key problem for the Semantic Web, but although 
previous drafts of RDF Schema did propose a mechanism 
for indicating that two properties defined in different 
namespaces where equivalent, that has been removed from 
the latest draft. Therefore at the moment CC/PP would have 
to define its own mechanism for doing this. An alternative 
and possibly better solution is the use of modular 
vocabularies. Here instead of replicating attributes so 
they exist in multiple namespaces for each vocabulary 
type, we create small "sub-vocabularies" of standard 
attributes with a single namespace. Specific vocabularies 
such as UAProf then reuse these sub-vocabularies rather 
than replicating attributes. For example in the current 
UAProf vocabularies both the November 1999 and May 2001 
versions use the attribute BitsPerPixel in the component 
HardwarePlatform. In the author's opinion it would have 
been better to re-use the original BitsPerPixel in the 
original namespace than create a new version as this creates 
additional problems for processors as they need to map 
between the two versions. Sub-vocabularies would also 
reduce the total number of attributes in common use; 
something that can only simplify matters for content 
authors or server developers. One possible problem with 
sub-vocabularies is the possible proliferation of 
components of the same type. Currently you would need an 
instance of a component for each component and each 
namespace used by an attribute in the profile. This could 
result in multiple instances of the same component where 
each component is associated with a different namespace. 
This is another unnecessary complexity introduced by 
components.

This problem is also discussed in
http://www.w3.org/2002/02/DIWS/submission/aschadeCompositeProfileInformation.html
Action Class:Outside charter
WG Action:
Kaz Kitagawa: This is out of scope.  This thing may 
happen to all of the markup languages.  Possibly, RDF 
can do that.

Graham Klyne: CC/PP does not specify a mechanism for merging two vocabularies 
associated with different namespaces that use the same attributes.  This is 
a wider issue with RDF, and I think it would be inappropriate to try and 
solve it in CC/PP.  RDF schema and DAML provide some mechanisms that might 
be used to define equivalence between vocabularies.  A clear advantage of 
using RDF is that these mechanisms, as they are evolve, can be incorporated 
into CC/PP.

Franklin Reynolds:
I think this issue is misleading. The problem statement includes:

"Each vocabulary is associated with a different namespace so one
possible interpretation could be for the processor to assume that
the attributes, even if they have the same name, are totally
different because they are in different namespaces. Other
interpretations are possible."

While a different interpretation is possible, it would be a mistake. I
suspect the motivating problem behind this issue is version management
(same as issue 169?). If this is true, why can't this problem be
solved with a layer of indirection - either using XML include or RDF
schema tricks?  If the tools to manage this problem already exist, why
is this something we should address? And if we should address it, why
not in the supplementary document mentioned as the answer to 169?

Mark Butler:
I don't think that tools do not exist to manage this problem. 
I saw a presentation from RV Guha recently, and this still
seemed to be a research problem for the Semantic Web. If
someone could point existing tools out to me I would be very 
interested?

Franklin Reybolds: 
Let me put it a different way. CC/PP assumes the use of XML namespaces
and RDF schemas. Problems associated with managing XML namespaces and 
RDF schemas are generic to the Web and are not unique to CC/PP so I 
think we should try to avoid inventing unnecessary CC/PP specific name 
space management strategies. Different organizations may choose different
version management strategies. This should be up to the organizations
that manage each XML name space and RDF schema.

This problem belongs to OMA, IANA and other naming authorities, not
the CC/PP WG.

Mark:
I don't think we can reach agreement on this, so I think we need to keep it
as "dissent".
Issue 169:
Title: Need better guidelines on namespaces and vocabularies
Class: Fairly Major
Status:Agreed by Requester
Subject:
 I think the CC/PP WD 
needs better guidelines for creating vocabularies. With 
UAProf they followed the RDF Schema guidelines, adopting 
a brand new namespace for each vocabulary every time they 
wanted to add new attributes. When they did this, they copied 
all the existing attributes to this namespace. Also sometimes 
in new vocabularies they have changed resolution rules, the 
components or the data types of these attributes also.

(An aside: The point is these changes always cause problems. 
For example in UAProf 1.2.1 they made SecuritySupport a literal 
leading to the problem described in MB_11. They then decided to 
change this to a Bag in UAProf 2.0. However this doesn't resolve 
the problem for 1.2.1! Specifically in this instance they do not 
use one advantage of using the XML serialisation of RDF i.e. you 
can infer the "collection type" (my own term, sorry) e.g. simple, 
bag or seq from the profile. So even a processor should in theory 
be able to cope with a profile that changes SecuritySupport to a 
Bag, unless the processor is performing validation. So people are 
not using validation, but yet they have a very strict 
interpretation of the schema.)

Currently processors need to be configured in advance to 
recognise namespaces and associate them with schemas. Clearly 
releasing vocabulary versions will cause an update problem for 
processors that work this way. Another problem is how do you link 
UAProf devices that use slightly different versions of the same 
vocabulary in a chain as there is no agreed way of merging different 
vocabulary versions, particularly when attributes have the same 
meaning but some of their properties e.g. data type, resolution 
rule etc have changed. This problem has not yet been resolved.

So I think there is no getting away from the fact that
i) we need to agree on vocabularies
ii) once we've agreed on vocabularies, we need to think very 
carefully before we change them because changing them creates 
problems and breaks things
iii) we definitely should not change vocabularies just to add 
new attributes; we should create new vocabularies and use the 
new and old vocabularies concurrently

Furthermore I think there is a general need to rethink how 
namespaces are used in association with schemas. Specifically 
people seem to be following TBL's advice on "good URL's don't 
change". Where as I can see why this is important to documents, 
I don't think it is necessarily true for schemas. If processors 
retrieve schemas automatically when the process documents, then 
I believe you can relax the advice "good URL's don't change" to 
"good URLs only ever undergo additive change" for schemas i.e. 
nothing in the schema that already exists is deleted or changed, 
but that new items can be added. I think this would help avoid 
the versioning problem that UAProf is currently encountering. 
Note people working on UAProf are also aware of this issue and 
it was brought up at a recent WAP-WAG meeting, but I can't 
include text due to IP issues associated with the WAP Forum.

See also 179. 
Action Class:Supplementary document
WG Action:
Kaz Kitagawa: These are out of scope. Does anyone interested 
in writing CC/PP for dummies ?

Franklin Reynolds: A guide or best practice document makes 
sense to me. However, I am not sure it should be in the 
charter. If we decide to put it in a new charter, should it 
be a Note or something else?

I don't think this belongs in the spec. It is already longer than
I would like. Why would we slow the first release of the spec for
this rather than including this information in a separate document?

Graham Klyne: Need better guidelines on namespaces and vocabularies.  
As described, this also seems like a more general RDF issue.  I'm not 
sure there's more we can usefully say.  I agree with others that this 
belongs in a separate document.

Mark: I now agree with "supplementary document". 
Issue 170:
Title: Need to emphasise the importance of defining property values in vocabularies
Class: Minor
Status:Agreed by Requester
Subject:
Also, as Janos Vamosi from Nokia raised with the WAP Forum 
recently, although the UAProf spec defines property names 
for the UAProf vocabulary and example property values, it 
doesn't define constraints on property values or what the 
property values mean. This means there is a danger different 
manufacturers may use the same value to mean different things 
or different values to mean the same things. CC/PP vocabularies 
need to accurately define the meaning of property values. The 
same issue has been raised by people on the WWW mobile list
http://lists.w3.org/Archives/Public/www-mobile/2002May/0026.html
Strictly this isn't CC/PP's problem, but I think the WD does 
need to give some explicit guidance about this.
Action Class:Disagree
WG Action:
Graham Klyne: Need to emphasize the importance of defining 
property values in vocabularies.  It seems to me this is just 
a case of common sense and good documentation (of vocabularies).  
Encouragaing the use of existing, [well-documented] vocabularies 
is a start.

Franklin Reynolds: 
I have no objection to a short paragraph discussing this issue being
added to Appendix D: Recommendations for creating a vocabulary.
(But how can this be a "fairly major" issue?)

Mark:
I have proposed some text here which should help, but addressing validation
and vocabulary concerns with a supplementary document is better. If we can
agree on changes or a supplementary document I can change it to "agreed by
requester". 
Issue 171:
Title: It is not possible to query CC/PP using XPath, so hence it is difficult to use CC/PP with XSLT
Class: Fairly Major
Status:Agreed by Requester
Subject:
I've been working on implementing CC/PP in Apache Cocoon in 
order to demonstrate how CC/PP or UAProf information can used 
in conjunction with content specialisation methods such as 
content transformation via XSLT. Typically this requires creating 
conditionals in XSLT that query the profile using a related 
standard called XPath. During this work, it was found that 
specifying constraints for matching device profiles in XPath is 
complicated and cumbersome. Furthermore there is no easy method 
of abstraction so that common sets of constraints may be reused in 
multiple stylesheets. One problem with manipulating CC/PP or 
UAProf profiles in XSLT is that these profiles are represented 
using RDF. Although RDF models can be represented in an XML 
serialisation, it is difficult to manipulate this serialisation 
in XSLT as it can represent the same model in many different 
ways. Models may vary depending on whether they use elements 
or attributes to indicate properties. Furthermore typically the 
XPath expression necessary to query a certain property value may 
not be representative of the underlying RDF structure of the 
profile. In order to avoid these problems DELI creates a 
"flattened" version of the UAProf or CC/PP profile available to 
XSLT stylesheets via a parameter called deli-capabilities. The 
profile is "flattened" because it is just a list of profile 
properties as XML elements without any component definitions 
or resource typing. The only obvious remnant of RDF is the way 
individual attribute values for complex attributes are separated 
using <li> elements. This heavily simplified profile form 
has the additional advantage of making the XPath expression 
correspond to the profile structure.

Clearly it may be desirable to use CC/PP with XSLT (in fact 
the Content Transformation Heuristics document mentions this), 
but at the moment it is difficult due to the adoption of the 
XMl serialisation of RDF.
Action Class:Disagree
WG Action:
Kaz Kitagawa: This is a research topic.  CFG + Semantics 
(through RDF) will possibly solve this. 

Graham Klyne: It is not possible to query CC/PP using XPath, so hence it is 
difficult to use CC/PP with XSLT.  "When what you have is a chainsaw, 
everything starts to look like a tree".  A part of me thinks that this is 
simply a case of trying to use the wrong tools, like hammering a 
screw.  But I musk concede that, as of today, there are more generic XML 
tools than RDF tools, so it's not surprising the folks will try.  This 
takes us to the debate of using restricted form RDF, that also conforms to 
some well-known XML forms that can be described by XML schema or 
similar.  I can see some advantage to that, as long as it's kept very clear 
that the underlying model and framework is RDF, and it's not acceptable to 
introduce features which are not RDF compatible.

Franklin Reynolds:
This is just another version of the XML vs. RDF debate.

Mark Butler:
I don't agree. This is different. The point I am making
here is as far as I can see, no-one has considered "right we've got
CC/PP, what do we do with it?" Currently many solutions for adapting
content e.g. Apache Cocoon, Morphis, IBM Transcoding Publisher, the
now discontinued HP Mobile toolkit use XML and XSLT to adapt content.
However as CC/PP is based on RDF, it's very difficult to use CC/PP
in these situations. For more details, see my technical reports. 

Franklin Reynolds: 
I agree that there are adaptive content solutions that use XML and XML 
tools like XSLT and I agree that RDF is not easily processed using those tools. 
If CC/PP were encoded using XML (without RDF) or a constrained subset of
RDF that was friendly to XML process tools, it would be reasonable to 
use XSLT and other XML processing tools. The biggest problems with 
this approach are:

  a. incompatibility with UAProf
  b. significant delay in completing the first version of the spec 
  c. some people like RDF and like using RDF tools
  d. there are even some people who don't like XML or XSLT (mea culpa)

I don't think there has ever been a requirement that CC/PP profiles 
should be easy to process with XSLT, so it is hard for me to understand
why this should be considered a major issue for the current spec. I think 
UAProf compatibility is a much bigger concern than XSLT friendliness. On 
the other hand, once version 1 of the spec is finished, I have no 
objection to revisiting the decision to use RDF - though I would hope 
this work could be done in conjunction with OMA.

Mark:
I would like to see this changed to "Hold until next version", then I will
mark it "agreed by requester". 
Issue 172:
Title: Type statements for components should not be optional
Class: Fairly Major
Status:Agreed by Requester
Subject:
As already noted, conformance issue 6 in the WD is
"A ccpp:Component resource MAY have an rdf:type property (or 
equivalent RDF structure) indicating what kind of client 
component it describes. The example in figures 3-4 is of a 
profile with an explicit indication of component subtype. 
However, CC/PP processors MUST be able to handle profiles 
that do not contain component type indicators. As long as 
the CC/PP attributes used are all specific to a given component 
type, a processor will have sufficient information to interpret 
them properly."
However, I believe there is a situation i.e. when a processor 
can i) not retrieve a schema ii) the components are not typed 
where it is impossible for the processor to determine components. 
For example some existing profiles, such as the Ericsson T68 
and T39  do not use rdf:type to identify components. Instead 
they just put the name in the local ID. Although this behaviour 
is permitted under the CC/PP and UAProf recommendations, I 
believe this is incorrect use of RDF. For example her_s a 
fragment from the T68 profile:

<prf:component>
  <rdf:Description ID="SoftwarePlatform">
       <prf:AcceptDownloadableSoftware>No</prf:AcceptDownloadableSoftware>
   </rdf:Description>
</prf:component>

As you can see in this profile a component is created with 
a local ID of "SoftwarePlatform". By local I mean it is local 
to this particular model. RDF processors don_t place a "global" 
interpretation on the ID. So therefore I think we have to use 
rdf:type to indicate that when we create a SoftwarePlatform 
resource we are referring to something we have defined in the 
associated schema. Presumably some UAProf processors search the 
profile for resources with specific local IDs e.g. "SoftwarePlatform",
"HardwarePlatform" etc. This is a mis-use of RDF: if we need to 
search for resources, then we should do it based on resource type.

My processor, DELI,  tries to cope with such situations by 
inferring the component from the attribute name using a vocabulary 
description. However a processor cannot guarantee that the 
vocabulary description will be available. All currently available 
UAProf profiles reference a namespace using a URL that does not 
contain a schema. If the processor has not been instructed a priori 
to associate this namespace with a local copy of the schema, then 
the processor cannot infer the parent components of any attribute, 
as they do not possess the schema. This stems from the fact that 
CC/PP and UAProf do not state that profiles MUST reference namespaces 
that make RDF schemas available.

Alternatively a better solution would be to get rid of the current 
approach for defining components: see issue 156. One argument 
against 156 might be it would break compatibility with UAProf. 
However as UAProf profiles don't always do it correctly anyway (for 
example see http://www.mitsubishi-telecom.com/profiles/eclipse.ua) 
I don't think this argument holds.
Action Class:Disagree
WG Action:
Kaz Kitagawa: This is a conformance issue. 

Graham Klyne: Type statements for components should not be optional.  
The current spec (section 3.1.1) is clear that when ambiguity would 
otherwise arise, an rdf:type MUST be present.

Franklin Reynolds:
I believe that the assumption was that the label of the component
resource, if it matched a well known value, would be sufficient to
determine the type of the component. Why do you argue that this is
"incorrect use of RDF"? And even if it is bad RDF, why won't it 
work?

Mark: I don't think we can reach agreement on this, so I think we need to keep it
as "dissent".
Issue 173:
Title: WD describes resolution, but not clear how this is implemented. Need to develop a notation for this and then reason using notation in concrete manner
Class: Fairly Major
Status:Duplicate Issue
Subject:
A CC/PP profile or a set of profiles in a request may contain 
multiple values for a single property. Therefore one task which 
must be performed by either the processor or the application is 
resolution i.e. determining how to use these values. Sometimes 
when an property has multiple values it indicates a choice i.e. 
a choice of mime types in CcppAccept. Here, in order for a processor 
to recognise this is a choice, the property needs to be a suitable 
data type e.g. Bag. Alternatively multiple values may indicate that 
there are different values of the same property associated with 
different contexts. In this case resolution needs to be performed 
to determine which value to use as a constraint.

Although CC/PP does not define resolution rules as completely as 
UAProf, it does define resolution rules in two situations: defaults 
and proxies. What is not clear is how a processor API responds to 
these resolution rules. For example the resolution rule for defaults 
is that defaults are always overridden by non-default values. 
However should a processor return both the default and non-default 
value to an application and then leave it up to the application to 
decide which value to use or should it automatically return only 
the non-default value? The problem here is there may be situations 
where an application does want to access the unresolved profiles. 
Therefore I think the WD needs to specify a processing model in 
order to distinguish we typically want CC/PP processors to be able 
to supply profiles, complete with context information, as well as 
implement resolution to simplify the job for the user. I find a view 
I have invented called the context path useful for thinking about 
these situations. For example consider the following profile:

PropertyValue          ContextPath
100                     Profile/HardwarePlatform/defaults/ScreenHeight
80                      Profile/HardwarePlatform/ScreenHeight

So a CC/PP processor might return this, the unresolved values from 
the profile set and then offer a resolution method that performs 
the default resolution rule i.e

PropertyValue          ContextPath
80                      Profile/HardwarePlatform/ScreenHeight

However we might also deal with a profile like this

PropertyValue          ContextPath
300                     PDAProfile/HardwarePlatform/defaults/ScreenHeight
100                     PhoneProfile/HardwarePlatform/defaults/ScreenHeight
80                      PhoneProfile/HardwarePlatform/ScreenHeight

in which case after resolution we would expect to get back

PropertyValue          ContextPath
300                     PDAProfile/HardwarePlatform/defaults/ScreenHeight
100                     PhoneProfile/HardwarePlatform/defaults/ScreenHeight

This issue applies to ProxyBehavior as well - I believe the WD needs 
to be a lot more prescriptive about this.

See also issue 178. 
Action Class:Duplicate Issue
WG Action:
Kaz Kitagawa: This is an implementation issue. 

Graham Klyne: WD describes resolution, but not clear how this is 
implemented.  I tend to agree, but the original WG took a view that the 
content provider (e.g. origin server) would know how to resolve this 
based on its knowledge of the property.

Conclusion: Implementation issue

Franklin Reynolds:
As I understand the issue, this is another version of the multi-modal
negotiation support problem. The simple answer is that this never
happens because the application only describes the hardware platform
profile that will be used. If some sort of multimodal negotiation is
taking place then maybe additional information has to be sent to
facilitate profile resolution by the application?
 
Again, I think this is future stuff.

Mark: Same as issue 165. 
Issue 178:
Title: Resolution Mechanisms
Class: Fairly Major
Status:Agreed by Requester
Subject:
During profile resolution, it is necessary to merge
profiles. During the merge it is possible that there
are multiple values for the same attribute. Clashes
in UAProf are resolved as follows:
- Profile attributes are divided into standard
attributes and defaults.
- Standard attributes always override default attributes.
- If there are multiple standard attributes, then a
resolution rule is applied to determine the final value
of the attribute. There are three resolution rules
in the UAProf spec:
 + override (use the last encountered attribute value)
 + locked (use the first encountered attribute value)
 + append (add the attribute values in the order encountered)

CC/PP on the other hand does not specify any behaviour
regarding defaults and standard attributes (my understanding
of the spec is the CC/PP processing application will receive
a profile containing both sets of attributes where they are
both present). Also CC/PP does not feature mechanisms like
resolution rules.

Therefore it has been suggested that the CC/PP working group
should consider the problem of resolution, and at minimum
devise a method of specifying resolution mechanisms for
specific CC/PP vocabularies so that applications can
process different vocabularies with different resolution
mechanisms.
Action Class:Outside charter
WG Action:
Johan Hjelm: I think these are good comments - however, I 
think all of them will fall in the domain of future work. 
Several of them do pertain to the use of  RDF and the 
construction of RDF itself, which the RDF Core working group 
is addressing now. Protocols are out of scope for the working 
group as currently chartered, so this is definitely future work 
items (and please note that the WG did not propose the protocol; 
it is a W3C Note, something like an experimental RFC, from 
Taka and me). Resolution mechanisms also fall into this domain.

For these reason, many of these issues can not be addressed 
within the current work, and not in the spec as currently 
written. However, the reasoning behind the existing spec 
works, and it has been implemented. My thinking is that for that 
reason, we should not mess with it now, but let it go to CR, and 
then address these issues in future work (and I do think that 
several of them will require a great deal of work, while others 
will fall naturally into the work done anyway).

In short - we will take care of it when the current spec has 
gone to CR.

Graham Klyne: Resolution Mechanisms.  I tend to agree, but the 
original WG took a view that the content provider (e.g. origin 
server) would know how to resolve this based on its knowledge 
of the properties.  I think this might be resolved through 
future work to define CC/PP-specific schema extensions 
(this relates to comments about validation at item 161).

Franklin Reynolds:
CC/PP does specify a resolution rule. It is equivalent to override. It
does not support append or locked. Though not always convenient, it
provides the most important functionality. Specifying additional
resolution mechanisms should be deferred until there is more
experience and demonstrated need.

Mark: This issue is the same as 173; close this issue
Issue 179:
Title: Vocabulary Description
Class: Fairly Major
Status:Agreed by Requester
Subject:
In order to simplify the processing of CC/PP vocabularies,
it is desirable that there is a way of describing those
vocabularies i.e. what components they contain, what
attributes the components have, attribute type, the
appropriate resolution rule for each attribute, any
constraints on the attribute (e.g. a list of possible
values for an enumeration, a range of a continuous value)
and also possibly any interdependencies between attributes
(e.g. if the color attribute is toggled, then
bitsperpixel will change as well).
Currently RDF schema is used to specify CC/PP. However
it is not clear if it is sufficient to describe
vocabularies to this detail. Therefore it has been
suggested the CC/PP working group should propose
appropriate mechanisms for describing vocabularies.
Action Class:Supplementary document
WG Action:
Johan Hjelm: See issue 178.

Graham Klyne: Vocabulary Description.  I think this is the 
same as 178/161.

Franklin Reynolds:
This is a catch all issue for vocabulary specification issues:
resolution issues (178), constrained types and values (177), etc. 
This work is probably worth doing, but I think it should be 
pursued in the next version of the spec or in a different spec.

Mark: This issue is the same as 169, close this issue. 
Issue 180:
Title: Different component IDs for components of the same type
Class: Fairly Major
Status:Request Approved
Subject:
One problem, particularly when profiles include other profiles
via references such as defaults,
is there may be a number of instances of component data
with different IDs that all refer to the same component type.
When profiles are resolved (i.e. merged) there is a danger
that attributes about the same component will be separated
even though the component fragments are the same type. Can
the CC/PP WG suggest an easy way to overcome this problem
without involving complex specialist RDF merging operations?
Action Class:Fix
WG Action:
Johan Hjelm: See issue 178.

Graham Klyne: Different component IDs for components of the 
same type.  I thought the intent was clear, but on re-reading, 
I think it could be clearer.  Maybe need to add something like 
this in section 3.1.3, just 
after the 1st paragraph:

[[
If a component referenced by ccpp:default contains an attribute that is not 
present on the referencing profile component, then the effect is as if the 
attribute value in the default component is applied directly to the profile 
component.  For example:

[MyProfile]
  |
  +--ccpp:component--> [TerminalHardware]
                        |
                        +--rdf:type-------> [HardwarePlatform]
                        +--ccpp:defaults--> [HWDefault]
                        +--memory---------> "32Mb"

[HWDefault]
  |
  +--rdf:type---> [HardwarePlatform]
  +--display----> "320x200"
  +--memory-----> "16Mb"

should be interpreted as describing the same capabilities as:

[MyProfile]
  |
  +--ccpp:component--> [TerminalHardware]
                        |
                        +--rdf:type-------> [HardwarePlatform]
                        +--display--------> "320x200"
                        +--memory---------> "32Mb"
]]

Andreas Schade http://lists.w3.org/Archives/Public/www-mobile/2001Aug/0042.html

Computation of MD5 digest 30 August 2002
Issue 174:
Title: Computation of MD5 digest
Class: Fairly Major
Status:Outside Charter
Subject:
The XML document containing the profile subset is carried in the
field-body of a HTTP/1.1 header field "x-wap-profile-diff: 1; <?xml
.../>". This field-body can be "folded" onto multiple lines and
HTTP/1.1 proxies such as a caching proxy is free to modify this
"folding" regarding the usage of linear-white-space without changing
the semantics of the field value. Unless special care is taken, such
modifications will break the MD5 digest value.  While CCPPex at least
mentions the need for a canonical representation of the XML document,
the present specification does not address this problem at all. It
does remain unclear, how the MD5 digest is to be computed and how
linear-white-space is to be treated in this computation.

The specification requires a canonical format for XML documents
embedded in HTTP headers. This canonical format MUST not be based on a
DOM based scheme (such as DOMHASH [RFC2803]) to avoid forcing proxies
to process the HTTP header values into DOM data structures.
Action Class:Outside charter
WG Action:
Johan Hjelm: Unfortunately, the CC/PP working group was not 
originally chartered to do protocol work. We intend to submit a new 
charter allowing us to do so, and your comments are most helpful in 
that regard.

Regarding the matching of attributes, we did leave that out of the
specification, the numbers of values for the properties you mention 
would in principle be infinite, and the literals can only be matched 
on a "exist/not exist" basis. The metrics for the numeric entities 
are not metrics, but literals, since RDF does not have data types 
other than strings (again, in principle). It seems to me that some 
of your issues stem from thinking about RDF in an XML-schemalike 
way, and that is not currently possible. The work in the RDF Core 
working group may make some of that thinking workable, however.
But this may be my personal impression.

Matching has worked fine in several implementations, but you can not 
do it in the way I believe you think. We have also intentionally 
not discussed matching in the CC/PP specification, since this would 
be based on heuristics in the implementation.

Graham Klyne: Computation of MD5 digest.  This is a 
protocol/implementation issue.  XMLDSIG provides the machinery, I think.

Andreas Schade:
>This one is related to the protocol issues #166 and #167 which were
>labeled "dissent".
>Of course, from a formal point of view, since the CC/PP WG was not
>chartered to do any protocol work, any protocol issue can be
>considered out of scope. The issue would be mute if CC/PP
>*specifies* a transfer protocol that works without a hash.
>However, in my opinion it was a clear mistake to exclude the
>protocol area from the beginning. How can you reach
>interoperability for any technology, if the transfer mechanism
>is not specified? For this reason, the protocol work is crucial if
>we want to see some broader uptake of CC/PP. Given that, the WG
>comments are not really satisfactory to me, even though they are
>formally correct.
>Aside note: I think a fair part of Johan's reply applies to issue
>177 - see below.
>Suggested status: dissent

Mark Butler:
>I absolutely agree with Andreas' comments about interoperability
>given the fact the protocol is beyond the scope of the WG. 
Issue 175:
Title: Multiple instances of components and resolution
Class: Minor
Status:Request Approved
Subject:
Problems arise if a component of some type occurs more than once. 
The standard does not say explicitly if such a situation can occur 
or not. If so, how does the profile resolution process work? 

In the case of collating property values specified in multiple component
fragments, what is the resulting component id? Can all these component
fragments contain default references, and if so, how are they processed?
Does the resolution process observe only the first default reference
and discard all others, or does it try to collate and merge default
property values using the resolution policies? And last but not least,
can defaults references be nested, i.e. can a component contain a
default URI which refers to a component which in turn contains a default
reference?
Action Class:Fix
WG Action:
Johan Hjelm: See issue 174.

Graham Klyne: Multiple instances of components and resolution.  I missed this.  
I think it's probably fair that the specification should say something about 
this; e.g. in section 3.1.1:
[[
No more than one instance of a component type should be present for any 
given profile resource.
]]

(Note that this doesn't mean that different instances of a given component 
type cannot appear linked to different resources in a CC/PP profile, e.g. 
for defaults or proxy capabilities.)

Andreas Schade:
>This issue raises questions regarding the structure of CC/PP
>documents. It is not addressed by any of Johan's comments to
>issue #174.
>As it currently stands, section 3.1.1 does not yet answer all the
>questions I raised. It does not say explicitly
>- whether an instance of a particular component type can occur only
>  once in a profile Can a profile contain, say, two components of
>  the type HardwarePlatform? Is it valid then?
>- how multiple non-default occurrences of the same attribute with
>  possibly different value are handled.
>- whether nested defaults are allowed/forbidden/discouraged.

>As you may have noticed, all of these questions were raised from an
>XML point of view. It may be that these situations can never occur
>because of the underlying RDF model. If that's the case, an
>explaining sentence would be beneficial. If it's not the case, the
>current WD leaves it open how they have to be dealt with. This is
>much more than just an implementation issue because the spec leaves
>room for different interpretations, and hence interoperability is
>hard to achieve.

>This issue belongs to the same category as  #165 (processing model)
>and #178 (resolution rules). I don't think that it can be considered
>fixed yet.

Graham Klyne:
I think these are fair questions.  My thoughts below:

>- whether an instance of a particular component type can occur only
>   once in a profile Can a profile contain, say, two components of
>   the type HardwarePlatform? Is it valid then?
This question plays slightly differently if you consider it relating to RDF 
or XML.  Since CC/PP is based on RDF, I think it should be answered with 
respect to RDF, noting that multiple XML occurrences may refer to the same 
RDF node if they are labelled with the same rdf:about (or rdf:ID) attribute 
value.

I think it would be simplest to restrict a well-formed CC/PP profile to 
having at most one non-default instance of any component type.

>- how multiple non-default occurrences of the same attribute with
>   possibly different value are handled.
I think it would be simplest to restrict a well-formed CC/PP profile to 
having at most one non-default instance of any attribute value for any 
component type.  Further, I suggest the use of the same attribute with 
different component types is discouraged but not forbidden.

(Historical note:  originally, there was a suggestion that multiple 
instances might be treated as similar in effect to a ccpp:Set of values, 
but that was dropped for simplicity.  IIRC.)

>- whether nested defaults are allowed/forbidden/discouraged.
I think this could go either way without problem.  As it stands, I'd say 
the spec allows nested defaults, and is not ambiguous regarding their 
interpretation.

I suggest:  if anyone has a usecase for nested defaults then allow 
them.  Otherwise discourage or prohibit them.

>This issue belongs to the same category as  #165 (processing model)
>and #178 (resolution rules). I don't think that it can be considered
>fixed yet.
I don't think this issue relates to processing model -- the meaning can be 
defined independently of processing rules.  I agree it relates to 
resolution rules.
Issue 176:
Title: Ambiguities in current specification
Class: Fairly Major
Status:Dissent Overruled
Subject:
It is believed that the present specification leaves the implementor
too many options leading to non-predictable results. Furthermore, the
syntactic ambiguities of RDF as well as the potential abuse of XML
namespaces (which can be redefined within different XML element
scopes) makes automated processing of UAProf information overly
complex without providing augmented capabilities.
Action Class:Disagree
WG Action:
Johan Hjelm: See issue 174.

Graham Klyne: Ambiguities in current specification.  I don't see any 
problem here.

Andreas Schade:
>Originally this paragraph was the summary of my submission. That's
>why it may look as if does not address a particular problem.
>The term "syntactic ambiguities" was intended to comment the fact
>that there isn't a single XML serialization for RDF. I know that
>members of the WG consider this an advantage of CC/PP, but in my
>opinion this makes it unnecessarily difficult to process CC/PP
>documents with a standard XML parser. If you want to, this issue is
>related to #151 and #154. I don't see how any of Johan's comments
>to #174 apply here.
>Suggested status: dissent

Franklin Reynolds:
> This is a general complaint and I am not sure how to respond. What is
> an example of an option leading to non-predictable results. Such an
> option should be fixed. Then there is the complaint about using RDF...

See Issue 151. 
Issue 177:
Title: Matching is undefined in CC/PP
Class: Fairly Major
Status:Outside Charter
Subject:
(These examples are taken from UAProf, but the problem applies to
CC/PP also).

Profile matching is one usage of UAProf advocated in the context
of WAP Push, where the push initiator can require a certain profile 
to be satisfied by the target device. Note however that the behaviour 
of the push-proxy gateway remains underspecified as profile matching 
is currently not defined, nor is the behaviour of a PPG in case of
profile mis-matching addressed.

1. Is the set of allowed values for all properties infinite? For 
example, is an arbitrary literal a correct value for a property of 
the type literal)? Or are there some properties with the constraint
that a valid value must be an element of a subset of all values 
matching the property type. For example, can numeric properties have 
only values of a certain range? Is there a finite set of values for 
properties of type literal/dimension?

2. Many property values are literals. The specification merely 
names examples for these literals rather than providing a final 
enumeration of possible values with attached semantics.

Examples:
"HardwarePlatform/Keyboard"

How should an origin server be able to use such attributes., if one
profile describes a keyboard as "101" and the other one describes it
as "AT keyboard" and yet another one as "ATKEYBOARD". I.e. the
spelling rules for literal values are insufficiently precise for
literal value matching (CC-PP, UAProf deficiencies)

"SoftwarePlatform/VideoInputEncoder"

How about "MPEG-1" versus "MPEG_1" versus "MPEG 1" versus "MPEG1"
versus your favorite choice of spelling? The same for "H.261",
"MPEG-4", "H.263", etc.?

What about punctuation rules, white space handling and case
sensitivity? The "culprits" reside in the CC/PP and UAProf specs.
The solution appears to be exhaustive enumeration of the various
legal literal values or precise lexical rules for literal tokens.

The list of examples can easily be extended with the following
attributes: BluetoothProfile, CPU, Model, AudioInputEncoder,
JavaPlatform, JVMVersion, OSName, OSVendor, RecipientAppAgent,
CurrentBearerService, BrowserName.

3. What is the metrics to be used when matching property values of 
type Dimension (PixelAspectRatio, ScreenSize, ScreenSizeChar)?
Action Class:Supplementary document
WG Action:
Johan Hjelm: See issue 174

Graham Klyne: Matching is undefined in CC/PP.  I tend to agree, 
but the original WG took a view that the content provider (e.g. 
origin server) would know how to resolve this based on its 
knowledge of the properties.

Andreas Schade:
>Profile matching involves (among other things) comparisons at the
>level of attribute values. A server processing a received CC/PP
>profile does something similar: It generates content based on the
>comparison of attribute values contained in the profile with some
>fixed values. (If "text/html" is contained in CcppAccept. then...)

>A data model for CC/PP is required in order to solve this problem
>(issue #164). Based on this data model a schema must define
>- the type of the components that can be part of a profile of the
>  schema,
>- which attributes are allowed for each of these components,
>- the data type of the attribute values,
>- and the set of allowed values (issue #170).

>Without that, attribute values are difficult to compare since the
>server would have to deal with all sorts of different spellings
>for a value. If "Support for the described formats for attribute
>values" is only *RECOMMENDED" as section 4 states, it may be
>possible that all attribute values are regarded as strings, which
>makes value comparisons even harder.
>From the comments on this issue it is not clear to me what the WG's
>position is.
>Suggested status: dissent

Graham Klyne:
In early discussion, the working group's position was that the set of 
allowed values and their meanings would be determined by the data 
provider's (i.e. origin server in HTTP) knowledge of specific attributes used.

(I tried to argue for a more general approach, but did not succeed because 
(I understand) that was felt to be too great a departure from UAProf.)

As for the type of components that can be part of a profile:  it's covered 
to the extent that they are all instances of ccpp:Component.  But there is 
--correctly in my view-- no limit of the number and type of components that 
can appear.

I think it's clearly an aspect of the goal of extensibility that we don't 
know in advance all the attributes or components that can appear in a profile.

Franklin Reynolds:
After filtering out the UAProf concerns, I understand the remaining
issues here to be the lack of support for constrained types and values. 
This is true. We have been hoping that eventually RDF and XML
Schema people would resolve their differences so that we can use XML
Schema based tools to constrain types and values. We are not there yet,
and I don't think we should hold up the spec waiting for them to
finish. Instead, we should generate a new version of the spec that
addresses these concerns once the XML Schema vs. RDF schema dust has
settled.
Issue 182:
Title: Use of proxies in CC/PP
Class: Fairly Major
Status:Request Approved
Subject:
Various issues dealing with proxy chaining and proxy behavior have
already been addressed  (12, 17-22, 33, 37, 38, 40, 120, 157, and
158). Having looked a bit more carefully at the WD as it currently
stands, I have another question regarding the use of proxy-behavior
profiles which is particularly related to issues 12, 18 and also 178
resolution mechanisms).

ProxyAllow/proxyBlock represent attributes added to/removed from the
client profile. These modifications can be made conditional using the
applicability construct. It is obvious that the applicability
condition must be expressed in the same vocabulary as the client
profile (since otherwise it could not be computed). Unlike
applicability, proxyAllow and proxyBlock may use different vocabularies
than the client profile (in fact, they do in the WD examples). If this
is the case, the server receiving the profile cannot simply resolve the
request profile (= client profile + proxy changes) based on the request
profile structure, but must be able to determine semantic equivalence
of properties possibly belonging to multiple different vocabularies!
In my opinion, this is too much to ask for.

Interestingly enough, section 2.1.4 shows an example in which both the
client profile and the proxy behavior use the same vocabulary (i.e. the
same namespace) to describe attribute values. Here my point does not
apply but the spec does not mandate to use the same namespace in client
and proxy profile.

The problem becomes apparent in section 3.2.2.1 (even though the client
profile is not shown) Suppose the client profile uses the UAProf
vocabulary - it should do so since otherwise the applicability construct
would never match. ProxyAllow adds new attributes using the ccpp-client
vocabulary. Now, based on what knowledge is the server that receives
such a profile supposed to figure out that the additional mime types
specified in ccpp-client:type in proxyAllow are meant to extend the
CcppAccept value in the client profile?

The problem could be avoided if the spec mandates the proxies to use the
same vocabulary as the client profile they modify. But even with the
same vocabulary for the client profile and the proxy behavior element,
the resolution problem raised in issue #158 remains unsolved.

Maybe it is a good idea to enable a proxy to modify a profile, maybe it
isn't. The client does not have a chance to say that it wants its
profile to arrive at the server as is. If some proxy feels it knows
better it will modify the client profile. Given this immaturity, I tend
to support issue #157 which proposed to avoid proxy capabilities.
Personally, I'd prefer profile-diffs plus resolution policies a la
UAProf although this is not as powerful as the proxy behavior idea
(attributes cannot be removed). I agree with your point in issue #158:
Proxy behavior will only work with an appropriate processing model in
place.
Action Class:Fix
WG Action:
Graham Klyne:
I just reviewed that, and it seems to be based on a fundamental 
misunderstanding:
[[
ProxyAllow/proxyBlock represent attributes added to/removed from the
client profile. These modifications can be made conditional using the
applicability construct. It is obvious that the applicability
condition must be expressed in the same vocabulary as the client
profile (since otherwise it could not be computed). Unlike
applicability, proxyAllow and proxyBlock may use different vocabularies
than the client profile (in fact, they do in the WD examples). If this
is the case, the server receiving the profile cannot simply resolve the
request profile (= client profile + proxy changes) based on the request
profile structure, but must be able to determine semantic equivalence
of properties possibly belonging to multiple different vocabularies!
In my opinion, this is too much to ask for.
]]
-- http://www.w3.org/Mobile/CCPP/Group/CR/issues-2002-07-24.html#no182

The idea that the different aspects of proxy capabilities use different 
vocabularies that must somehow be matched is not true.  It is possible that 
a proxy capability may add or block a feature that is not mentioned in the 
original profile.  For example, if a proxy can do PDF-to-JPEG content 
transformation, then it may contain a proxy-allow that adds a capability 
corresponding to PDF-receiving capability, even though no such capability 
is mentioned (or even known) to the client who advertises JPEG receiving 
capability.

It is presumed the server that receives the profile will understand or 
ignore all of the vocabulary used.  So, if the server sees a capability for 
receiving PDF, it may understand that capability and generate PDF, or it 
may not understand that capability and generate something that corresponds 
to the declared capabilities that it does understand.

I also presume that, in general [**], all components will use and 
understand the same vocabulary to refer to the same capabilities.

([**] I say "in general": exceptions are possible.  The design of CC/PP is 
such that the data provider --origin server, or whatever-- is presumed to 
understand all the capability vocabulary sufficiently to generate 
appropriate content for the client.  If different terms are being used to 
describe the same capability, the data provider may take this into 
consideration.  Personally, I'd prefer a design which made the whole 
capability matching process more explicit, but that is inherently different 
to the design of UAProf, and was not the group's consensus.)

This part of the comment:
[[
Interestingly enough, section 2.1.4 shows an example in which both the
client profile and the proxy behavior use the same vocabulary (i.e. the
same namespace) to describe attribute values. Here my point does not
apply but the spec does not mandate to use the same namespace in client
and proxy profile.
]]
I think completely misunderstands the roles of vocabularies and 
namespaces.  A system component understands some particular set of terms 
which may or may not be declared in a single namespace.  Understanding some 
terms from a given namespace does not necessarily mean that all such terms 
are understood.  (It may be that for some applications, all-or-nothing 
understanding of a namespace is needed, but that doesn't apply to feature 
vocabularies.  To require all-or-nothing understanding doesn't bring any 
advantage that I can see, and would seriously impair graceful extensibility.)

[[
The problem could be avoided if the spec mandates the proxies to use the
same vocabulary as the client profile they modify. But even with the
same vocabulary for the client profile and the proxy behavior element,
the resolution problem raised in issue #158 remains unsolved.
]]
As I say above, that is presumed, but maybe this could be made 
clearer.  Suggestion below.

As for issue #158... I fundamentally disagree with the point made.  The 
reason it may seem complex in the example given, to my mind, is because it 
tries to map something that is simple in terms of the RDF data model onto a 
completely representation based on XML lexical structures.  ...but I 
already said all that.

[[
Maybe it is a good idea to enable a proxy to modify a profile, maybe it
isn't. The client does not have a chance to say that it wants its
profile to arrive at the server as is. If some proxy feels it knows
better it will modify the client profile. Given this immaturity, I tend
to support issue #157 which proposed to avoid proxy capabilities.
Personally, I'd prefer profile-diffs plus resolution policies a la
UAProf although this is not as powerful as the proxy behavior idea
(attributes cannot be removed). I agree with your point in issue #158:
Proxy behavior will only work with an appropriate processing model in
place.
]]
This comment seems to misunderstand the proxy chaining design.  The whole 
idea was to ensure that proxy capabilities can be included without changing 
the original client profile -- the motivation for this was to allow 
checking of client profile descriptions.  Also, this way of describing 
proxy capabilities explicitly does NOT depend on a processing model, unless 
you include the implicitly sequential nature of proxy processing on the 
path between sender and receiver (and that is explicitly acknowledged in 
the spec, appendix F).  See below for a suggestion to emphasize this point.

As for the "profile-diff" idea, I strongly feel (as I have stated 
elsewhere) that that is a broken mechanism.  Part of the architectural goal 
here should be to separate profile representation from the protocol used to 
transfer it.  Profile-diff (as I have seen it proposed for the CC/PP 
protocol) muddles these to important and distinct concepts, and in my view 
it's widespread adoption would effectively make CC/PP useless for use with 
any protocol other than HTTP.

Summary:

I think there may be a need for some words in the proxy capability section...

I suggest adding the following sentence to the second paragraph of section 3.2:
[[
The proxy behaviour description is intended for use by intermediaries whose 
operational characteristics match those described in Appendix F of this 
document.
]]

I suggest including these additional paragraphs at the end of section 
3.2.2, just before 3.2.2.1 (based on 
http://www.w3.org/TR/2001/WD-CCPP-struct-vocab-20010315/ version of the 
document):
[[
In a proxy capability description, 'applicability', 'proxyAllow' and 
'proxyBlock' are all presumed to refer to capabilities and preferences 
using the same attribute vocabulary.  It is particularly significant that 
an 'applicability' value uses vocabulary in common with the client profile.

But note that a proxy may introduce a capability that is otherwise unknown 
to the client (e.g. file format transcoding), in which case an attribute 
vocabulary term must be used that does not appear in the client's profile, 
and which may not be recognized or understood by the client system.  This 
idea is illustrated by example 3.2.2.1.

Similarly, a proxy may unconditionally block capabilities which the client 
does not declare (e.g. file format blocking), in which a proxy-block may 
mention an attribute that does not appear in the client profile.  This is 
illustrated by example 3.2.2.3.
]]

Franklin Reynolds: 

I have no problem with Graham's proposed changes. 

But, I can't help but think that part of the problem is confusion over
the intended behavior associated with a proxy-profile. After 
rereading section 3.2.2, it seems to me that the intended semantics 
of allow, blocks and applicability are not as clear as I would like.

The question that came up is whether proxy-profiles are intended to 
explicitly describe the behavior of proxies or are they intended 
achieve this implicitly by modifying client profiles? The difference 
may not be obvious, so I will try to explain.

When reading example 3.2.2.3, it sounds like a proxy that blocks 
jpeg is telling a server that the proxy will discard jpeg content.
This is an example of the proxy advertising its own behavior.

However, if the blocks statement is supposed to be interpreted as
modifying a client profile so that explicit support for jpeg has 
been removed, we end up with different behavior. This is because a
server might not assume a client does not support jpeg just because
jpeg support is not explicitly mentioned. Removing jpeg from a 
list of supported types is not the same as asserting that jpep
is not supported.

I believe the UAProf work emphasized modifying the client's profile
(using profile-diffs) and the CC/PP work does not. My understanding 
is that CC/PP  proxy-profiles describe the behavior of the proxy, 
they do not modify the client profile.

If UAProf implementers are making this mistake, I suggest the 
following changes to the spec:

original third paragraph in section 3.2:

"This approach to describing proxy behaviors does not force a proxy 
to analyze and rewrite a client profile. Rather, the applicability, 
proxyAllow and proxyBlock properties allow a proxy describe its 
behavior in a way that takes account of a client's capabilities. 
As a result, the structure is very easy for a proxy to create, though 
it does place some additional responsibility on an origin server to 
analyze and combine the various parts appropriately."

proposed change:
"A proxy profile describes the behavior of a proxy using proxyAllow 
and proxyBlock properties. The applicability property can be used as
a sort of matching rule to indicate which clients are affected by the 
proxyAllow and proxyBlock properties. The structure of a proxy profiles 
tend to be quite simple and they can be created without analyzing 
each client profile.

Unlike UAProf proxies which attempt to create "profile-diffs" which
modify the client profile of each request, a CC/PP proxy simply creates 
a profile that describes its own behavior. The origin server has 
responsibility for analyzing the capabilities of the client profile 
and each, if any, associated proxy profiles to determine what sort of 
content is appropriate. Since the order in which proxies are encountered 
can have an effect on end-to-end behavior, a "capability chaining" 
mechanism is defined to describe the order in which proxies are 
encountered."

The only reason I suggest adding the explicit reference to UAProf 
proxies and profile-diffs is because I think the UAProf community 
is misunderstanding how CC/PP proxies are intended to work. If this
is not the case, then my changes are unnecessary...

Graham:

I think some clarification of proxy profiles is indeed desirable.

I think you're correct in saying that the proxy profile does not modify the 
client profile.  (I take this as a foregone conclusion if signed client 
profiles are to reach the server intact.)  So it seems I must agree that 
the proxy profile describes the proxy behaviour.

I'm slightly uncomfortable with this, because my focus has been on 
presenting an effective profile to the data provider (origin server) 
without getting into details of how the various receiving components 
work.  So I'd be more comfortable with saying that the proxy profile 
describes the effect of the proxy behaviour (in terms of how it modifies 
what the provider can send and have it usable by the recipient), but I 
guess that's a small change, and I don't feel empahtic about it.

Let's see how this plays with your proposed change:
[[
A proxy profile describes the effect of a proxy using proxyAllow
and proxyBlock properties, in terms of how it modifies what the
origin sender can send and have it usable by the client.
The applicability property can be used as a sort of matching rule
to indicate which clients are affected by the
proxyAllow and proxyBlock properties.
Proxy profiles have a simple structure, and can be created
for each proxy without regard for the client profiles with
which they may be used.

Unlike UAProf proxies which attempt to create "profile-diffs" which
modify the client profile of each request, a CC/PP proxy simply creates
a profile that describes the effect of its own behavior.
The origin server has responsibility for analyzing the capabilities
of the client profile and each, if any, associated proxy profiles to
determine what sort of content is appropriate to send.
The order in which proxies are encountered can have an effect
on end-to-end behavior, and a "capability chaining" mechanism
reflects the order in which proxies are encountered.
]]

I think something like this may more clearly explain what is happening, even
without explicit reference to UAProf; e.g.
[[
A proxy profile describes the effect of a proxy using proxyAllow
and proxyBlock properties, in terms of how it modifies what the
origin sender can send and have it usable by the client.
The applicability property can be used as a sort of matching rule
to indicate which clients are affected by the
proxyAllow and proxyBlock properties.
Proxy profiles have a simple structure, and can be created
for each proxy without regard for the client profiles with
which they may be used.

A CC/PP proxy does not modify the client profile in any way, but
creates a profile that describes the effect of its own behavior.
The origin server then has responsibility for analyzing the
client profile and each, if any, associated proxy profile to
determine what sort of content is appropriate to send.
The order in which proxies are encountered can have an effect
on end-to-end behavior, and a "capability chaining" mechanism
reflects the order in which proxies are encountered.
]]

 From recollection, I think these changes are consistent and not 
overlapping with the other clarifications I suggested.

For myself, I prefer the second proposed wording above, which is closely 
based on Franklin's proposal quoted below.

Johannes Koch http://lists.w3.org/Archives/Public/www-mobile/2002Nov/0010.html

Error in Figure 2-3b 20 November 2002
Issue 183:
Title: Error in Figure 2-3b
Class: Minor
Status:Request Approved
Subject:
In Figure 2-3b: the ccpp:defaults/@rdf:resource attributes don't 
match the rdf:Description/@rdf:about attributes in the default XML files 
below
Action Class:Fix
WG Action:
Issue 184:
Title: Headers to retrieve CC/PP Schemas
Class: Editorial
Status:Publication Issue
Subject:
in 2.2 Extensibility and namespaces:
   in the Note following the schema links: Why not serve the schemas as 
'application/rdf+xml' (and expect applications reading the schemas to 
send an appropriate Accept header) and serve an HTML (commented?) 
version of the schemas for HTML clients?
Action Class:Publication Issue
WG Action:
See also issue 113.

Franklin: 
I have no objection to this change, but I don't think it is 
important and I don't think it affects the document.

Mark: Publication issue, doesn't effect the spec.

Graham:
Well, maybe, but the application/rdf+xml isn't registered yet, and is 
likely to be a couple of months yet.

David Ezell (XML Schema) http://lists.w3.org/Archives/Public/www-mobile/2003Feb/0000.html

Missing major heading 11 February 2003
Issue 203:
Title: Missing major heading
Class: Editorial
Status:Request Approved
Subject:
the table of contents appears to be missing major heading for section 2.
Action Class:Fix
WG Action:
Issue 204:
Title: Compound Types
Class: Minor
Status:Request Approved
Subject:
the following example contains a problematic simple type (figure
   2-4b)

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://www.example.com/schema#">
  <rdf:Description
      rdf:about="http://www.example.com/profile#HWDefault">
    <rdf:type
        rdf:resource="http://www.example.com/schema#HardwarePlatform" />
    <ex:displayWidth>320</ex:displayWidth>
    <ex:displayHeight>200</ex:displayHeight>
    <ex:memory>16Mb</ex:memory>
  </rdf:Description>
</rdf:RDF>

Describing memory as "16Mb" implies a "compound simple type" where the
unit of measure (mb) co-resides with the value (16).  The Schema WG 
tried and failed to produce a workable method for producing such 
compound types, and the reasons for that failure were very technical 
and non-trivial.

[N.B. the editor of this note was once a strong proponent of
such types, but in the end understood the issues preventing their
inclusion in the REC, and did not object to their omission.]

Our experience is that "compound" values, such as "16Mb", are better 
expressed as separate simple values.

     <ex:memory-value>16</ex:memory-value>
     <ex:memory-unit>Mb</ex:memory-unit>

While the RDF syntax makes this expression slightly more cumbersome than
it might be otherwise, we believe that it helps clarify what kinds of 
simple values are actually definable.

We respectfully suggest that the examples be changed to represent the
state of what's possible with simple types.  Note that this use pattern
appears in several examples, and not just the one quoted.

[N.B. mapping this type to a single value-space (i.e. to create
a simple type) would involve describing canonical lexical representations
for all values.  Please consider such simple type construction as a second 
alternative, along the lines described below for "rational" in item 6.
Such a construction would require restricting the allowed "suffixes"
using a pattern facet (regular expression).]
Action Class:Fix
WG Action:
Graham Klyne:
I agree this is potentially problematic, but this kind of thing was 
discussed at the time.  This value does not claim to be any datatype (in 
the XSD sense) other than a string value that the server interprets.  It is 
a form inherited from UAProf.

Franklin Reynolds:
compound types, such as 16mb, exist to be compatible with UAProf

CR telecon:
One of the constraints on CC/PP is UAProf compatibility. Compound datatypes
are already widely used in UAProf: for example the Dimension datatype or the
CcppAccept property in
http://mobileinternet.panasonicbox.com/UAprof/GD67/R1.xml 
although we note the later usage may not be in keeping with the UAProf
specification. 

Therefore the CC/PP WG decided it could not ban the usage of composite
literals, but could add some wording to the WD to strongly advise against
their usage (although Graham Klyne noted that he thought the WD already had
wording to that effect) and remove any examples using compound literals.
Issue 205:
Title: Case Insensitive Text
Class: Minor
Status:Request Approved
Subject:
section 4.1.1.2, concerning "case-insensitive text"

Unfortunately, there is no direct way to designate a type based on such
a character set (for purposes of matching and ordering) as a simple type.
Further, while using such a type is slightly more convenient for hand
editing, it arguably adds little real expressive value, and in fact
creates problems for interoperability since it can't be designated as
a type.

Some of the reasons for this restriction on type creation follow.
Based on the work of our members and on comments from other experts, 
we know that case folding is dependent on both language and locale:  in 
Quebec (for example), the uppercase equivalent of '&eacute;' is '&Eacute;', 
but in metropolitan France it is 'E'.  In most countries using the
Latin alphabet, the upper case equivalent of 'i' is 'I', while in Turkey 
it is uppercase-dotted-i (and the lower-case equivalent of 'I' is 
lowercase-i-without-a-dot).  

Further, it can be argued that case sensitivity is less likely to
surprise users, since in XML case sensitivity is the rule.

While the introduction of case-insensitive text was probably intended 
to be a simplifying measure, it seems to us that defining it properly 
would introduce a great deal of complication for very little gain, at 
a large cost in interoperability.

We respectfully suggest that you eliminate this type.
Action Class:Fix
WG Action:
Graham Klyne:
This type was introduced for compatibility with parts of the IETF conneg 
work.  In practice, it is not used with anything other than ASCII 'A'-'Z' 
and 'a'-'z' letters, so the problems noted here could be avoided by making 
that restriction explicit -- i.e. rather than describing it as "case 
insensitive", indicate that it is intended to be used with a restricted 
repertoire of characters, and that for purposes of comparison the ASCII 
characters 'A'-'Z' are considered equivalent to 'a'-'z'.

An example of this kind of value would be a language tag, per RFC 
3066.  Also, the CONNEG-registered features for colour capability is such a 
token.

Franklin:
This deals with CONNEG vocabulary interoperability

CR telecon:
It was concluded that CC/PP should adopt the advice of the XML Schema
Working Group, and avoid using case-insensitive types. As the prime
motivation for including case insensitive types was compatibility with IETF
Conneg, it was established that a requirement on CC/PP exiting CR would be
that the CC/PP WG had demonstrated that Conneg profiles that used case
insensitivity could be mapped to case sensitive CC/PP profiles.
Issue 206:
Title: Case folding in token
Class: Minor
Status:Request Approved
Subject:
section 4.1.1.2, concerning "token" 

The same objection to case folding applies to this type, with an added issue
as to why such a type should be constrained to US-ASCII?  The type xsd:token
(in XML Schema Part 2 [2]) has proven to be a good base from which to 
restrict enumerations.  We understand that you may have some specific use
cases of which we are not aware.

To reduce confusion, we request that you use "token" in the same sense as
XML Schema or use a different term for your case-insensitive ASCII token.
Action Class:Fix
WG Action:
Graham Klyne:
Same comment as issue 205.

Franklin:
This deals with CONNEG vocabulary interoperability

CR telecon:
Same comment as issue 205.
Issue 207:
Title: Integer Number
Class: Minor
Status:Request Approved
Subject:
section 4.1.1.3 Integer number

The XML Schema Part 2 REC defines an "xsd:int" type which seems identical
to the one you define.  Please note that xsd:integer is unconstrained in
value whereas xsd:int is constrained *almost* exactly as you have defined
it, with the exception that the minInclusive facet of the datatype is set
to -2147483648 (as opposed to -2147483647).

We respectfully suggest that you clarify that xsd:int is the desired type, 
and modify the prose to be consistent with XML Schema Part 2 [2].
Action Class:Fix
WG Action:
Graham Klyne:
Maybe... but I note:

(a) the restricted range of values was a recommendation rather than an 
absolute limit.

(b) the choice of -2147483647 rather than -2147483648 was deliberate, since 
it avoids some strange edge conditions, and the integer is intended to be a 
way of representing quantities, not bit-mask values.  I think some 
programming languages restrict 32-bit integers in this way (I can't 
remember which, offhand).

Franklin:
I can't remember any specific reason for the -2147483648 vs   
-2147483647 decision.
Unless someone has a strong objection, I think we can safely adopt the
recommendation. 

CR telecon:
Again here the disagreement was about whether to adopt a representation
compatible with CONNEG or with XML Schema. Based on the previous issue, it
was decided to adopt the XML Schema WG's advice but to have the requirement
of demonstrating that IETF Conneg could be mapped to CC/PP.
Issue 208:
Title: Rational Number
Class: Minor
Status:Request Approved
Subject:
section 4.1.1.4 Rational number

We indicated in item 2 (above), that two-part values are often better expressed
as two separate values.  However, rational number may be represented as a
user defined (or in this case, WG defined) simple type, as follows:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
        
targetNamespace="http://www.w3.org/TR/2002/WD-CCPP-struct-vocab-20021108/">
        <xs:simpleType name="rational">
               <xs:annotation>
                       <xs:documentation>
                               The canonical lexical representation of any
value 
                               will be the form of the value reduced to its
lowest 
                               common denominator, and with '1' in the
denominator 
                               if applicable.
                       </xs:documentation>
               </xs:annotation>
               <xs:restriction base="xs:string">
                       <xs:pattern value="[0-9]+(/[0-9]+)?"/>
               </xs:restriction>
        </xs:simpleType>
</xs:schema>

Note that the "c14n" should probably be further elaborated:
Lexical value        Canonical Lexical Rep.
=============        ======================
    "3/6"       ==>        "1/2"
    "15"        ==>        "15/1"
etc.

We believe that people will find this definition useful.  

However, the above definition only solves one half of the problem, i.e. that
it describes *only* the lexical representation.  Binding a lexical
representation to
a value space (unfortunately) is not easy; it requires operator definition, and 
must be carefully described since processors which understand simple types will 
be expected to do the arithmetic.  Such expectations are (we believe) essential
for interoperability.

We invite you to raise the issue of the need for a rational number with the
XML Schema WG, since that is the only way this issue can really be resolved.
In the meantime, we suggest that you note in the REC that use of this rational 
type may be harmful to interoperability.
Action Class:Fix
WG Action:
Graham Klyne:
I note that I *did* raise this issue with XML schema when it was in 
last-call, and my representation was rejected.

The reason for requiring a rational type in CC/PP was so that the work 
(already done at the time) of the IETF CONNEG working group could be 
accommodated within CC/PP:  we (CONNEG) found that rational numbers were a 
useful way to represent values such as resolution which might be expressed 
in pisels per inch or per cm.  In this case, absence of a rational number 
would be harmful to interoperability.

Franklin:
This deals with CONNEG vocabulary interoperability

CR telecon:
After some discussion, it was determined that dealing with rational numbers
was a lot harder than the CC/PP WG had envisioned. Therefore the WG decided
to add some text to the WD, using the submission from the XML Schema WG. In
addition it was decided that an important exit criteria for CR was the
demonstration of interoperability tests that operate on this datatype, such
as equivalence.
Issue 209:
Title: Trailing in # in hyperlinks
Class: Editorial
Status:Request Approved
Subject:
section 2.2 (html editorial issue)

The anchor (hyperlink) for http://www.w3.org/2002/11/08-ccpp has the trailing
'#' in bold.  [ed. note:  I believe this variation is invisible in some
browsers.]
Action Class:Fix
WG Action:
Issue 210:
Title: Editorial
Class: Editorial
Status:Request Approved
Subject:
section 4.1.2.2 (editorial blip)

The sentence "Compare the above attribute value, which is a sequence containing
one
element, with the a simple value as shown in figure 4-5 above." has "the a"
after
the second comma.
Action Class:Fix
WG Action: