5. Conformance

This section explains how to make a valid claim that a product conforms to this specification. Anyone may make a claim (e.g., vendors about their own products, third parties about those products, journalists about products, etc.). Claims may be published anywhere (e.g., on the Web or in product documentation). Claimants are solely responsible for their claims. If the subject of the claim (e.g., the software) changes after the date of the claim, the claimant is responsible for updating the claim. Claimants are expected to modify or retract a claim if it may be demonstrated that the claim is not valid. Claimants are encouraged to conform to the most recent specification available.

There are three classes of products of CC/PP:

  1. documents (e.g. a web resource)
  2. producers (e.g. a web client)
  3. consumers (e.g. a web server)

5.1 CC/PP Document Conformance

Documents may exist as resources accessible via a URL, or may be transmitted as data in a message. A document is CC/PP conformant when it meets the following criteria:

  1. The document MUST be valid RDF serialized in XML, conforming to the RDF Schema in appendix B. See section 1.
  2. The document MUST use valid syntax for namespace declarations. See section 2.2.
  3. The profile element MUST contain one or more components. See section 2.1.
  4. Each component in the profile MUST contain one or more attributes. See section 2.1.
  5. The component names MAY be in rdf:type statements. See section 3.1.
  6. Components MUST be associated with the CC/PP namespace or some subclass thereof. See section 3.1.
  7. Component names, component types, and attribute names must all refer to different URIs within a profile. See section 3.
  8. If a component type is given as an element name and as an rdf:type element, they MUST refer to the same URI. See section 3.1.
  9. Default references MUST be valid URLs. See section 3.3.
  10. Defaults MAY be written as ccpp:defaults or ccpp:Defaults. See section 3.3.
  11. Defaults MUST be associated with the CC/PP namespace or some subclass thereof. See section 3.3.
  12. Component attributes MAY contain both a default value and a directly applied value, with the directly applied value taking precedence. See section 3.3.
  13. Components MAY contain inline defaults. See section 3.3.
  14. Components MUST NOT contain both inline and referenced defaults. See section 3.3.
  15. Components MAY reference a default document which does not have an rdf:type. See section 3.3.
  16. Attributes MAY have sets of values (Bags). See section 4.1.2.1.
  17. Attributes MAY have sequences of values (Seq). See section 4.1.2.2.
  18. Attributes MAY have Text values. See section 4.1.1.2.
  19. Attributes MAY have Integer number values. See section 4.1.1.3.
  20. Attributes MAY have Rational number values. See section 4.1.1.4.
  21. A component MUST NOT contain more than one attribute with the same name. See section 3.2.
  22. Attributes of the same name MAY be in different components. See section 3.1.
  23. Profiles MAY use multiple namespaces for attributes. See section 2.2.

5.3 CC/PP Producer Conformance

A producer is CC/PP conformant when any CC/PP profile document generated by the producer is a CC/PP conformant document.

5.4 CC/PP Consumer Conformance

A consumer is CC/PP conformant when the consumer accepts any CC/PP conformant document and extracts appropriate information. Support for the RDF Schema in appendix B by CC/PP consumers is OPTIONAL.

There are two categories of conformance for CC/PP consumers, depending on the treatment of invalid profiles:

  1. validating: A consumer is a CC/PP conformant validating consumer when it rejects all  non-conformant CC/PP documents.
  2. non-validating: A consumer is a CC/PP conformant non-validating consumer when it does not reject all non-conformant CC/PP documents.

NOTE: A consumer implementation may be configurable to act as either a validating or a non-validating consumer at different times.

5.5 Conformance Claims

5.5.1 Validity

A conformance claim is valid if it is well formed and meets the appropriate conformance criteria for the applicable product class as given above.

5.5.2 Well-formed

A conformance claim is well-formed if it includes the following information:

  1. the date of the claim
  2. the product class (document, producer, or consumer)
  3. the consumer category (validating or non-validating) if applicable
  4. the title and dated URI of this document