RE: [provision] PSO/Account/ProvisionedState

["Jeff Bohren" <jbohren@opennetwork.com>]

As I pointed out previouslly, the  near-universal operations are not really schema idependent. You still need to know what PSOs can be disabled, enabled, expired, etc. 
 
Jeff Bohren
OpenNetwork Technologies

	-----Original Message----- 
	From: Jeff Larson [mailto:Jeff.Larson@waveset.com] 
	Sent: Thu 3/25/2004 5:20 PM 
	To: Gearard Woods; Jeff Bohren 
	Cc: Gary Cole; provision@lists.oasis-open.org 
	Subject: RE: [provision] PSO/Account/ProvisionedState
	
	
	I haven't been following this that closely, but I like aspects of both approaches.  I like
	the notion that you can carry out near-universal operations like disable, enable, and expire, 
	in a schema independent way.  But I also like the notion that I can at least obtain the current state
	from the model so I don't have to make 42 web services calls to get everything I want to display.
	 
	I guess as long as the schema is arbitrary we can have it both ways.  If I choose
	to use fine grained standard operations I can.   If the PSP exposes the same functionality
	through the model, I can use that too, though I will be outside of the SPML spec.
	 
	But we're on a slippery slope here.  Almost every account will have an associated
	password, email address, and full name.  Do we then provide individual operations
	to get and set those so we can access them in an standard way without having to be
	bothered with PSP specific schema?  How far does this go?
	 
	Jeff
	 
	 
	 

		-----Original Message-----
		From: Gearard Woods [mailto:gewoods@us.ibm.com] 
		Sent: Thursday, March 25, 2004 3:35 PM
		To: Jeff Bohren
		Cc: Gary Cole; provision@lists.oasis-open.org
		Subject: RE: [provision] PSO/Account/ProvisionedState
		
		

		I think there's a fundamental difference here even though the intent may be the same. Basically, we're all trying to model state and provide some kind of standardized view of it to the outside world so that we can offer interoperability. By placing state in the resource schema you have immediately abandoned the possibility that arbitrary resource schema may be supported, which I believe to be important. You are also now requiring a mapping from the "standard" schema to the real resource schema. On the other hand, by placing the emphasis on the service provider and providing an operational interface to effect state changes, the provider can now apply its knowledge of the resource to make the state change however it wishes to do so and places no restrictions on the resource schema. 
		Gerry