[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 11 - Partial Schema Compliance
if we only validate when dealing with external services, i'm not sure i see much of a point of strongly typing the variables. not that i'm necessarily thinking that that's a bad idea, mind you.. danny ----- Original Message ----- From: "Chris Keller" <chris.keller@active-endpoints.com> To: "'Danny van der Rijn'" <dannyv@tibco.com>; <wsbpel@lists.oasis-open.org> Sent: Wednesday, August 06, 2003 2:58 PM Subject: RE: [wsbpel] Issue - 11 - Partial Schema Compliance > I'd vote for the validation "only when dealing with external services". > But in addition we should add a new function like > bpws:validateVariable('x'). This could return a Boolean, which would be > true if valid and false if not (or we could have it return a new bpel > type, which gave more info on what was invalid). In this way users can > build valid messages via assigns and then decide if and when they may > need to test the data (e.g. they can put it in a switch with a throw if > the data is invalid). But they should never receive or send out bad > data so that validation should be mandatory. > > -----Original Message----- > From: Danny van der Rijn [mailto:dannyv@tibco.com] > Sent: Wednesday, August 06, 2003 5:26 PM > To: wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue - 11 - Partial Schema Compliance > > I was going to raise this as a separate issue, and was just beginning to > write it up. Not sure if it should be a separate issue at this point or > not, since its existence as an issue depends on a solution to the > insertion > issue. > > I think that yaron's example can be easily fixed by saying that schema > validation occurs after all <copy> elements of an <assign> activity have > been completed, and not after each <copy> clause. So the example turns > into > something like: > > <assign> > <copy> > <from something or another that contains the integer value> > <to variable="Foo" part="p1" query="/foo/bar"/> > </copy> > <copy> > <from something or another that contains the Icky value> > <to variable="Foo" part="p1" query="/foo/icky"/> > </copy> > </assign> > > however, if the validation boundary (more on this in a sec) is arrived > at, > and there is a validation problem, a new standard fault needs to be > thrown: > > invalidVariableContent - Thrown when the content of a variable fails > validation > > it would be nice if the fault could include information about which > variable > it was. > > but that only fixes your example. here's a more difficult example: > > a variable has 2 parts, both required, one of which is repeating and has > cardinality > 1. Think of a purchase order request/response, as a > common > example > > Variable: PO > Part: PO > Schema: > <PurchaseOrder> > <PurchaseOrderID/> > <LineItem/>+ > </foo> > > Variable: POResponse > Part: POResponse > Value: Uninitalized > Schema: > <PurchaseOrderResponse> > <PurchaseOrderID/> > <LineItemResponse/>+ > </foo> > > Variable: LineIn > Part: LineIn > Schema: <LineItem/> > > Variable: LineOut > Part: LineOut > Schema: <LineItemResponse/> > > Now imagine that the process <receive>s a PO, and loops over each line > item > to construct a response. imagine the following code fragments (an > analogous > example inside a <sequence> is trivial to imagine): > > <flow> > ... > <assign name="AssignID"> > <copy> > <from variable="PO" part="PO" > query="/PurchaseOrder/PurchaseOrderID"/> > <to variable="POResponse" part="POResponse" > query="/PurchaseOrderResponse/PurchaseOrderID"/> > </copy> > <assign> > ... > <while "there are line items, loop over them"> > > <assign> > <copy> > <from variable="PO" part="PO" > query="/PurchaseOrder/LineItem[loopIndex]" /> > <to variable="LineIn"/> > </copy> > </assign> > > <invoke operation="ProcessOrderLine" inputVariable="LineIn" > outputVariable="LineOut"/> > > <assign name="AssignResponseLine"> > <copy> > <from variable="LineOut"/> > <to variable="POResponse" part="POResponse" > query="/PurchaseOrderResponse/LineItemResponse[loopIndex]"/> > </copy> > </assign> > > </while> > ... > </flow> > > if the AssignID <assign> is reached first, it would cause an > invalidVariableContent fault to be raised, since there are no line > items. > if, however, the AssignResponseLine <assign> is reached first, it would > cause the same, since there is no PurchaseOrderID > > i don't really have a nice solution to this problem. i do have some > thoughts, though, not that i like any of them. > > - create an attribute on some (proper?) subset of activities stating > that > some list of variables (/subparts?) is to be exempt from validation > during > the execution of the activity. then, for instance, you can wrap the > above > code fragment with an <empty> or <scope> (or whatever) that has the > attribute novalidation="POResponse/POResponse" (syntax is > variable/part?). > validation would occur upon completion of the activity. > > - don't be so granular: validation="no" simpler to deal with for the > language, doesn't provide as much benefit to the user of a strongly > typed > system. > > - implicitly allow what yaron calls "automatic incremental validation." > question then is when is full validation enforced. i'm not sure that > yaron's proposal of "only when dealing with external services" is good > enough. > > - never validate(!) > > - programming convention (as per yaron) with type <any> shamelessly > overused. > > BPEL makes use of a strongly typed system, but current limitations makes > it > unusable. to paraphrase yaron: > > > The issue here is one of programming model friendliness. For BPEL to > be > > successful we need a programming model that programmers will be > comfortable > > with and I'm fairly confident that [one where data is messy to deal > with] > isn't > > one programmers are going to successfully use. > > danny > > ----- Original Message ----- > From: "Yaron Goland" <ygoland@bea.com> > To: <wsbpel@lists.oasis-open.org> > Sent: Wednesday, August 06, 2003 11:19 AM > Subject: [wsbpel] Issue - 11 - Partial Schema Compliance > > > > A related issue is what happens if the copy results in a non-schema > > compliant value? > > > > For example: > > > > Variable: Foo > > Part: P1 > > Value: Uninitialized > > Schema: > > <foo> > > <bar>INT</bar> > > (<blah/>|<icky/>) > > </foo> > > > > Now lets say that the programmer is building up the Foo value. Some > event > > has occurred which has told the programmer the value that bar should > have > so > > naturally the programmer wants to execute: > > > > <copy> > > <from something or another that contains the integer value> > > <to variable="Foo" part="p1" query="/foo/bar"/> > > </copy> > > > > Assuming we use the idea that queries on to elements that resolve to 0 > nodes > > are inserts and assuming we accept that in cases where there are no > siblings > > of the insertion point then there is no need to use > beforeinsertionPoint > or > > afterinsertionPoint since the insertion point is unambiguous then the > result > > would be: > > > > <foo> > > <bar>Whatever the INT value was that got copied in</bar> > > </foo> > > > > But this result violates the schema for the Foo variable which > mandates > the > > presence of either a blah or icky element in addition to the bar > element. > > Therefore the COPY would fail schema validation. > > > > It looks to me like the way to get around this problem is to define a > > variable Temp whose schema is <ANY> and then build the legal foo value > there > > and when one has successfully put everything together then one can > copy > that > > value into Foo. But doesn't that seem ham fisted to anyone? In essence > it > > means that all values are untyped until the last possible moment when > one > > has a big bang attempt to set the value and see if it is schema > compliant. > > > > Another approach would be to define a temp variable whose schema was: > > > > Variable: Temp > > Part: P1 > > Value: Uninitalized > > Schema: > > <foo> > > <bar>INT</bar>? > > (<blah/>|<icky/>)? > > </foo> > > > > This would allow one to build up the temp value incrementally and > still > get > > schema validation. Then when one was done one could copy the result > into > > Foo. > > > > But the level of sophistication this requires on the part of the > > programmers, e.g. the ability to take all of their typed values, > analyze > > them and figure out how to re-write their schemas so as to allow for > partial > > validation, seems way beyond the norm. > > > > What I suspect will really happen is that programmers will learn to > define > > their temp variables as schema type <ANY>. They will build up their > values > > inside of the <ANY> variables and then when they are done they will > try to > > copy from the temp variable into the final location (Foo in this case) > and > > pray it works. If it doesn't they are probably out of luck since it is > > unlikely that they will be able to do much with the error message. > > > > A workable programming model demands a way to build up values > incrementally > > with feedback on validity (e.g. error: the element you just inserted > does > > not exist in the schema). > > > > What I think we need is a model where when manipulating variables one > can > > get some sort of automatic incremental validation and only when trying > to > > communicate the value externally through a Web Service message will > you > get > > full validation where the value must be perfect or you get an error. > > > > For example, in an incremental validation model the programmer could > execute > > the following assuming Foo is uninitialized: > > > > <copy> > > <from something or another that contains the integer value> > > <to variable="Foo" part="p1" query="/foo/bar"/> > > </copy> > > > > The result is that Foo would contain <foo><bar>Some INT</bar></foo> > which > is > > 'partially' valid. E.g. it doesn't fully specify the schema but it > doesn't > > contradict it either. > > > > However, in a partial schema validation model the following would be > > illegal: > > > > <copy> > > <from something or another that contains the integer value> > > <to variable="Foo" part="p1" query="/foo/bark"/> > > </copy> > > > > The reason being that /foo/bark/ does not exist in the schema and so > could > > never be valid. > > > > The issue here is one of programming model friendliness. For BPEL to > be > > successful we need a programming model that programmers will be > comfortable > > with and I'm fairly confident that a model in which all variables stay > > untyped while they are being built up until the last possible instant > isn't > > one programmers are going to successfully use. > > > > Just a thought, > > > > Yaron > > > > > > -----Original Message----- > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > Sent: Wednesday, August 06, 2003 10:08 AM > > To: wsbpel@lists.oasis-open.org > > Subject: [wsbpel] Issue - 11 Query in <to> close should allow > assigning > > to new locations > > > > > > I would like to open discussion on this issue (and volunteer to > champion > > it). > > > > The issue is that in section 14.3 dealing with assignment, there is > the > > following verbiage: > > > > "For XPath 1.0, the value of the query attribute MUST be an absolute > > locationPath (with '/' meaning the root of the document fragment > > representing the entire part). It is used to identify the root of a > subtree > > within the document fragment representing the part. <b>The location > path > > MUST select exactly one node. If the location path selects zero nodes > or > > more than one node during execution, then the standard fault > > bpws:selectionFailure MUST be thrown by a compliant > implementation.</b>" > > (emphasis added) > > > > This means that the only way to get an initialized value into a > variable > is > > to receive a message from elsewhere. This is, I believe, far too > > restrictive. I propose that the wording be changed to > > > > "For XPath 1.0, the value of the query attribute MUST be an absolute > > locationPath (with '/' meaning the root of the document fragment > > representing the entire part). It is used to identify the root of a > subtree > > within the document fragment representing the part. <b>When the > expression > > is used inside a <from> element, the location path MUST select exactly > one > > node. If the location path selects zero nodes or more than one node > during > > execution, then the standard fault bpws:selectionFailure MUST be > thrown by > a > > compliant implementation. When the expression is used inside a <to> > > element, and it selects 0 nodes, then the expression should be treated > as > > the location that the value will have after it is inserted.</b>" > > > > This probably isn't the best wording, and I'd love someone to clean it > up > a > > bit, but I think you get the general idea. > > > > Danny van der Rijn > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]