- From: Graham Klyne <GK@dial.pipex.com>
- Date: Thu, 25 May 2000 09:05:33 +0100
- To: "Hidetaka Ohto" <ohto@w3.org>
- Cc: <www-ccpp-protocol@w3.org>
At 02:16 PM 5/12/00 -0400, Hidetaka Ohto wrote: > > Finally, concerning the proposed use of "Profile-diff" headers. To me, > > this is mixing data formats with the protocol specification. The idea of > > expressing differences from some common feature set is, I think, a format > > issue, and the CC/PP format is being designed to address this. As such, I > > don't think it should be necessary to distinguish between "profile" and > > "profile-diff". > > > Here is one possible example approach: > > Profile-URI: <client-profile-URI> > > Profile-RDF: <RDF-expression> > > Profile-RDF: <RDF-expression> > > : > > Profile-RDF: <RDF-expression> > >In your possible example, you still distinguished the >list of URIs(Profile-URI) from the list of RDF expressions(Profile-RDF). >One of the main functions of "Profile" and "Profile-Diff" in the draft >is the same as those of Profile-URI and Profile-RDF. > >Basically I am not sure the difference between them. The sole purpose of Profile-URI in my proposal is to distinguish the "entry point" into the RDF graph: i.e. the resource that is the root of the graph describing the properties supplied. As such, it would specify a *single* URI, not a list. >My take on your opinion is that CC/PP descriptions should describe their >relationship (such as overriding/combining rules) by themselves as much as >possible. Yes, that's my opinion. >At the time I made the CCPPEX draft, CCPP itself does not have >precedence rules explicitly, therefore CCPPEX needed to have the function. >I agree there will be many details that are resolved as the CC/PP format >definition is firmed up. I understand ... my comments were made in light of an assumption that CC/PP would deal with these issues. (And the fact that I believe that it should not be the protocol's responsibility to contain structural information about the capability profile.) #g ------------ Graham Klyne (GK@ACM.ORG)
Received on Thursday, 25 May 2000 06:49:04 UTC