W3C home > Mailing lists > Public > www-mobile@w3.org > June 2002

Re: Validation in CC/PP

From: Andreas Schade <san@zurich.ibm.com>
Date: Fri, 7 Jun 2002 10:01:20 +0200
To: "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com>
Cc: "'w3c-ccpp-wg@w3.org'" <w3c-ccpp-wg@w3.org>, "'www-mobile@w3.org'" <www-mobile@w3.org>, www-mobile-request@w3.org
Message-ID: <OFD4920CF4.398FE977-ONC1256BD1.00283AF0@LocalDomain>


We also think that validation is necessary. Since the schema defines
the vocabulary, it represents a sort of contract between the sender and
the recipient of the profile information as it tell the recipient what
questions it may ask, i.e. what property values it may query. If
profiles do not adhere to the schema they use, a receiving entity can
only guess what properties are contained in the profile, what types are
used to represent the property values, and what these values actually mean.
In this case the profile does not provide much value for the receiving

Validation is in our opinion the only way to guarantee that the contract
between the sender and the recipient is upheld. On the other hand, strictly
requiring that a profile can only contain the properties defined in the
schema it uses actually breaks profile extensibility. We have therefore
defined and implemented different levels of profile validation that
control the parsing of profiles:

(1) None: All profile properties are processed. Values of properties
    defined in the schema are represented using their specified types.
    Properties not defined in the schema are included in the resulting
    profile data structure. Their values are always represented as strings.
    In this mode profiles can be extended with proprietary properties.
(2) Weak: Values of properties defined in the schema are represented
    using their specified types. Properties not defined in the schema are
    not included in the resulting profile, and a warning is given. In this
    mode profiles that violate their schema are processed, but the
    property set is narrowed to enforce schema compliance.
(3) Strict: Schema violations are regarded as errors. Profiles that do
    not comply with their schema are not processed.

Best regards,
Andreas Schade
IBM Zurich Research Laboratory

|         |           "Butler, Mark"    |
|         |           <Mark_Butler@hplb.|
|         |           hpl.hp.com>       |
|         |           Sent by:          |
|         |           www-mobile-request|
|         |           @w3.org           |
|         |                             |
|         |                             |
|         |           05.06.2002 18:40  |
|         |           Please respond to |
|         |           "Butler, Mark"    |
|         |                             |
  |                                                                                                                                             |
  |       To:       "'w3c-ccpp-wg@w3.org'" <w3c-ccpp-wg@w3.org>, "'www-mobile@w3.org'" <www-mobile@w3.org>                                      |
  |       cc:                                                                                                                                   |
  |       Subject:  Validation in CC/PP                                                                                                         |

In my opinion, one key problem with CC/PP as it currently stands is there
no notion of profile validation. I've been speaking about this to people
here at HP working on RDF and they have made a number of suggestions. I'd
like to briefly outline these suggestions as I think they are of general
interest to people working on CC/PP.

So why do we need validation? Well experience with existing CC/PP
vocabularies has shown that even with a small number of profiles, vendors
make mistakes when creating profiles. For example they get property names
wrong e.g. use PixelsAspectRatio not PixelAspectRatio. There is also no
agreement on property literal values so two vendors might use the same
literal to indicate different capabilities or different literals to
the same capability e.g. "1.2.1/June 2000" and "1.2.1" are used to refer to
the same capability.

My colleague Andy Seaborne has suggested there are three assumptions you
make about RDF properties when performing schema validation in order to
solve the first problem:

i) Open - the "correct" validation of data against a schema - can never
actually say anything is wrong because RDFS does not make any closed world
assumptions or contain negation.
ii) Strict - must be able to prove that a resource is the type specified,
whether by domain/range or by rdf:type declaration.
iii) Exact - the resources must have all and only the declared properties.
This is a crude way of getting a robust checking - really need the idea of
optional/mandatory properties.

So it seems to me that by default CC/PP should be using the Strict
assumption i.e. a property can only be used in a profile if it is defined
the associated schema. In addition if a property is associated with a
component(s), then it can only appear there. In the future, we may have
vocabularies where a device must supply all the profile attributes to
conform to the vocabulary i.e. schema need to be able to define if they
should be interpreted as Exact.

The second problem has also been encountered by the DAML community who have
explored using XML Schema (XSD) to perform data validation on literal
values. For example this validator
provides support for XML schema validation using the Oracle XDK XML Schema
Validation toolkit to verify DAML files.

For examples of how to reference XSD in RDF, see this DAML example
which uses this XML schema file
via the dt namespace prefix i.e.


I also found this document, Annotated DAML+OIL, useful

So what do other people think about this? Would providing validation be
useful? Are there any other appropriate methods?

best regards

Mark H. Butler, PhD
Research Scientist                HP Labs Bristol
Internet: http://www-uk.hpl.hp.com/people/marbut/
Received on Friday, 7 June 2002 04:03:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:03 UTC