Hi Danny and others,
After more thinking, the nature of XSLT artifact is not exactly like
WSDL artifact. BPEL makes uses of WSDL only as an interface definition
language (i.e. the abstract part of WSDL). On the other hand, BPEL
makes uses of XSLT more than an interface. It make uses of its
execution logic as well. The interface parts of XSLT are its global
parameters and input documents. The execution logic is XSLT's
transformation logic.
I guess the intention of wording is to highlight the XSLT artifact can
be updated during runtime, its transformation logic can be changed as
long as its interface with BPEL remains intact / defined after the
change.
That's why I changed from my "on-the-fence" position to "no" regarding
removal of those wordings.
I don't think a complete removal of such wordings is a good choice.
How about the following: (based on Danny's suggested wording)
The first XPath function parameter, which locates the style sheet, is intended to have the similar semantics as the location attribute of an <import> element. The differences are only in syntax. Style sheets associated with a process (through its doXslTransform invocations) SHOULD be considered part of the process definition, and in
most situations would not change at run-time in a similar manner to WSDL definitions and XML Schemas referenced by an <import> element.
However, WS-BPEL processors MAY dynamically update associated style sheets at run-time, as long as all requirements of this specification are still met (in particular, the semantics of "atomic" assignment and
serialized scopes). Transformation logic inside style sheets MAY be updated dynamically during process run-time, as long as its interface (e.g. its parameters) with the process definition remains intact.
I guess people may still need to think more about the last sentence
("Transformation ...") added there. I tend to think it better captures
the difference between a WSDL and an XSLT. It may answer people's
question on why this statement needs to be here but not for WSDL.
Actually, this difference applies not just to XSLT, but to any future
artifact that combines "interface"+"execution-logic".
I am open to more rewording of the last sentence.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
I propose the following choice of alternatives:
Alternative A:
In Section 8.4
Change:
Style sheets associated with a process (through its doXslTransform
invocations) are considered part of the process definition, and in
most situations would not change at run-time. However, WS-BPEL
processors MAY dynamically update associated style sheets at
run-time, as long as all requirements of this specification are still
met (in particular, the semantics of "atomic" assignment and
serialized scopes).
To:
The first XPath function parameter, which names the style sheet, is intended
to have the same semantics as the location attribute of an <import> element.
The differences are only in syntax.
Style sheets associated with a process (through its doXslTransform
invocations) SHOULD be considered part of the process definition, and in
most situations would not change at run-time
in a similar manner to WSDL definitions and XML Schemas referenced by an <import> element.
However, WS-BPEL
processors MAY dynamically update associated style sheets at
run-time, as long as all requirements of this specification are still
met (in particular, the semantics of "atomic" assignment and
serialized scopes).
Alternative B (comes without
spec wording at the moment):
- Add another importType, http://www.w3.org/1999/XSL/Transform.
- Require the first parameter of doXslTransform to be a string literal
that matches an <import>ed "location" of the XSLT importType
stated above.
Danny
Simon D Moser wrote:
Hi all,
as discussed in the Call today, I move to vote on my submitters proposal to
remove the text mentioned below from section 8.4
Status: received
Date added: 25 Mar 2006
Categories: Other specifications
Date submitted: 24 March 2006
Submitter: Simon Moser
Description: The Text 8.4 about the dynamicity of XSLT should be removed
In Section 8.4, there is some text (which used to be a footnote):
Style sheets associated with a process (through its doXslTransform
invocations) are considered part of the process definition, and in
most situations would not change at run-time. However, WS-BPEL
processors MAY dynamically update associated style sheets at
run-time, as long as all requirements of this specification are still
met (in particular, the semantics of "atomic" assignment and
serialized scopes).
We (TC at f-t-f, Stuttgart) think that talking about dynamically changing
of XSLT artifacts is out of scope for the specification, since we do not
talk about dynamically changing WSDL or XSD files that are referenced from
the process, too.
Cheers
/Simon
--------------------------------------------------
Simon Daniel Moser, M.Eng.
Business Process Solutions Development 1
IBM Boeblingen Laboratory
Schoenaicherstr. 220, 01/086
D - 71032 Boeblingen
Tel.: +49 - 7031 - 164304
IP Telephone Number (ITN): 39204304
email: smoser@de.ibm.com
Rule of thumb #3459835478: when you find yourself typing/copying the same
thing more than twice in a row, redesign or re-implement. No excuse
possible.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|