RE: [provision] Liberty Identity Personal Profile example...

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

Jeff,
 
I think you are misinterperting the whole purpose of the batch request. The only reason that you would use a batch request would be to group logically related operations. While this is implementation dependent, I would think that a batch request going through workflow would be approved or denied as a whole. If operations or not logically related then they should be independent requests.
 
I am not a Liberty expert, but looking at the spec for the Personal Profile, it is very clearly LDAP oriented (or X.500 oriented). It would seem that a hierachical model would fit it quite well. But there are many solutions to this problem in addition to the ones I posted.
 
I do see a lot of value in adding explicit support for complex data types in the post 1.0 effort. Rami has made some interesting suggestions and I have some ideas on my own. The only requirement that I would make is that whatever approach we adopt can support reliable mamagement of the complex data. Obviously the Liberty group did not feel that was important since thier spec explicitly says that thier protocol does not support that.
 
Jeff Bohren
OpenNetwork Technologies
 
 

	-----Original Message----- 
	From: Jeff Larson [mailto:Jeff.Larson@waveset.com] 
	Sent: Thu 7/31/2003 4:29 PM 
	To: Gearard Woods; Jeff Bohren 
	Cc: provision@lists.oasis-open.org 
	Subject: RE: [provision] Liberty Identity Personal Profile example... 
	
	


	Sorry I haven't had time to remain current on this topic.  I don't
	have anything to say on the schema representation debate right now,
	but I did want to comment on the recent examples attempting to
	represent complex data types.
	
	I dislike the notion of describing what will usually be considered an
	atomic operation on a single object as a batch of SPML requests.  For
	starters, any PSP more complex than a directory will likely incur a
	substantial amount of overhead processing an add or modify request so
	you don't want to treat these like discrete transactions even though
	the end result may be the same.  It is not uncommon to require
	workflow approvals on any modification, this approach could result in
	multiple approvals.
	
	So now, the PSP has to analyze every batch to determine which requests
	can be semantically merged into a single transaction.  Batch execution
	mode better not be sequential.  A similarly complex inverse
	transformation then needs to be performed to make what internally was
	a single transaction appear as multiple responses in the batch
	response.
	
	Regarding the Hierarchical method:
	
	It isn't obvious to me how the DN-like <spml:id>'s work to identify
	subcomponents, but I'll assume that's due to my relative lack of LDAP
	experience.  I don't especially like the data duplication though.
	
	Regarding the Referential method:
	
	This looked more obvious to me than the Hierarchical method, but I
	would NOT want to be required to retain these GUIDs for later
	identification of the interior objects.  Again I would expect many
	PSPs that aren't implemented on directories are going to have problems
	maintaining GUIDs for things that are not "first class" objects in
	their database model.
	
	But if the GUIDs aren't retained, how do I issue a modifyRequest to
	change just the AltCN attribute?
	
	
	While I'm not necessarily suggesting this as a solution, Waveset
	solves very similar problems by flattening a complex hierarchical data
	model into a list of attributes whose names are "paths" into the
	hierarchy.  Our path syntax is non-standard, but for the sake of
	example,
	the little XML document would be exposed using the following
	attribute names:
	
	     InformalName
	     CommonName.CN
	     CommonName.AltCN
	     LegalIdentity.LegalName
	     LegalIdentity.VAT
	
	We're using this approach right now to squeeze extremely complex
	hierarchical objects through SPML.  We use the same technique to edit
	these objects in a web GUI.  HTML forms post a flat list of name/value
	pairs, you have the same problem.
	
	Yes, it is cumbersome.  I would really prefer complex data types in
	SPML, but this does work and I would choose it over the previous two
	methods because it maintains the atomicity of the request.
	
	I think we should continue exploring the consequences of introducing
	complex data types into SPML.  I just wanted to point out what I think
	is a simpler way to make complex data appear flat.
	
	Regards,
	Jeff