Alexandre Alves wrote:
-
Considering
that we are using XML info-set terminology, I was wondering if we
should say ‘as
the document element property of the source DII’ instead of ‘as
the single child of the root node of the source tree’ when
explaining the source node-set?
The intent was to use infoset terminology when dealing with WS-BPEL
features, and XSLT (including XPath 1.0) terminology when dealing with
XSLT-specific features. I'll review the proposal to make sure that I've
been consistent in this regard, but I don't think it would be helpful
to remove all XPath terminology when specifying how XSLT is to be used
by the WS-BPEL processor.
-
I was
under the impression that XSLT variables and params are identified by a
QName, so
shouldn’t we name the BPEL variables as ‘bpws:foo’? Or was the
rationality to keep the names unqualified for simplicity sake? The
advantage of
qualifying them using the BPEL URI would be that it avoid name clashes,
wouldn’t
it?
Yes, XSLT variables/params have qualified names, whereas WS-BPEL
variables have unqualified (NC) names. The decision to match on ncnames
was for simplicity, readability/consistency, and based on the
observation that in "real life" XSLT variable and parameter names are
very rarely qualified. Matching on a WS-BPEL-specific XML name space
for global parameter names (bpws:foo) would certainly clearly mark such
parameters as intended for WS-BPEL variable matching, at the loss of
some simplicity.
-
As
doXslTransform
is a xpath function, it can in theory be used in while condition
expressions,
join condition expression, until expression, etc. Is this allowed? If
it is,
shouldn’t we propagate BPEL links, partnerLinks, and properties, to the
XSLT engine as well?
It can be used in any place an XPath expression is allowed, except join
conditions, which are highly restricted. We could choose to restrict
where the doXslTransform function can be called (perhaps to
<from> expressions only?), but that isn't part of the current
proposal, and I suspect we'd need a good motivation to include such a
restriction.
Other values (links and properties) can be communicated via variables,
exception partner links, which are opaque. Our goal was to provide a
portable solution to Issue 11 in a minimal fashion.
Also,
although this is not relevant to
this proposal in question, I think it is interesting to consider that
the
XUpdate committee has re-started its activities recently…
It would be wonderful if XUpdate were complete; it would be a good fit
to our needs. I sincerely hope that WS-BPEL 2.0 will be complete long
before XUpdate is; perhaps WS-BPEL 2.1?
Best regards,
-Ron
|