Re: [wsbpel] Issue - 11 - Partial Schema Compliance

["Danny van der Rijn" <dannyv@tibco.com>]

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