- From: Krishna Sankar <ksankar@cisco.com>
- Date: Fri, 13 Jun 2003 11:59:56 -0700
- To: "'Savas Parastatidis'" <Savas.Parastatidis@newcastle.ac.uk>, "'Steve Graham'" <sggraham@us.ibm.com>
- Cc: "'David Snelling'" <d.snelling@fle.fujitsu.com>, "'Jim Webber'" <jim.webber@arjuna.com>, "'Paul Watson'" <Paul.Watson@newcastle.ac.uk>, <public-ws-desc-state@w3c.org>, <public-ws-desc-state-request@w3.org>, "'Steve Tuecke'" <tuecke@mcs.anl.gov>
Hi all, > If adoption of a set of common operations that operate on attributes > would be useful, then I can see another WS-* spec. > <KS> This is that specification ! If we define the serviceData concept here and expect another specification to explain the operations on them, it will just add the proliferation of more WS-* specifications. We already have too many :o(. Our goal should *not* be to develop max number of specifications, but a few cohesive and coherent specifications. Point well taken on the independence from underlying implementations - may they be languages, OS platforms and such. But, we still need to define the interfaces of the common operations. The platforms and languages are free to implement them as they wish, leveraging their own idiosyncrasies. IMHO, as we are into the realm of stateful services (with state visibility thru the sericeData mechanism), we should *completely* define what that means. In this regard we need to touch upon security as well - I am thinking of visibility and access control of the serviceDataelements - how they can be expresses, exchanged, queried,.... IMHO, it would be better if we address the security interfaces in this specification, leaving, of course, the implementations to choose whatever mechanisms. I differentiate between mechanics and mechanisms - we define the mechanics, the platforms do the mechanisms. In that sense, these security aspects are NOT orthogonal to the serviceData mechanics. I think the OGSA/OGSI is too silent on security. I might be in the minority on this (hopefully not a minority of 1, especially on this Friday the 13th :o)) Cheers & have a nice weekend </KS> -k.
Received on Friday, 13 June 2003 15:00:41 UTC