[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]