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

CC/PP, RDF and XML

From: Butler, Mark <Mark_Butler@hplb.hpl.hp.com>
Date: Tue, 18 Jun 2002 18:50:41 +0100
Message-ID: <5E13A1874524D411A876006008CD059F04501912@0-mail-1.hpl.hp.com>
To: "'www-mobile@w3.org'" <www-mobile@w3.org>

Folks,

I recently submitted this issue to the CC/PP working group. I would also
like to hear some opinions on it from this group?

thanks in advance

MB_7: Mark Butler
CC/PP AND RDF[2]
Instead of representing CC/PP as the XML serialisation of RDF, I think CC/PP
should be represented as XML and there should be a well defined way of
converting it to RDF if required. This would have a number of advantages:

- The CC/PP profile would be shorter and easier to understand. For example
the profile in Figure 2-2.b in the 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#erminalBrowser">
        <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:Descr

could be rewritten

<?xml version="1.0"?>
<prf:Profile xmlns:prf="http://www.example.com/schema#">
  <prf:HardwarePlatfom>
    <prf:displayWidth>320</prf:displayWidth>
    <prf:displayHeight>200</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>

- CC/PP profiles could be processed with existing XML tools, eg XML parsers.
- CC/PP profiles would be much easier to use in XSLT. This would be
advantageous as XSLT is a standard approach to content adaptation. 
- Profile authors would not be required to understand RDF.
- Existing validation tools such as XML Schema could be used to validate
that profiles conform to specific vocabularies.
- 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. This can be done in
RDF but is it difficult: for example it would be difficult to cosntruct an
RDQL query to do this. However in XML this can be done using XPath.
- 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.
- The XML serialisation of RDF is still being refined so using an
alternative serialisation would effectively insulate CC/PP from changes in
RDF.
- As the XML profiles are shorter, they are more efficient to transmit over
bandwidth restricted networks.
- 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.

One issue here is backward compatability with UAProf. I think this issue
could be solved by instructing CC/PP processors to ignore extraneous RDF
tags in UAProf profiles e.g. rdf:Description, ccpp:Component, rdf:type, ID
etc to extract an XML processor i.e. it would be possible to construct
processors in such a way that they could read UAProf profiles in the
existing format if required, but perhaps UAProf might prefer this simplifed
format also?

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 Tuesday, 18 June 2002 13:51:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 13:00:01 GMT