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:]
> Sent: Wednesday, August 06, 2003 3:14 PM
> To: Ugo Corda; ;
> 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:]
> Sent: Wednesday, August 06, 2003 5:34 PM
> To: ;
> 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:]
> > Sent: Wednesday, August 06, 2003 11:20 AM
> > To:
> > 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:]
> > Sent: Wednesday, August 06, 2003 10:08 AM
> > To:
> > 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:
> > For additional commands, e-mail:
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
>
>
>
>
