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

["Ugo Corda" <UCorda@SeeBeyond.com>]

Chris,

In the case of a choice, we can choose one element from the choice to be the element for the uninitialized case. If the path later on specifies a different choice element, we'll just replace the existing one.

In the case of a set of items, we could start with just one item. Then XPath would use the position function to specify whether we are dealing with a existing item or a new one.

Ugo

> -----Original Message-----
> From: Chris Keller [mailto:chris.keller@active-endpoints.com]
> Sent: Wednesday, August 06, 2003 3:14 PM
> To: Ugo Corda; ygoland@bea.com; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 11 - Partial Schema Compliance
> 
> 
> Ugo,
> 
> I don't think your suggestion will work, because you can have mutually
> exclusive elements in a complex type (choice).  Also it 
> doesn't address
> Danny's case of building up a set of items in a purchase 
> order response.
> 
> Chris
> 
> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
> Sent: Wednesday, August 06, 2003 5:34 PM
> To: ygoland@bea.com; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 11 - Partial Schema Compliance
> 
> Yaron,
> 
> How about saying that an uninitialized variable has always 
> the complete
> set of elements as specified in the corresponding schema, only their
> values are null? That way the schema validation should be ok 
> (except for
> possible constraints on the element values).
> 
> When I do the copy, the only case where the query yields zero nodes is
> when the query specifies a path that does not exist according to the
> schema. The copy operation is always a "find and replace", 
> never insert.
> The copy operation will turn the value of an element either 
> from null to
> the specified value, or from an old value to a new value.
> 
> Ugo
> 
> > -----Original Message-----
> > From: Yaron Goland [mailto:ygoland@bea.com]
> > Sent: Wednesday, August 06, 2003 11:20 AM
> > To: wsbpel@lists.oasis-open.org
> > 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
> 
> 
> 
> 
>