OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


I should have used a different term instead of null.

What I was proposing is that we think of an uninitialized variable as a document that has all the elements as specified in the schema (modulo the issue about choices and lists, discussed before), but where the value (string contents) of all terminal elements (leaves) is empty.

An assignment either puts a value in those empty elements or changes a previous value to something else (case of already initialized element).

So, to take your schema example <foo><bar/><yack/></foo>, an uninitialized variable of that type would look like:

<foo>
	<bar/>
	<yack/>
</foo>

so I don't have to worry whether a particular element has already been introduced by previous assignment when I use a path expression: all elements are all already there.

The same variable, once initialized, might look like:

<foo>
	<bar>
	hello
	</bar>
	<yack>
	there
	</yack>
</foo>

Ugo

> -----Original Message-----
> From: Yaron Goland [mailto:ygoland@bea.com]
> Sent: Thursday, August 07, 2003 1:56 PM
> To: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 11 - Partial Schema Compliance
> 
> 
> I could also fairly happily live with 'validation only for external
> services' with the introduction of the validateVariable 
> function but only if
> we do enforce partial validation. What I mean by partial 
> validation is that
> if what you put into the variable can never result in a 
> schema compliant
> value then the assign fails.
> 
> If the schema is:
> <foo><bar/><yack/></foo>
> 
> and you do an assign of <foo><blah/></foo> then the assign should fail
> because the result is 100% invalid. That is different than an 
> assign of
> <foo><bar/></foo>. Technically the result is still invalid 
> (there is no
> <yack/>) but it is at least 'partially' valid. Programmers need help
> building valid structures which is why partial validation is 
> so important.
> 
> I also have to admit that I don't fully understand Ugo's 
> proposal for using
> null. Null (through the nillable declaration) is an explicit 
> state in XML
> Schema so it would seem that Ugo's proposal would require changing a
> schema's definition if the schema doesn't use nillable. My 
> suspicion is that
> I just don't understand his proposal.
> 
> 		Yaron
> 
> -----Original Message-----
> From: Chris Keller [mailto:chris.keller@active-endpoints.com]
> Sent: Wednesday, August 06, 2003 2:59 PM
> To: 'Danny van der Rijn'; wsbpel@lists.oasis-open.org
> 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
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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]