- From: Kazuhiro Kitagawa <kaz@w3.org>
- Date: Fri, 21 Jun 2002 11:58:19 +0900
- To: www-mobile@w3.org
Delivered-To: kaz@w3.mag.keio.ac.jp
Date: Thu, 20 Jun 2002 07:04:05 -0400 (EDT)
X-Envelope-From: www-mobile-request@tux.w3.org Thu Jun 20 07:04:04 2002
Message-ID: <040301c2184a$8e739060$0314c7c2@galapagos>
From: "Tayeb Lemlouma" <Tayeb.Lemlouma@inrialpes.fr>
To: "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com>
Cc: <www-mobile@w3.org>, <w3c-ccpp-wg@w3.org>
Old-Date: Thu, 20 Jun 2002 13:06:41 +0200
Organization: INRIA
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0400_01C2185B.51AE8E80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2479.0006
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006
X-Diagnostic: Not on the accept list
Subject: [Moderator Action] Re: Issues and future work for CC/PP
X-Diagnostic: Mail coming from a daemon, ignored
X-Envelope-To: www-mobile
This is a multi-part message in MIME format.
------=_NextPart_000_0400_01C2185B.51AE8E80
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Mark,
=20
Here are some CC/PP issues that we propose.
=20
First, I think that there is a large consensus between a majority of =
developers=20
and people who work with CC/PP on the simplification of the actual =
CC/PP.=20
A simplified format of CC/PP will facilitate profiles parsing, handling, =
validation=20
and will ensures many performance gains. When we talk about CC/PP=20
simplification we have two directions: leaving RDF or keeping RDF (the =
model)=20
and using it in a good manner.=20
=20
As I said in the beginning of this discussion, the problem is not in the =
RDF=20
'the model' but in the 'adopted XML serialization'. The current RDF =
serialization=20
is complicated and hard to handle especially in the CC/PP context where =
clients=20
and networks are subject of many limitations and constraints if compared =
to the=20
classical environments.=20
=20
To simplify I'll take the same example taken by Mark, but I prefer to =
begin with=20
the figure 2-2.a rather than 2-2.b of the working draft. Well, let's =
examine the=20
terminal software component in our natural language.=20
=20
According to the graphical presentation of the profile, the client uses =
a 'software=20
platform' having the name of 'EPC'. The 'version' of the platform is =
'2.0' and the=20
'vendor name' of the OS is 'Symbian'. Now, let's speaking a little RDF =
for our=20
profile:=20
- The described component is the 'Terminal Software',=20
- Given properties concerns the RDF resource of the type: =
'SoftwarePlatform',=20
- The name of the SoftwarePlatform is 'EPOC',=20
- 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.
=20
Well, until now we speak about the same thing in a well understood =
language=20
(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=20
the profile, as it's given in fig 2-2.b of the WD (with namespaces).
=20
<ccpp:component>
<rdf:Description
rdf:about=3D"http://www.example.com/schema#TerminalSoftware">
<rdf:type
=
rdf:resource=3D"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>
=20
And here a simple XML form of the software component (I take the same=20
proposed by Mark)
=20
<prf:SoftwarePlatform>
<prf:name>EPOC</prf:name>
<prf:version>2.0</prf:version>
<prf:vendor>Symbian</prf:vendor>
</prf:SoftwarePlatform>
=20
=20
Here are some important points that arise when comparing the two=20
approaches (using RDF and using a simple XML form of profiles)
=20
Performance:
=20
The precedent component sizes are respectively: 281 char and 132 char=20
(only required space are counted), which gives a size gain of 149 char.=20
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=20
compressed form of XML (see the binary XML content format specification) =
or using URIs (see the CC/PP exchange protocol using HTTP Extension), =
etc.
=20
Parsing:
=20
I agree that parsing a simple XML format is more easy than parsing RDF, =
and=20
I understand some people who find that tools to parse RDF are not =
sufficient.=20
It's also clear that XSLT parse RDF (since RDF is XML) but less easy =
than=20
XML. But the problem here is due directly to the adopted XML =
serialization=20
of RDF in CC/PP.
=20
Validation:=20
=20
Defining XML schemata for the sued vocabularies inside CC/PP profiles, =
will=20
be of a high benefit to validate the syntax of the profiles. CC/PP =
'Syntactic'=20
validation can not be ensured using RDF schemata this is why XML =
syntactic=20
validation must be enabled in CC/PP.
=20
Semantic:
=20
The major problem of leaving RDF is to ignore the meaning or the =
semantic=20
axes of CC/PP profiles. Adopting pure XML for CC/PP will be good from=20
the point of view validation and parsing which is only related to the =
syntax=20
dimension of CC/PP profiles. If we take the above example (RDF and XML=20
form of the software component), the XML form lists the different =
component=20
attributes identified by a namespaces that doesn't point to an RDFS but =
to an=20
XMLS which is a pure syntactic consideration.
=20
RDF serialization:
=20
It is right that adopting a new RDF serialization proper to CC/PP will =
insulate=20
CC/PP from changes in RDF, but leaving completely the RDF model will=20
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).=20
It's designed to be easy to parse and build larger applications on top =
of. N3 allows,=20
in a simple way, writing out URIs and literal values in triples. In N3 =
it's not necessary=20
to give also the URI, furthermore N3 ensures an efficient way to =
abbreviate the URI=20
which avoid using long URIs every where in the description. =20
=20
In my opinion the solution isn't to leave RDF the model but to adopt a =
new RDF=20
serialization proper to CC/PP. The new XML serialization should be a =
simple form=20
of RDF following the approach of N3 but not in a plain text. XMLS =
schemata should=20
also be used in order to ensure the validation of the profiles. In a =
description framework=20
the two dimensions syntax and semantic must work together in order to =
make the=20
framework efficient and useful.
=20
Constraints expressing:
=20
CC/PP should enables advanced mechanisms to express more complicated =
client=20
constraints. Enriching CC/PP with logical expressing facilities will =
make it more=20
efficient to be used to express clients constraints in well formed =
manner. In this=20
context the effort made in RFC 2533: http://www.ietf.org/rfc/rfc2533.txt =
by=20
Graham K for media feature description, represents a good approach to be =
inspired=20
in order to define new CC/PP logical expressions. New constraints can be =
used and=20
expressed within RDF bag, alt and seq.
=20
=20
Best regards
Tayeb*
----------
Tayeb Lemlouma
http://www.inrialpes.fr/opera/people/Tayeb.Lemlouma/index.html
Opera project
National Research Institute in Computer Science and Control (INRIA =
Rh=F4ne-Alpes, France )
Office B213, phone (+33) 04 76 61 52 81, Fax (+33) 04 76 61 52 07.
------=_NextPart_000_0400_01C2185B.51AE8E80
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2479.6" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D""><FONT face=3DArial size=3D2>Hi=20
Mark,<BR> <BR>Here are some CC/PP issues that we=20
propose.<BR> <BR>First, I think that there is a large consensus =
between a=20
majority of developers </FONT><BR><FONT face=3DArial size=3D2>and people =
who work=20
with CC/PP on the simplification of the actual CC/PP. </FONT><BR><FONT=20
face=3DArial size=3D2>A simplified format of CC/PP will facilitate =
profiles parsing,=20
handling, validation</FONT> <BR><FONT face=3DArial size=3D2>and will =
ensures many=20
performance gains. When we talk about CC/PP</FONT> <BR><FONT =
face=3DArial=20
size=3D2>simplification we have two directions: leaving RDF or keeping =
RDF (the=20
model) </FONT><BR><FONT face=3DArial size=3D2>and using it in a good =
manner.=20
<BR> <BR>As I said in the beginning of this discussion, the problem =
is not=20
in the RDF </FONT><BR><FONT face=3DArial size=3D2>=91the model=92 but in =
the =91adopted=20
XML serialization=92. The current RDF serialization</FONT> <BR><FONT =
face=3DArial=20
size=3D2>is complicated and hard to handle especially in the CC/PP =
context where=20
clients</FONT> <BR><FONT face=3DArial size=3D2>and networks are subject =
of many=20
limitations and constraints if compared to the </FONT><BR><FONT =
face=3DArial=20
size=3D2>classical environments. <BR> <BR>To simplify I=92ll take =
the same=20
example taken by Mark, but I prefer to begin with </FONT><BR><FONT =
face=3DArial=20
size=3D2>the figure 2-2.a rather than 2-2.b of the working draft. Well, =
let=92s=20
examine the </FONT><BR><FONT face=3DArial size=3D2>terminal software =
component in=20
our natural language. <BR> <BR>According to the graphical =
presentation of=20
the profile, the client uses a =91software </FONT><BR><FONT face=3DArial =
size=3D2>platform=92 having the name of =91EPC=92. The =91version=92 of =
the platform is=20
=912.0=92 and the </FONT><BR><FONT face=3DArial size=3D2>=91vendor =
name=92 of the OS is=20
=91Symbian=92. Now, let=92s speaking a little RDF for our =
</FONT><BR><FONT face=3DArial=20
size=3D2>profile: <BR>- The described component is the =91Terminal =
Software=92, <BR>-=20
Given properties concerns the RDF resource of the type: =
=91SoftwarePlatform=92,=20
<BR>- The name of the SoftwarePlatform is =91EPOC=92, <BR>- The version =
of the=20
SoftwarePlatform is =912.0=92,<BR>- The vendor of the SoftwarePlatform =
is=20
=91Symbian=92.<BR>- Other information can also be =
given:<BR>TerminalSoftware,=20
SoftwarePlatform, name, version, vendor definition can </FONT><BR><FONT=20
face=3DArial size=3D2>be found in the RDF schema identified by the =
corresponding=20
namespaces.<BR> <BR>Well, until now we speak about the same thing =
in a well=20
understood language </FONT><BR><FONT face=3DArial size=3D2>(I hope!:) ). =
Now let=92s=20
take a look on how the precedent information are </FONT><BR><FONT =
face=3DArial=20
size=3D2>expressed using the adopted RDF serialization. Here is the =
software part=20
of </FONT><BR><FONT face=3DArial size=3D2>the profile, as it=92s given =
in fig 2-2.b of=20
the WD (with namespaces).<BR> <BR> =20
<ccpp:component><BR> =20
<rdf:Description<BR> &n=
bsp;=20
rdf:about=3D"http://www.example.com/schema#TerminalSoftware"><BR> =
; =20
<rdf:type<BR> &nb=
sp;=20
rdf:resource=3D"http://www.example.com/schema#SoftwarePlatform"/><BR>&=
nbsp; =20
<ex:name>EPOC</ex:name><BR> &nbs=
p; =20
<ex:version>2.0</ex:version><BR>  =
; =20
<ex:vendor>Symbian</ex:vendor><BR> &nb=
sp;=20
</rdf:Description><BR> =20
</ccpp:component><BR> <BR>And here a simple XML form of the =
software=20
component (I take the same</FONT> <BR><FONT face=3DArial =
size=3D2>proposed by=20
Mark)<BR> <BR> =
<prf:SoftwarePlatform><BR> =20
<prf:name>EPOC</prf:name><BR> =20
<prf:version>2.0</prf:version><BR> =20
<prf:vendor>Symbian</prf:vendor><BR> =20
</prf:SoftwarePlatform><BR> <BR> <BR>Here are some =
important=20
points that arise when comparing the two </FONT><BR><FONT face=3DArial=20
size=3D2>approaches (using RDF and using a simple XML form of=20
profiles)<BR> <BR>Performance:<BR> <BR>The precedent component =
sizes=20
are respectively: 281 char and 132 char </FONT><BR><FONT face=3DArial =
size=3D2>(only=20
required space are counted), which gives a size gain of 149 char.=20
</FONT><BR><FONT face=3DArial size=3D2>So we can imagine the gain of the =
global=20
profile when using a simple XML </FONT><BR><FONT face=3DArial =
size=3D2>format. The=20
problem of profile size is addressed especially when we talk =
</FONT><BR><FONT=20
face=3DArial size=3D2>about profiles transmission over slow networks and =
less from=20
the storage </FONT><BR><FONT face=3DArial size=3D2>point of view. In =
this context,=20
many other solutions exit such as using </FONT><BR><FONT face=3DArial=20
size=3D2>compressed form of XML (see <A =
href=3D"http://www.w3.org/TR/wbxml/">the=20
binary XML content format specification</A>)</FONT> <BR><FONT =
face=3DArial=20
size=3D2> or using URIs (see <A=20
href=3D"http://www.w3.org/TR/NOTE-CCPPexchange">the CC/PP exchange =
protocol using=20
HTTP Extension</A>), etc.<BR> <BR>Parsing:<BR> <BR>I agree =
that=20
parsing a simple XML format is more easy than parsing RDF, and</FONT> =
<BR><FONT=20
face=3DArial size=3D2> I understand some people who find that tools =
to parse=20
RDF are not sufficient. </FONT><BR><FONT face=3DArial size=3D2>It=92s =
also clear that=20
XSLT parse RDF (since RDF is XML) but less easy than </FONT><BR><FONT =
face=3DArial=20
size=3D2>XML. But the problem here is due directly to the adopted XML=20
serialization </FONT><BR><FONT face=3DArial size=3D2>of RDF in=20
CC/PP.<BR> <BR>Validation: <BR> <BR>Defining XML schemata for =
the sued=20
vocabularies inside CC/PP profiles, will </FONT><BR><FONT face=3DArial =
size=3D2>be=20
of a high benefit to validate the syntax of the profiles. CC/PP =
=91Syntactic=92=20
</FONT><BR><FONT face=3DArial size=3D2>validation can not be ensured =
using RDF=20
schemata this is why XML syntactic </FONT><BR><FONT face=3DArial =
size=3D2>validation=20
must be enabled in CC/PP.<BR> <BR>Semantic:<BR> <BR>The major =
problem=20
of leaving RDF is to ignore the meaning or the semantic </FONT><BR><FONT =
face=3DArial size=3D2>axes of CC/PP profiles. Adopting pure XML for =
CC/PP will be=20
good from </FONT><BR><FONT face=3DArial size=3D2>the point of view =
validation and=20
parsing which is only related to the syntax </FONT><BR><FONT =
face=3DArial=20
size=3D2>dimension of CC/PP profiles. If we take the above example (RDF =
and XML=20
</FONT><BR><FONT face=3DArial size=3D2>form of the software component), =
the XML form=20
lists the different component </FONT><BR><FONT face=3DArial =
size=3D2>attributes=20
identified by a namespaces that doesn=92t point to an RDFS but to an=20
</FONT><BR><FONT face=3DArial size=3D2>XMLS which is a pure syntactic=20
consideration.<BR> <BR>RDF serialization:<BR> <BR>It is =
right=20
that adopting a new RDF serialization proper to CC/PP will insulate=20
</FONT><BR><FONT face=3DArial size=3D2>CC/PP from changes in RDF, but =
leaving=20
completely the RDF model will </FONT><BR><FONT face=3DArial =
size=3D2>implies the=20
loss of the RDF advantages.<BR>It=92s well known that the current XML=20
serialization of RDF is not unique.<BR>There is another serializing of =
RDF that=20
is called N3 (developed by Tim Berners-Lee). </FONT><BR><FONT =
face=3DArial=20
size=3D2>It=92s designed to be easy to parse and build larger =
applications on top=20
of. N3 allows, </FONT><BR><FONT face=3DArial size=3D2>in a simple way, =
writing out=20
URIs and literal values in triples. In N3 it=92s not necessary =
</FONT><BR><FONT=20
face=3DArial size=3D2>to give also the URI, furthermore N3 ensures an =
efficient way=20
to abbreviate the URI </FONT><BR><FONT face=3DArial size=3D2>which avoid =
using long=20
URIs every where in the description. <BR> <BR>In my opinion =
the=20
solution isn=92t to leave RDF the model but to adopt a new RDF =
</FONT><BR><FONT=20
face=3DArial size=3D2>serialization proper to CC/PP. The new XML =
serialization=20
should be a simple form </FONT><BR><FONT face=3DArial size=3D2>of RDF =
following the=20
approach of N3 but not in a plain text. XMLS schemata should =
</FONT><BR><FONT=20
face=3DArial size=3D2>also be used in order to ensure the validation of =
the=20
profiles. In a description framework </FONT><BR><FONT face=3DArial =
size=3D2>the two=20
dimensions syntax and semantic must work together in order to make the=20
</FONT><BR><FONT face=3DArial size=3D2>framework efficient and=20
useful.<BR> <BR>Constraints expressing:<BR> <BR>CC/PP should =
enables=20
advanced mechanisms to express more complicated client </FONT><BR><FONT=20
face=3DArial size=3D2>constraints. Enriching CC/PP with logical =
expressing=20
facilities will make it more </FONT><BR><FONT face=3DArial =
size=3D2>efficient to be=20
used to express clients constraints in well formed manner. In this=20
</FONT><BR><FONT face=3DArial size=3D2>context the effort made in RFC =
2533: <A=20
href=3D"http://www.ietf.org/rfc/rfc2533.txt">http://www.ietf.org/rfc/rfc2=
533.txt</A>=20
by </FONT><BR><FONT face=3DArial size=3D2>Graham K for media feature =
description,=20
represents a good approach to be inspired </FONT><BR><FONT face=3DArial =
size=3D2>in=20
order to define new CC/PP logical expressions. New constraints can be =
used and=20
</FONT><BR><FONT face=3DArial size=3D2>expressed within RDF bag, alt and =
seq.<BR> <BR> <BR>Best =
regards<BR>Tayeb*<BR>----------<BR>Tayeb=20
Lemlouma<BR><A=20
href=3D"http://www.inrialpes.fr/opera/people/Tayeb.Lemlouma/index.html">h=
ttp://www.inrialpes.fr/opera/people/Tayeb.Lemlouma/index.html</A><BR>Oper=
a=20
project<BR>National Research Institute in Computer Science and Control =
(INRIA=20
Rh=F4ne-Alpes, France )<BR>Office B213, phone (+33) 04 76 61 52 81, Fax =
(+33) 04=20
76 61 52 07.</FONT><BR></BODY></HTML>
------=_NextPart_000_0400_01C2185B.51AE8E80--
Received on Thursday, 20 June 2002 22:59:37 UTC