RE: Zen & Chinwag

<- I hate to say this over and over, but CC/PP is exactly what you
<- describe: A
<- metadata framework for agent description. In the WAP context
<- (since they are the
<- only ones to develop a metadata vocabulary, they are the only
<- ones we know
<- about) it works exactly as you describe: The profile of the
<- client is matched
<- against the profile on the server (that for instance describes
<- the document).

CC/PP is *not* exactly what I describe, though there is considerable
overlap. I'm not sure what you mean about saying it over and over - is this
a future intention?

I must admit my earlier opinion of CC/PP was largely coloured by scanning
rather than thoroughly reading the CC/PP specs [1, 2, 3, 4], largely
becoause much of these emphasise profiling the 'user agent' (a recurring
phrase), and focuses on a narrow range of applications (e.g. supplying data
in a suitable format for mobile devices). This 'user agent' is nothing like
the the generic 'process' I've been talking about (though it could be seen
as a specific instance).

After some re-reading of the CC/PP docs, I can still identify significant
differences between the intended role of this and what I had in mind with
RPP [5]. To quote the abstract of [1] :
"In this document we describe a method for using RDF, the Resource
Description Framework of the W3C, to create a general, yet extensible
framework for describing user preferences and device capabilities. This
information can be collected into a profile and provided by user agents to
servers and content providers. The user's preferences and the capabilities
of the user's agents can be used to customize a service or content provided
by a service."

If I'm not very mistaken, what is being profiled by CC/PP is user
preferences & the capabilities of their agents, and this profile is for use
by a service provider to customize services. What I was primarily aiming for
was a profile of the *services*.

Ok, I'm sure it could be argued that CC/PP is capable of doing what I'm
talking about - but my point there would be that CC/PP is really geared up
for telling services the kind of content or service the client wants, rather
than  describing what the service does in general terms. Ok, taking your WAP
example - as you say, the profile of the client is matched against the
profile on the server (that for instance describes the document). The end
result in this instance is exactly the same using CC/PP as in manner I'm
suggesting. Similarly the use of proxies in CC/PP to chain transcoding
operations is the same in principle as referring-on that I suggested. The
difference really lies in the emphasis - CC/PP strikes me as being very
content-orientated (i.e. data) rather than service-oriented (i.e. process).
The profile seems to be about what a particular agent (usually a client,
'user agent') can handle, rather than what that agent
(client/service/process) can *do*.

If my client wants to e.g. convert a gif image into a png, then what is
important is the required process (transforming a into b) and the input and
output data formats (gif & png). Whether or not my client can view gif or
png images (potentially parts of the CC/PP profile) is irrelevant.

I believe CC/PP was an attempt to solve a specific set of real-world
problems, typified by the requirement to supply data in an appropriate
format to clients with differing capabilities (it looks like it has been
successful in this).

However, as with many such problem-solving activities, the scope expanded
back to generalize the system. Due to this expansion, I'm willing to accept
that CC/PP could potentially be used to profile processes as I'm suggesting
with RPP. But I would say approaching the problem from a more general case
(that of processes), and then narrowing to a specific case (e.g. WAP content
provision) stands a better chance of producing a system that can be applied
to other cases in a 'natural' fashion.

I'm currently thinking the way forward is to purloin some of the better
features of CC/PP (and WSDL for that matter) and incorporate them into the
RPP schema.

[1] http://www.w3.org/TR/CCPP-struct/
[2, 3, 4] etc

[5] http://www.isacat.net/citnames/2001/04/rpp.htm

Received on Monday, 16 April 2001 02:36:24 UTC