OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [provision] Non-batchable operations.


I apologize for being out of the loop on the latest threads, but I am at the RSA show and my hotel internet connection was working until tonight. I am here supporting the SAML 2.0 interop which is being very well received. If any of you are at the RSA show and haven't seen the interop, you really should stop by. 
 
Anyway, the batchable request type was removed because it provided no value from an XSD standpoint. Since it was not adding any additional information to requests that are batchable, and because with the open content model it provided no validation, it was removed.
 
If someone can point out some value to having it, we could put it back.
 
So now the real question is what should normatively specified as batchable. I really don't see any value in normatively calling out certain verbs and declaring them batchable. I would lean towards leaving this unspecified.
 
 
Jeff Bohren

	-----Original Message----- 
	From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
	Sent: Wed 2/16/2005 11:44 AM 
	To: PSTC 
	Cc: 
	Subject: Re: [provision] Non-batchable operations.
	
	

	Darran Rolls wrote:
	
	> With many on the road this week, we should let this float on the list
	> for a week before drawing a close.
	> For my part, I agree with your assessment. 1-6 and say no to batchable
	> bulks (now there's a mouth full :-)
	>
	> One follow up question.  If one defines a new capability and one knows
	> that it will be problematic to handle bulk and batch, is there a
	> universal model for specifying "no batch" and "no bulk" on the
	> capability?
	
	No, as it stands there is not.
	- We lost the ability to say "batchable" when we dropped
	BatchableRequestType.
	- We never really *had* a way to say "mustBeSynchronous".
	
	1) The former (BatchableRequestType) disappeared in some version of the
	XSD.  I'm not sure whether there was a technical requirement that it
	disappear, or whether the XSD author(s) just thought that the model was
	cleaner without it.  However, Mr. Bohren has pointed out more than once
	that:
	- the XSD is *not* the specification; and
	- validation in many parsers is so weak that any restriction in the XSD
	   is likely not be enforced by the parser.
	
	Jeff, why did we get rid of BatchableRequestType?  Would anything break
	if we brought it back?
	
	2) The latter ("mustBeSynchronous") was not really on our radar in SPML
	1.0.  The choice of execution mode was always at the requestor's
	initiative, and the provider was free to say unsupportedOperation.
	
	Synchronous and asynchronous execution modes suddenly became a lot more
	important in SPMLv2 when we realized that (the possibility that
	provisioning operations require workflow--which in turn might require
	approvals--implies that) many operations could become asynchronous *at
	the provider's initiative*.
	
	gpc
	
	
	To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php.
	
	



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]