Chris Keller wrote:
Hi Ron,
Right, you
would also have child elements separating
the text (as per Alex’s elaboration of my example, thanks Alex). What
I was getting at is that there are many cases where /a/b/text() would
produce
more than one text node (or zero) and produce a selectionFailure.
On your
second point… Hmmm, I
am not sure what you mean by target variable. Do you mean the result
of
the <to>, which could be an EII, AII or TII?
My apologies; what I meant was "target variable infoset item," or, put
another (and as your surmised), the result the <to>.
If so then
I think we
are on the same page and yes I agree with your statement. It shows why
the replace part of the <copy> description should be described as
replace
contents, since you treat the return of <to> as a variable of
some xml
type itself. If I have an element of type xsd:int and an attribute of
type
xsd:int, I should be able to copy from that source element to that
attribute or
vice versa. This is at the heart of the table that Alex produced.
I think we converging. One point of clarification, however: Alex's
nifty table actually doesn't reflect XML Schema types, only infoset
item types. This avoids the problem of type conversion that was giving
Yaron headaches (which Yaron readily shared, BTW :-). XPath datatypes
aren't quite the same as XML schema simple types. The rules
accompanying Alex's table cover the use of simple-typed variables,
specifying conversion between XPath types and TII. Assignment to
a simple-typed variable can cause a bpws:mismatchedAssignmentFailure
fault if the source TII can't be converted appropriately.
Regardless, I believe we've answered Rania's original question.
-Ron
|