FW: [Moderator Action] Re: Issues and future work for CC/PP

------ Forwarded Message ------
From: "Tayeb Lemlouma" <Tayeb.Lemlouma@inrialpes.fr>
Organization: INRIA
Date: Fri, 21 Jun 2002 04:08:44 -0400 (EDT)
To: "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com>
Cc: <www-mobile@w3.org>, <w3c-ccpp-wg@w3.org>
Subject: [Moderator Action] Re: Issues and future work for CC/PP

(Hi again, I think that my last mail wasn't well formatted, I'm sorry.
I'm trying here to re-send it again in a legible format, I hope this will
work)
 
 

Here are some CC/PP issues that we propose.
 
First, I think that there is a large consensus between a majority of
developers 
and people who work with CC/PP on the simplification of the actual CC/PP.
A simplified format of CC/PP will facilitate profiles parsing, handling,
validation 
and will ensures many performance gains. When we talk about CC/PP
simplification we have two directions: leaving RDF or keeping RDF (the
model) 
and using it in a good manner.
 
As I said in the beginning of this discussion, the problem is not in the RDF
‘the model’ but in the ‘adopted XML serialization’. The current RDF
serialization 
is complicated and hard to handle especially in the CC/PP context where
clients 
and networks are subject of many limitations and constraints if compared to
the 
classical environments.
 
To simplify I’ll take the same example taken by Mark, but I prefer to begin
with 
the figure 2-2.a rather than 2-2.b of the working draft. Well, let’s examine
the 
terminal software component in our natural language.
 
According to the graphical presentation of the profile, the client uses a
‘software 
platform’ having the name of ‘EPC’. The ‘version’ of the platform is ‘2.0’
and the 
‘vendor name’ of the OS is ‘Symbian’. Now, let’s speaking a little RDF for
our 
profile: 
- The described component is the ‘Terminal Software’,
- Given properties concerns the RDF resource of the type:
‘SoftwarePlatform’,
- The name of the SoftwarePlatform is ‘EPOC’,
- The version of the SoftwarePlatform is ‘2.0’,
- The vendor of the SoftwarePlatform is ‘Symbian’.
- Other information can also be given:
TerminalSoftware, SoftwarePlatform, name, version, vendor definition can
be found in the RDF schema identified by the corresponding namespaces.
 
Well, until now we speak about the same thing in a well understood language
(I hope!:) ). Now let’s take a look on how the precedent information are
expressed using the adopted RDF serialization. Here is the software part of
the profile, as it’s given in fig 2-2.b of the WD (with namespaces).
 
    <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>
 
And here a simple XML form of the software component (I take the same
proposed by Mark)
 
  <prf:SoftwarePlatform>
    <prf:name>EPOC</prf:name>
    <prf:version>2.0</prf:version>
    <prf:vendor>Symbian</prf:vendor>
  </prf:SoftwarePlatform>
 
 
Here are some important points that arise when comparing the two
approaches (using RDF and using a simple XML form of profiles)
 
Performance:
 
The precedent component sizes are respectively: 281 char and 132 char
(only required space are counted), which gives a size gain of 149 char.
So we can imagine the gain of the global profile when using a simple XML
format. The problem of profile size is addressed especially when we talk
about profiles transmission over slow networks and less from the storage
point of view. In this context, many other solutions exit such as using
compressed form of XML (see the binary XML content format specification)
 or using URIs (see the CC/PP exchange protocol using HTTP Extension), etc.
 
Parsing:
 
I agree that parsing a simple XML format is more easy than parsing RDF, and
 I understand some people who find that tools to parse RDF are not
sufficient. 
It’s also clear that XSLT parse RDF (since RDF is XML) but less easy than
XML. But the problem here is due directly to the adopted XML serialization
of RDF in CC/PP.
 
Validation: 
 
Defining XML schemata for the sued vocabularies inside CC/PP profiles, will
be of a high benefit to validate the syntax of the profiles. CC/PP
‘Syntactic’ 
validation can not be ensured using RDF schemata this is why XML syntactic
validation must be enabled in CC/PP.
 
Semantic:
 
The major problem of leaving RDF is to ignore the meaning or the semantic
axes of CC/PP profiles. Adopting pure XML for CC/PP will be good from
the point of view validation and parsing which is only related to the syntax
dimension of CC/PP profiles. If we take the above example (RDF and XML
form of the software component), the XML form lists the different component
attributes identified by a namespaces that doesn’t point to an RDFS but to
an 
XMLS which is a pure syntactic consideration.
   
RDF serialization:
 
It is right that adopting a new RDF serialization proper to CC/PP will
insulate 
CC/PP from changes in RDF, but leaving completely the RDF model will
implies the loss of the RDF advantages.
It’s well known that the current XML serialization of RDF is not unique.
There is another serializing of RDF that is called N3 (developed by Tim
Berners-Lee). 
It’s designed to be easy to parse and build larger applications on top of.
N3 allows, 
in a simple way, writing out URIs and literal values in triples. In N3 it’s
not necessary 
to give also the URI, furthermore N3 ensures an efficient way to abbreviate
the URI 
which avoid using long URIs every where in the description.
 
In my opinion the solution isn’t to leave RDF the model but to adopt a new
RDF 
serialization proper to CC/PP. The new XML serialization should be a simple
form 
of RDF following the approach of N3 but not in a plain text. XMLS schemata
should 
also be used in order to ensure the validation of the profiles. In a
description framework
the two dimensions syntax and semantic must work together in order to make
the 
framework efficient and useful.
 
Constraints expressing:
 
CC/PP should enables advanced mechanisms to express more complicated client
constraints. Enriching CC/PP with logical expressing facilities will make it
more 
efficient to be used to express clients constraints in well formed manner.
In this 
context the effort made in RFC 2533: http://www.ietf.org/rfc/rfc2533.txt by
Graham K for media feature description, represents a good approach to be
inspired 
in order to define new CC/PP logical expressions. New constraints can be
used and 
expressed within RDF bag, alt and seq.
 
 
Best regards
Tayeb*
----------
Tayeb Lemlouma
http://www.inrialpes.fr/opera/people/Tayeb.Lemlouma/index.html
<http://www.inrialpes.fr/opera/people/Tayeb.Lemlouma/index.html>
Opera project
National Research Institute in Computer Science and Control (INRIA
Rhône-Alpes, France )
Office B213, phone (+33) 04 76 61 52 81, Fax (+33) 04 76 61 52 07.


------ End of Forwarded Message ------