RE: CC/PP, RDF and XML

Mark, 

I agree that this does simplify the authoring and processing of profiles,
with tools that can run on limited capability devices as well. However, the
main concern with this approach is the "flattening" of profiles. 

Most importantly, in order to express things such as "component-level"
defaults, with override of selective attributes, "classes" of components,
etc. it seems like you would have to define special tags for the XML with
perhaps associated DTDs.  

Another way of looking at it is that if profiles are nothing more than a
list of attributes, with associated lists of values, then XML is fine.
However, if profiles are intended to be more expressive, with semantics that
would be useful during processing (such as defaults and overrides, or
component classes with meaningful instances) then RDF seems like a better
choice. 

What would be ideal would be a simplified XML serialization of RDF
structure! Which may be a whole another can of worms.

Thanks
dvk

-----Original Message-----
From: Butler, Mark [mailto:Mark_Butler@hplb.hpl.hp.com] 
Sent: Tuesday, June 18, 2002 10:51 AM
To: 'www-mobile@w3.org'
Subject: CC/PP, RDF and XML



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 Wednesday, 19 June 2002 15:13:18 UTC