- 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
Folks, 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 entity. 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 is 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 indicate 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 can 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 in 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 http://www.daml.org/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 http://www.daml.org/validator/examples/dt4.daml which uses this XML schema file http://www.daml.org/validator/examples/dt1.xsd via the dt namespace prefix i.e. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:daml="http://www.daml.org/2001/03/daml+oil#" xmlns:xsd="http://www.w3.org/2000/10/XMLSchema#" xmlns:dt="http://www.daml.org/validator/examples/dt1.xsd#"> I also found this document, Annotated DAML+OIL, useful http://www.daml.org/2001/03/daml+oil-walkthru.html 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 mark-h_butler@hp.com Internet: http://www-uk.hpl.hp.com/people/marbut/
Received on Friday, 7 June 2002 04:03:25 UTC