This Test Suite was designed to demonstrate that all the features in the CC/PP: Structure and Vocabularies specification is implementable, and that at least two implementations are interoperable. Individual implementations must have been developed independently by different organizations.
Each test in the Test Suite must have at least two passing implementations. It is not required that any implementation pass all of the tests. The interoperability data is not intended to be used for assessing or grading the performance of any individual implementation. This Test Suite is focused on CC/PP specific features. It does not test RDF features that are not in CC/PP.
There are three classes of applications of CC/PP that can be tested:
Documents may exist as resources accessible via a URL, or may be transmitted as data in a message. The table below lists valid CC/PP profile features. Sample profiles are provided as examples of valid CC/PP profiles exhibiting the corresponding feature and invalid CC/PP profiles violating the corresponding feature.
| General area of feature | |||
| ID | Specific area of feature | Sample valid profile(s) | Sample invalid profile(s) |
| RDF/XML | |||
| 1 | MUST be valid RDF serialized in XML | 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11 | |
| 2 |
MUST use valid syntax for namespace declarations | 01 |
|
| CC/PP Profile
Components | |||
| 3 |
profile MUST contain one or more components | 01 | 32 |
| 4 |
each component MUST contain one or more attributes | 01 |
31 |
| 5 |
component name MAY be in type statement | 12, 13 | |
| 6 |
components MUST be associated with the CC/PP namespace or some subclass thereof | 14 | 30 |
| 7 |
component names, component types, and attribute names must all refer to different URIs within a profile | 01 | 34 |
| 8 |
if a component type is given as an element name and as an rdf:type element, they MUST refer to the same URI | 35 | 36 |
| CC/PP Profile Defaults | |||
| 9 |
default references MUST be valid URLs | 15, 16 | |
| 10 |
defaults MAY be written as ccpp:defaults or ccpp:Defaults | 15, 16 | |
| 11 |
defaults MUST be associated with the CC/PP namespace or some subclass thereof | 17 | 33 |
| 12 |
MAY contain both a default value and a directly applied value, directly applied value takes precedence | 18 | |
| 13 |
MAY contain inline defaults | 37 | |
| 14 |
MUST NOT contain both inline and referenced defaults | 37 | 38 |
| 15 |
MAY reference a default document which does not have an rdf:type | 39 | |
| CC/PP Profile Attributes | |||
| 16 |
MAY contain attributes that are sets of values (Bags) | 23, 24 | |
| 17 |
MAY contain attributes that are sequences of values (Seq) | 25, 26 | |
| 18 |
MAY contain attributes that are string values | 27 | |
| 19 |
MAY contain attributes that are Integer numbers | 28 | |
| 20 |
MAY contain attributes that are Rational numbers | 29 | |
| 21 |
MUST NOT contain multiple values for the same
attribute in the same component |
01 |
41 |
| 22 |
MAY contain attributes of the same name in more
than one component |
40 |
|
| 23 |
MAY use multiple namespaces for
attributes |
19,
20, 21,
22 |
|
Some of the sample valid profiles above use the following:
To be considered a CC/PP conformant producer, any CC/PP profile document generated by a producer must be a valid CC/PP profile document. Different producers will demonstrate generation of valid CC/PP profile documents differently. The method by which a producer sends CC/PP profile documents to a consumer is beyond the scope of the CC/PP Structure and Vocabularies specification. In the case of a WAP phone, for example, the phone's web client may send a URL with each request that references a valid CC/PP profile document. The web server servicing that URL may in turn respond with a valid CC/PP profile document as the body of a HTTP message.
To be considered a CC/PP conformant consumer, a consumer must accept any valid CC/PP profile document and extract appropriate information. Different consumers will demonstrate proper acceptance and extraction of information differently. In the case of a Java application server, for example, a Java servlet may be written that prints out the profile data. The method by which a consumer receives CC/PP profile documents from a producer is beyond the scope of the CC/PP Structure and Vocabularies specification. The behavior of a consumer when accepting and extracting information from an invalid profile is beyond the scope of this test suite.