Hi Danny and Dieter,
I understand your point of worrying about openning a Pandora's box and
the desire to make WSDL and XSLT more symmetrical. I am with you guys
on that one.
In the main part of Issue 11 proposal, it mentions the consistency
between XSLT and WS-BPEL and that needs to be enforced by static
analysis. It does not mention much about similar after static analysis.
Also, the dependency from the process definition to the XSLT is
relatively different from WSDL. The former uses parameters in an xpath
function. The later uses QName of a portType or messageType and etc in
a BPEL construct. The former dependency may be a bit subtle for people
to notice.
Hence, here is one more attempt to express a similar message without
mentioning the Pandora's box (i.e. dynamic update) at all. It says the
interface consistency needs to be observed all the time. Whether a
dynamic update may or may not happen is outside of this sentence.
-------------------------------
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). During process run-time, the interface of stylesheet (e.g. its parameters declared) SHOULD be always consistent with the counter part of the WS-BPEL process definition (e.g. parameters passing in).
-------------------------------
Does that sound better to you guys?
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
I understand your point, but part of what I was trying to do was not to
ever mention any of these artifacts changing. It's always possible to
change WSDLs (add portTypes, operations, add a fault to an existing
operation, add an import, modify ANYTHING concrete, ...) and Schemas
(add declarations, remove declarations that aren't used by the process,
change type derivation to less-restrictive types, ... ) in ways that
don't harm a running process, just like it's possible to do so for
XSLT. And similarly, changes can do great harm. We also make no
restrictions or mention of changes to things that are imported or
included by the WSDLs, Schemas, or style sheets.
We don't want to explicitly disallow change. But to explicitly allow
it is to open Pandora's box, IMO. Making no mention of it leaves the
field wide open for implementations, without muddying the spec in the
implications of such change.
Danny
Alex Yiu wrote:
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
|