[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 255 - Proposal for vote
+1
I am not in favor of even mentioning dynamic changes in this spec.
Kind Regards
DK
Dieter König Mail: dieterkoenig@de.ibm.com IBM Deutschland Entwicklung GmbH
Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Schönaicher Strasse 220
Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 Böblingen
Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany
Danny van der
Rijn
<dannyv@tibco.com To
> Alex Yiu <alex.yiu@oracle.com>
cc
06.04.2006 18:59 ws bpel tc
<wsbpel@lists.oasis-open.org>
Subject
Re: [wsbpel] Issue 255 - Proposal
for vote
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
--------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]