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




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