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:
>Other xml document types I believe XML should be capitalized here.
No details
> this document is created from merge of I believe you mean "this document is created from the merge of" (notice the added "the").
No details
> HTML <alt> tags There is no HTML <alt> tag (that I know of). I believe you mean the alt attribute.
No details
> 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?
Fix: add link to definition
> Section 2 provides [...] It would be nice if these section references were links.
No details
> 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.
use the phrase "CC/PP attributes" rather than just "attributes"
> another RDF resource names 'Object-resource'. I believe you mean "named" not "names".
No details
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"
The examples check out in SiRPAC. Use entity reference syntax (&xxx;) to indicate that the names are placeholders
In Figure 2-1b, you omit the rdf: prefix on the about attribute of the third ccpp:component.
No details
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.
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.
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.
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.
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?
Offer better example
> 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.
Fix consistency
> see Section 6.2.1. In the same section, this reference is also unlinked.
No details
Figure 2-12 is a broken image (404).
No details
>> 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.
Fix: Ralph or others about RDF fragment naming makes sense
> 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.
No details
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.
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.
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.
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.
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)
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.
> <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.
change URI strings to URIs
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?
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.
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.
Change URI strings URIs
WRT 4.1.1: How come there's no decimal? It'd be really nice to say HTMLVersion > 2.1 or some such.
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.
In A.1 the term Anonymization isn't bolded like the rest.
No details
> Some communication process that provides definite and tamper-proof > information about the identity of a communicating party. Why is there a line break there?
No details
> 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...
No details
> rdfs:Literal > ccpp:URI {A URI value of a CC/PP attribute} A URI is not a literal, but a resource
No details
> accessed, the parties with > whom communication occurs, etc. yet another!
Change URI string to URIs
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.
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.
Also, why do you declare your own ccpp:Resource? It doesn't seem you get any benefit from that, but simply pollute the namespaces.
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.
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!
Remove an xml base URI within the schema document.
> 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.
No details
> 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.
Change URI string URIs
> This class is used to represent any CC/PP attribute value that > is arbitrary text. How is this different from literals?
literals is atomic string values.
You may also want to declare that the Defaults property is deprecated, or some such.
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.
> 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.
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.
> 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.
Clarify Philipp: > text has changed Aaron: > 38: Don't remember what I meant. Can live with.
> 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.
No action
> 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.
>Editorial Clarifications
> NOTE: the proxy vocabulary described later [...] Actually, I believe it was defined "above".
No details
>[...] 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.
No details
> We recommend [interCap style] be used for CC/PP attribute names Then how come all your attributes are hyphenated?
Fix (allow hyphenating attributes)
> 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
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
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.
No details
Also, why don't talk about CCPP in HTTP, or at least point to the note?
Add reference to the mailing list to show that is ongoing work, instead of the Note.
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.
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.
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.
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.
You will of course want to stick copies of your schema in your namespaces.
Putting schemas and examples in separate files and added pointers to them. Publication issue
> 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/
No details
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.
Fix: publication issue
Phew, all done. Does this mean I get to go in the acknowledgments section? ;-)
Thank him 52 times.
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/
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.
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.
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.
3. Why isn't there an RDF schema at: http://www.w3.org/2000/07/04-ccpp#
Add links to those documents.
4. The image "constraints.png" seems to be missing.
No details
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.
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.
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.
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.
1.3.2 - remove the RDF tutorial info and instead refer to the relevant RDF specs/docs (e.g. RDF Primer).
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.
Get CC/PP added to the RDF Primer's list of RDF Applications.
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.
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.
Should explicitly state whether Appendices are Normative or Informative.
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.]
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.
2.2 - define "CC/PP expression"
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.
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).
2.3 - remove all of the RDF tutorial info in this section (and subsections); alternatively, add references to the relevant RDF specs/docs.
Same as issue 186 Graham: Yup. Art: same as 186
* 3.2 - move all of this stuff to a new chapter on Proxies (include any info from 2.1.4 that is not redundant).
Same as issue 190. Graham: It already is separate, I thought. Art: log it for next version
* 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.
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.
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).
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.
* 6.1 - RDFSCHEMA - add this doc is a Candidate Recommendation
* 6.2 - there appears to be a formatting bug in the UAPROF ref
* 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.
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.
* B.3 - why are there two definitions of the anyURI Class? Which definition is resolved when an application refers to ccpp:anyURI?
Mark: There are a few errors in this schema, particularly duplications and errors in comments. Check and fix.
* C. - instead of using "mandatory", use RFC2119 language.
* D.1 - add a definition of "CC/PP parser"
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"?
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).
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.
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.
Same as Issue 57. Published W3C WD, CC/PP Implementors Guide: Privacy and Protocol.
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?).
Seems to be based on his using an old document. Reported issue does not arise in the current public version.
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)
Same as Issue 59.
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.)
Same as Issue 59.
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 )
Fix: publication issue
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
No details
HTML Tidy set to not indent will reduce the file size by 10%. (see http://www.w3.org/People/Raggett/tidy/)
No details
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.
No details
Also in Appendix A, I would try to reword anything borrowed from WAP or other sources unless it was W3C's content originally.
No details
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)
No details
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.
No details
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.
No details
Globally, web -> Web
No details
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.
No details
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)"?
No details
The p following Figure 3-10 should start outside the dl.
No details
Abstract list item 3: "xml" should be "XML".
No details
Status section: "working group" (five times) should be "Working Group" (see cAPItalization in the W3C Process Document http://www.w3.org/Consortium/Process/).
No details
Status par. 2: "November 14 ," should be "November 14,"
No details
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)
No details
Status par. 4: "minutes(Member-only link)" should be "minutes (Member-only link)"
No details
Status par. 3: "W3CDevice Independence activity" should be "W3C Device Independence Activity" (two changes)
No details
1. par. 5: "in the Appendix F" should be "in Appendix F"
No details
In 1.3.1 par. 4, the key words REQUIRED, RECOMMENDED and OPTIONAL are missing.
No details
2.1.4 par. 4: "each of which, needs" should be "each of which needs"
No details
2.1.4 par. 5: "To indicate sequence of proxies" should be "To indicate a sequence of proxies"
No details
2.3.1 par. 6: "meaning, defines" should be "meaning, and defines"
No details
2.3.1 par. 6: "[4]" should be "<a href="#%5B4%5D">[4]</a>"
No details
2.3.1 par. 7: "data type" should be "data type"
No details
2.3.2 par. 5: ""basic RDF serialization syntax." should be ""basic RDF serialization syntax."" (note the quotes)
No details
2.3.2 par. 6: "abbreviation forms" should be "abbreviated forms"
No details
2.3.2 par. 6: "XML forms. using" should be "XML forms. Using"
No details
2.3.3 par. 2: "RDF schema" should be "RDF Schema" (shorthand name of the spec. would be cAPItalized, otherwise schema would be lowercase)
No details
2.3.3 par. 4: "Specific" should be "Specific"
No details
2.3.3 par. 6: "The RDF Schema" should be "RDF Schema" or "The RDF Schema specification"
No details
2.3.3 Figure 2-12 img alt text: "RDF Schema" should be "RDF schema"
No details
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)
No details
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
No details
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"
No details
4.1.1.2 Tokens par. 2: "upper and lower case" should be "upper and lowercase"
No details
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.
No details
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;"
No details
6. [7]: "Internet draft" should be "Internet-Draft"
No details
6. [12], [13], [14]: "XML schema" should be "XML Schema" [also these are PRs as I imagaine you know]
No details
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.]
No details
A.1 Cacheable: "sever" should be "server"
No details
A.2 HTML: "Hyper Text Markup Language" should be "HyperText Markup Language"
No details
A.2 HTTP: "Hyper Text Transfer Protocol" should be "Hypertext Transfer Protocol"
No details
A.2 P3P: "Project for Platform for Privacy Preferences" should be "Platform for Privacy Preferences Project", or "Platform for Privacy Preferences"
No details
A.2 XHTML: "Extensible Hyper-Text Markup Language" should be "Extensible HyperText Markup Language"
No details
A.2 XSL: "Extensible Style Language" should be "Extensible Stylesheet Language"
No details
D.3.1 heading: "don't: reuse" should be "reuse"
No details
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"
No details
D.3.5 par. 1: "lower case" should be "lowercase"
No details
.3.5 par. 2: "upper case" should be "uppercase"
No details
E. par. 1: "vocabularies" should be "vocabularies."
No details
W.: "20010223 Published as First Working Draft." should be "20000223 ? Published as first Working Draft."
No details
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>.
Add section addressing this: including the use cases
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#")
There is no default namespace, no namespace prefix
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.
Delete D.3.2 - Components used in proxy description is typed.
Also in Appendix C, is "charHeight" really the "number of lines of text" that can be displayed ?
No details
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...
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?
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.
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.
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
No details
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 :-)
No details
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.
No details
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.
No details
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.
No details
figure 2-4b: Overriding a default value in XML Ditto default xmlns in both examples
No details
In 'Note' just at end; relative URIs can be used in RDF but not recommended for namespaces - the latter is my opinion.
Fix namespace reference
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
Uniform examples are used
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.
No details
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.
No details
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?
No details
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
Same as issue 128
2.3.3 RDF schema Can you add a link to the RDF schema document here since this is the first discussion of it.
No details
3.1.3 Defaults In examples here using no rdf: prefixes on Description, type elements or about, resource attributes. So why declare xmlns:rdf ?
Same as issue 128
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!
Old document problem. (fixed in this version)
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
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.
3.2.1 Capability chaining examples back to rdf: everywhere again
Same as issue 128.
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?
Same as issue 121
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.
No details
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.
Same as 128
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).
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
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
Put them all in separate files so they can be referenced.
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.
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.
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.
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.
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?
No details
.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
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.
Correction of xml:lang handling Further discussion
we agree to make it so. Change em to en
Editorial changes
No details
Editorial changes
No details
Editorial changes
No details
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.
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.
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!
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.
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>
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.
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?
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.
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.
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.
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.
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.
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.
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.
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?)
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.
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.
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"
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.
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"
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.
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.
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.
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.
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?
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.
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.
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"
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?
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.
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.
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".
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.
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.
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.
Graham Klyne: (again), more on protocol, out of scope. Mark: See previous issue.
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
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".
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.
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".
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.
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".
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.
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".
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.
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".
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.
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.
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.
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
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.
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.
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?
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" ]]
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.
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.
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?
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.
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.
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.
(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)?
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.
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.
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.
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
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?
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.
the table of contents appears to be missing major heading for section 2.
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).]
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.
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 'é' is 'É', 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.
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.
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.
Graham Klyne: Same comment as issue 205. Franklin: This deals with CONNEG vocabulary interoperability CR telecon: Same comment as issue 205.
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].
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.
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.
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.
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.]
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.