Hi, all,
Regarding to why we want to pair-up the syntax-level NS-URI and
semantic-level extensionURI together, I have explained already in this
email thread.
I want to achieve the advantage of providing a formal way to decouple
syntax and semantic (from Yaron's proposal) while keep the approach of
using namespace to: (a) partition different extensions (from Dieter's
proposal) (b) to lookup the owner / definer of extension.
Let me illustrate the advantages of combining these 2 approach by the
following example:
Say, a BPEL user somehow gets a version of BPEL source code as follows:
Using the "balanced" / hybrid approach:
---------------------------------
<process>
<extensions>
<extension namespace="http://foo.com"
extensionURI="http://foo2impl.com"
mustUnderstand="yes" />
<extension namespace="http://bar.com"
extensionURI="http://bar2impl.com"
mustUnderstand="no" />
</extensions>
<scope>
<foo:ExtElem1> ... </foo:ExtElem1>
<bar:ExtElem3 />
...
</scope>
</process>
---------------------------------
And, the BPEL user is using a BPEL editor that understands
"http://foo2impl.com"
extension. It can perform some extra validation
on <foo:ExtElem1>. Hence it address Yaron's concern of
error-prone typo issue.
The BPEL editor can safely ignore whatever extension under "bar"
namespace even WITHOUT understanding. (as long as they are well-formed
XML)
Now expressing the same BPEL source, using pure-"Yaron's" approach:
---------------------------------
<process>
<extensions>
<extension extensionURI="http://foo2impl.com" />
<extension extensionURI="http://bar2impl.com" />
</extensions>
<scope>
<foo:ExtElem1> ... </foo:ExtElem1>
<bar:ExtElem3 />
...
</scope>
</process>
---------------------------------
All definitions of extension are now COMPLETELY opaque and "stored"
inside those 2 extensionURIs. Say, the BPEL editor that is being used
understands "http://foo2impl.com"
but NOT "http://bar2impl.com".
Can
the editor safely ignore <bar:ExtElem3> ? The answer is NO,
unless the BPEL edtiors understand all extensionURI used in this BPEL.
Because, it even CANNOT identify WHICH extension URI controls the
meaning of <bar:ExtElem3 />.
Now expressing the same BPEL source, using pure-"Dieter's"
approach:
---------------------------------
<process>
<extensions>
<extension namespace="http://foo.com" mustUnderstand="yes" />
<extension namespace="http://bar.com" mustUnderstand="no" />
</extensions>
<scope>
<foo:ExtElem1> ... </foo:ExtElem1>
<bar:ExtElem3 />
...
</scope>
</process>
---------------------------------
- Lack of explicit information on where to fetch extra validation
information for <foo:ExtElem1> and <bar:ExtElem3>. (that
is: one of Yaron's concerns)
- If we just follow the semantics in this proposal, the relation
between NS-URI and extension definition virtually must be an one-to-one
relationship. (instead of one-to-many relationship). It makes the
reusing the syntax across multiple semantic definition virtually
impossible. One important usage of this feature is:
- to release multiple versions of implementation from the same
vendor without forcing people to change NS-URI used in extension in the
source code. e.g.:
<extension namespace="http://foo.com"
extensionURI="http://foo2impl.com/v1.0.0"
/>
<extension namespace="http://foo.com"
extensionURI="http://foo2impl.com/v1.0.1"
/>
<extension namespace="http://foo.com"
extensionURI="http://foo2impl.com/v1.1.0"
/>
This allows BPEL developers to upgrade / downgrade versions of
extension components selectively at their own will and pace without
asking them to change their source code extensively.
Enabling versioning of source code is a very critical feature, if we
forsee BPEL source codes will be generated and used as a programming
langauge extensively in a business organization.
If people consider this feature is an over-engineering, then the same
argument would be applied to xsi:schemaLocation feature of XML Schema.
(I got to admit that there are a number of too-advanced features in XSD
for average users. But, xsi:schemaLocation is NOT one of them.)
Hope this email help.
Thanks!!!
Regards,
Alex Yiu
Yaron Y. Goland wrote:
I can't
imagine why you would argue that editors and such don't matter to me
since I have repeatedly argued that they are critical to BPEL. However
I still don't see how your point applies.
Can you please provide an example where namespace provides any real
help to someone trying to use a generic BPEL editor with a BPEL
instance that has custom extensions? I.e. show an example of some
critical feature that works if we use the namespace attribute but fails
if we don't? Can you also please define the semantics of a
'mustUnderstand' extension in that scenario?
Thanks,
Yaron
Danny van der Rijn wrote:
Unfortunately, you missed some interesting
discussion on this about 30
seconds after the F2F officially adjourned.
My problem with your proposal is that it completely cuts any loosely
integrated tools, such as editors, syntax validators, etc., out of the
picture. You may argue that they don't matter, but that's where we
would disagree.
Danny
Yaron Y. Goland wrote:
> Dieter and Alex's proposals both attempt to specify the syntax of
> extensions. But that is error prone (as I explain in my blog
article)
> and completely unnecessary.
>
> All that is necessary is a simple list of what extensions are
> supported where extensions are opaque IDs.
>
> When an engine runs a BPEL it looks at the extension IDs and sees
> which ones are marked mandatory. If one is marked mandatory that
the
> engine doesn't support then the BPEL fails.
>
> Assuming all mandatory extensions are supported then when the
BPEL
> processes the BPEL file it simply ignores any elements or
attributes
> it doesn't recognize. There is therefore no need to explicitly
specify
> anything about syntax since the BPEL processor doesn't care. The
only
> thing the BPEL processor cares about are the elements and
attributes
> it DOES support and it already knows what those are.
>
> Generally speaking simpler is better and there is nothing simpler
then
> just specifying an opaque ID.
>
> Yaron
>
> Francisco Curbera wrote:
>
>> My short summary of this discussion is this:
>>
>> 1. There is a very clear case for allowing an engine to
decide if an
>> extension is required by looking at... the extension element
itself!
>> Not a
>> bad idea that Alex explains quite clearly. This is what
Dieter's
>> proposal
>> allows.
>>
>> 2. There are ways in which we can add into BPEL explicit
support for
>> overloading the semantics of extension elements. This may or
may not
>> be a
>> good idea, but the answer to that question clearly reaches
far beyond
>> BPEL.
>> That notion is at the same time powerful and tricky, as the
discussion
>> between Alex and Yuzo shows.
>>
>> Somehow #2 sounds to me like a clear case of
over-engineering; I don't
>> think we should go there unless a very compelling use case
(not an
>> abstract
>> example) is provided to justify it.
>>
>> Paco
>>
>>
>>
>>
>>
>>
>> Yuzo
>>
Fujishima
>>
>>
>> <fujishima@bc.jp. To:
wsbpeltc
>>
<wsbpel@lists.oasis-open.org>
>> nec.com> >>
cc:
>>
>>
>> Subject: Re:
[wsbpel]
>> Issue 92 - 92.1 - a newer and potentially unifying
proposal >> 03/18/2005
>>
12:47
>>
>>
>> >>
AM
>>
>>
>>
>>
>>
>>
>>
>>
>> Alex,
>>
>> Thank you for the response. Please see my comments in-line.
>>
>> Alex Yiu wrote:
>> >
>> > Yuzo,
>> >
>> > Thanks for your very constructive reply.
>> >
>> > Regarding to your point (1):
>> >
>> > The reason that I am making namespace mandatory while
extensionURI
>> > optional is: to retain an original feature in Dieter's
proposal -
>> i.e.:
>> > we can decide whether an extension construct is
"mustUnderstand"
>> by just
>> > looking up its namespace URI. This is a good and
important
>> feature to
>> > maintain. E.g.:
>> >
>> > <scope>
>> > <foo:ExtElem />
>> > <bar:ExtElem />
>> > ...
>> > </scope>
>> >
>> > BPEL tool can know that <foo:ExtElem /> is a
"mustUnderstand", while
>> > <bar:ExtElem /> is NOT.
>> >
>> > To further illustrate my example:
>> >
>> > <process>
>> > <extensions>
>> > <extension namespace="http://bar.com"
<http://bar.com>
>> > extensionURI="http://bar2impl.com"
<http://bar2impl.com>
>> > mustUnderstand="no" />
>> > </extensions>
>> > <scope>
>> > <bar:ExtElem />
>> > ...
>> > </scope>
>> > </process>
>> >
>> > The above process definition can be processed by a BPEL
engine which
>> > does not understand "http://bar.com"
<http://bar.com> and safely
>> > disregard the existence of <bar:ExtElem />
regardless of extensionURI
>> > value used in the declaration.
>> >
>> > Let me paraphrase myself. I think it is important to
enable us to
>> find
>> > *THE* "owner" of extension definition by looking up
namespace.
>> Using the
>> > same example:
>> >
>> > <bar:ExtElem />
>> > ==> Namespace is: "http://bar.com"
<http://bar.com>
>> > ==> Definition Owner is: "http://bar2impl.com"
>> <http://bar2impl.com>
>> >
>> >
>>
>> The namespace attribute is truly useful only when the
extension need not
>> be understood. In other words, all that an engine needs is
the following
>> rule: "An extension element that belongs neither of the
namespaces of
>> the optional extensions must be understood."
>>
>> In my approach, the namespace attribute must be specified
only when the
>> extension is optional (need-not-be-understood) and the
namespace is
>> different from the extension URI. (If the namespace is not
explicitly
>> specified for an optional extension, the value of the
extension URI is
>> used instead.)
>>
>> > IMHO, the following usage (one namespace defined by
multiple
>> extension
>> > URI) should be disallowed. Otherwise, it will open a
BIG can of
>> worms:
>> >
>> > <extensions>
>> > <extension namespace="http://bar.com"
<http://bar.com>
>> > extensionURI="http://bar2impl.com"
<http://bar2impl.com>
>> > mustUnderstand="no" />
>> > <extension namespace="http://bar.com"
<http://bar.com>
>> > extensionURI="http://bar3impl.com"
<http://bar3impl.com>
>> > mustUnderstand="yes" />
>> > </extensions>
>>
>> Disallowing is OK for me, but we may be able to allow it.
>>
>> Case A: The engine supports the http://bar3impl.com but not
>> http://bar2impl.com
>>
>> In this case, the engine should know specific
elements/attributes in the
>> http://bar.com namespace that are relevant to extension
>> http://bar3impl.com. All other elements/attributes in the
namespace
>> should be for http://bar2imp.com and ignorable.
>>
>> Case B: The engine supports neither.
>>
>> In this case, the engine may erroneously reject a process
definition
>> that contains elements/attributes for http://bar2impl.com
only and does
>> not contain those for http://bar3imp.com because the engine
cannot
>> distinguish elements/attributes for bar2impl from those for
bar3impl.
>>
>> But I don't think this error severe. Just removing the
extension
>> declaration for bar3impl should do.
>>
>> Could you elaborate on what you are worrying about?
>>
>> >
>> >
>> > Regarding to your point (2):
>> >
>> > Whether it is a justified design to all an extensionURI
to point
>> to 2 or
>> > more namespaces are something that we need to think
about.
>>
>> I agree.
>>
>> > Unfortunately, it's kind of outside the scope of this
TC to
>> dictate the
>> > details of interpretation of extensionURI. So, in
short, we should
>> still
>> > allow that happen.
>> >
>> > When this happens, I would say I prefer syntax listed
in (B). I
>> > understand it can be a bit verbose. However, it allows
me to
>> achieve two
>> > things:
>> >
>> > (I) Consider this example:
>> >
>> > <extensions>
>> > <extension extensionURI="theExtension"
namespace="namespaceOne"
>> > mustUnderstand="yes"/>
>> > <extension extensionURI="theExtension"
namespace="namespaceTwo"
>> > mustUnderstand="*no*"/>
>> > </extensions>
>> >
>> >
>> > The "yes" and "no" contrary above is intentional. It is
definitely
>> > conceivable that one extensionURI defines extensions of
multiple NS,
>> > where some of them are "mustUnderstand" and some of
them are NOT.
>>
>> IMHO, if an extension allows "partial support", it is the
extension,
>> not the namespace(s), that is to be split, primarily.
>>
>> Suppose extension A allows partial support. Then A should be
split into
>> A1, A2, ... and so on. The namespaces may also be split, but
the
>> namespace splitting is secondary to that of the extension.
>>
>> >
>> > (II) Again, being able to lookup the "owner" of
extension
>> construct by
>> > looking up namespace URI is a very important feature.
>> >
>> > All in all, it really depends on whether you look at
the problem
>> from a
>> > syntax-oriented viewpoint or from a semantic-oriented
viewpoint.
>> > Unfortunately, for the latter case, interpretation of
extensionURI is
>> > out of this TC scope. Otherwise, I would lean towards
to your
>> approach.
>> >
>> > Another important clarification to add:
>> >
>> > Advanced cases of mixed namespace managment within ONE
extension
>> point.
>> > Consider this example:
>> >
>> > <process>
>> > <extensions>
>> > <extension namespace="http://foo.com"
<http://foo.com>
>> > extensionURI="http://foo2impl.com"
<http://foo2impl.com>
>> > mustUnderstand="yes" />
>> > <extension namespace="http://bar.com"
<http://bar.com>
>> > extensionURI="http://bar2impl.com"
<http://bar2impl.com>
>> > mustUnderstand="yes" />
>> > </extensions>
>> > <scope>
>> > <foo:ExtElem1> <bar:ExtElem2 />
</foo:ExtElem1>
>> > <bar:ExtElem3 />
>> > ...
>> > </scope>
>> > </process>
>> >
>> > We should EITHER saying the above usage is illegal?
>> >
>> > OR: it works with the following example semantics?
>> >
>> > The semantics of "<foo:ExtElem1> <bar:ExtElem2
/> </foo:ExtElem1>"
>> > should be under the domain of "http://foo2impl.com"
>> <http://foo2impl.com
>> >.
>> >
>> > The semantics of "<bar:ExtElem3 />" should be
under the domain of
>> > "http://bar2impl.com" <http://bar2impl.com>.
>>
>> I think we should consider
>> <foo:ExtElem1> <bar:ExtElem2 />
</foo:ExtElem1>
>> as being belonging to extension http://foo2impl.com.
>>
>> Generally speaking, inside an extension element, there can
appear
>> a lot of elements/attributes that does not belong to the same
namespace
>> as the extension element.
>>
>> Yuzo Fujishima
>> NEC Corporation
>>
>> >
>> >
>> > Again, this illustrates another aspect of the design of
looking up
>> the
>> > "OWNER" of extension by just doing namespace and XML
information
>> items
>> > analysis.
>> >
>> >
>> >
>> > If the TC feels comfortable with viewpionts expressed
above, I would
>> > consolidate these clarification to my "newer" proposal.
(Sorry
>> rushing
>> > out my previous email out.)
>> >
>> >
>> >
>> > Thanks!
>> >
>> >
>> >
>> > Regards,
>> > Alex Yiu
>> >
>> >
>> >
>> > Yuzo Fujishima wrote:
>> >
>> >>Hi,
>> >>
>> >>I would like to make two points.
>> >>
>> >>Point 1: Make extenstionURI mandatory rather than
namespace
>> >>
>> >>An extension defines the namespace(s) it uses, not
vice versa. In
>> other
>> >>words, if an engine knows an extension, it should
know the
>> namespace(s)
>> >>used. Specifying namespace(s) in addition to the
extension URI is
>> >>redundant per se.
>> >>
>> >>Therefore, for me, it makes more sense to make
>> >> namespace attribute optional
>> >>and
>> >> extensionURI attribute mandatory.
>> >>
>> >>Point 2: More than one namespace for an extension
>> >>
>> >>In my opinion, using more than one namespace for an
extension
>> should be
>> >>rare. But I may be wrong, as at least Yaron seems to
have a use case.
>> >>
>> >>If we are to allow using more than one namespace for
an extension,
>> >>extension declaration should look like:
>> >>
>> >>(A1)
>> >><extensions>
>> >> <extension extensionURI="theExtension"
mustUnderstand="yes">
>> >> <namespace>namespaceOne</namespace>
>> >> <namespace>namespaceTwo</namespace>
>> >> </extension>
>> >></extensions>
>> >>
>> >>or:
>> >>
>> >>(A2)
>> >><extensions>
>> >> <extension extensionURI="theExtension"
mustUnderstand="yes"
>> >> namespaces="namespaceOne namespaceTwo"/>
>> >></extensions>
>> >>
>> >>rather than:
>> >>
>> >>(B)
>> >><extensions>
>> >> <extension extensionURI="theExtension"
namespace="namespaceOne"
>> >> mustUnderstand="yes"/>
>> >> <extension extensionURI="theExtension"
namespace="namespaceTwo"
>> >> mustUnderstand="yes"/>
>> >></extensions>
>> >>
>> >>B is more redundant and error-prone; what should
happen if
>> >>mustUnderstand is yes for one and no for the other?
>> >>
>> >>Yuzo Fujishima
>> >>NEC Corporation
>> >>
>> >>Alex Yiu wrote:
>> >>
>> >>
>> >>>References:
>>
OF1830994A.7D15ACF8-ON85256FBD.005F9D2B-85256FBD.00603657@us.ibm.com"><OF1830994A.7D15ACF8-ON85256FBD.005F9D2B-85256FBD.00603657@us.ibm.com>
<
>>
OF1830994A.7D15ACF8-ON85256FBD.005F9D2B-85256FBD.00603657@us.ibm.com">mailto:OF1830994A.7D15ACF8-ON85256FBD.005F9D2B-85256FBD.00603657@us.ibm.com
>>
>> > 4230C1D7.2010603@bea.com"><4230C1D7.2010603@bea.com>
4230C1D7.2010603@bea.com"><mailto:4230C1D7.2010603@bea.com>
>> >>>In-Reply-To: 4230C1D7.2010603@bea.com"><4230C1D7.2010603@bea.com>
>> <4230C1D7.2010603@bea.com">mailto:4230C1D7.2010603@bea.com
>> >
>> >>>Content-Type: multipart/alternative;
>> >>> boundary="------------050006030409020902060909"
>> >>>
>> >>>This is a multi-part message in MIME format.
>> >>>--------------050006030409020902060909
>> >>>Content-Type: text/plain; charset=UTF-8;
format=flowed
>> >>>Content-Transfer-Encoding: 7bit
>> >>>
>> >>>
>> >>>Hi, all,
>> >>>
>> >>>As discussed in the F2F, here is the written up
details of a
>> potentially
>>
>> >>>unifying proposal for Issue 92.1. Hopefully, it
would address the
>> need
>> >>>from both sides while retaining simplicity.
>> >>>
>> >>>
>> >>>Thanks!
>> >>>
>> >>>Regards,
>> >>>Alex Yiu
>> >>>
>> >>>
>> >>>
>> >>>===========================================
>> >>>
>> >>>Issue 92.1 - Alternative Proposal to deal with
namespace URI and
>> >>>extension URI
>> >>>
>> >>> <extensions>?
>> >>> <extension namespace="anyURI"
>> >>> extensionURI="anyURI"?
>> >>> mustUnderstand="yes|no"
/>+
>> >>> </extensions>
>> >>>
>> >>>
>> >>>The "namespace" declares which namespace-URI
extension elements and
>> >>>attributes are being used under. It mainly
governs the syntactic
>> part of
>>
>> >>>the extension. It also provides information
whether a BPEL processor
>> >>>MUST understand extension constructs under a
particular namespace.
>> >>>
>> >>>The optional "extensionURI" is used to point to
the semantical
>> >>>definition of extension used under the declared
namespace. The
>> >>>semantical definition MAY include extra
information for BPEL tools /
>> >>>processors to validate extension construct
usage. However, the
>> >>>interpretation of the extensionURI is out of the
scope of this
>> >>>specification.
>> >>>
>> >>>When the optional "extensionURI" attribute is
missing:
>> >>>
>> >>> <extensions>
>> >>> <extension
namespace="http://foo.com" <http://foo.com> />
>> >>> </extensions>
>> >>>
>> >>>the "namespace" URI will be re-used as the
default extension URI.
>> That
>> >>>means the namespace URI is a well-known URI.
And, the semantics of
>> >>>extension is specified by the owner of that
particular namespace.
>> >>>
>> >>>Having two URIs (one for syntactic and one for
semantic)
>> separated but
>> >>>still paired up allows us to:
>> >>>
>> >>> * decouple the syntax and semantics of
extension
>> >>> * reuse the same extension syntax
(identified by the
>> namespace URI)
>> >>> but with different implementations
(identified by the
>> extensionURI)
>> >>>
>> >>>
>> >>>If we have just extensionURI without the
namespace URI, BPEL
>> authors and
>>
>> >>>tools would not know which extension syntax are
governed which
>> >>>extensionURI, especially when multiple
extensions are used within
>> the
>> >>>same process definition. It would make the
process definition much
>> >>>harder to comprehend. Also, declaring an
extension with a
>> namespace URI
>> >>>allows BPEL processors and tools identifies
which extension
>> constructs
>> >>>can be safely ignored by just cross checking
namespaces and their
>> >>>corresponding "mustUnderstand" attribute. BPEL
processors do NOT
>> need to
>>
>> >>>understand the definition pointed by
extensionURI, which is a
>> >>>out-of-scope mechanism.
>> >>>
>> >>>Please note that similar patterns have been used
in other XML-syntax
>> >>>based language before. E.g.:
>> >>>
>> >>> * XSD: <xsd:import namespace="anyURI"
>> schemaLocation="anyURI"? />
>> >>> * JSP tag library extension: taglib-uri and
taglib-location
>> >>> * BPEL: Say, same XQueryX expression (of
same namespace URI)
>> coupled
>> >>> with different XQuery execution context
and data bindings
>> pointed
>> >>> by different expressionLanguage URIs.
>> >>>
>> >>>
>> >>>===========================================
>> >>>
>> >>>--------------050006030409020902060909
>> >>>Content-Type: text/html; charset=UTF-8
>> >>>Content-Transfer-Encoding: 7bit
>> >>>
>> >>><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">
>> >>><html>
>> >>><head>
>> >>> <meta content="text/html;charset=UTF-8"
http-equiv="Content-Type">
>> >>></head>
>> >>><body bgcolor="#ffffff" text="#000000">
>> >>><br>
>> >>>Hi, all, <br>
>> >>><br>
>> >>>As discussed in the F2F, here is the written up
details of a
>> >>>potentially unifying proposal for Issue 92.1.
Hopefully, it would
>> >>>address the need
>> >>>from both sides while retaining
simplicity.<br>
>> >>><br>
>> >>><br>
>> >>>Thanks!<br>
>> >>><br>
>> >>>Regards,<br>
>> >>>Alex Yiu<br>
>> >>><br>
>> >>><br>
>> >>><br>
>>
>>>===========================================<br>
>> >>><br>
>> >>><span style="text-decoration:
underline;">Issue 92.1 - Alternative
>> >>>Proposal to deal with namespace URI and
extension URI</span><br>
>> >>><br>
>> >>><pre> <extensions>?
>> >>> <extension namespace="anyURI"
>> >>> extensionURI="anyURI"?
>> >>> mustUnderstand="yes|no"
/>+
>> >>> </extensions></pre>
>> >>><br>
>> >>>The "namespace" declares which namespace-URI
extension elements and
>> >>>attributes are being used under. It mainly
governs the syntactic
>> part
>> >>>of the extension. It also provides information
whether a BPEL
>> processor
>> >>>MUST understand extension constructs under a
particular
>> namespace. <br>
>> >>><br>
>> >>>The optional "extensionURI" is used to point to
the semantical
>> >>>definition of extension used under the declared
namespace. The
>> >>>semantical definition MAY include extra
information for BPEL tools /
>> >>>processors to validate extension construct
usage. However, the
>> >>>interpretation of the extensionURI is out of the
scope of this
>> >>>specification. <br>
>> >>><br>
>> >>>When the optional "extensionURI" attribute is
missing: <br>
>> >>><pre> <extensions>
>> >>> <extension namespace=<a
class="moz-txt-link-rfc2396E"
>> href="
>> http://foo.com" <http://foo.com>>"http://foo.com"
<http://foo.com></a>
>> />
>> >>> </extensions></pre>
>> >>>the "namespace" URI will be re-used as the
default extension URI.
>> That
>> >>>means the namespace URI is a well-known URI.
And, the semantics of
>> >>>extension is specified by the owner of that
particular namespace.
>> <br>
>> >>><br>
>> >>>Having two URIs (one for syntactic and one for
semantic)
>> separated but
>> >>>still paired up allows us to:<br>
>> >>><ul>
>> >>> <li>decouple the syntax and semantics of
extension</li>
>> >>> <li>reuse the same extension syntax
(identified by the
>> namespace URI)
>> >>>but with different implementations (identified
by the
>> extensionURI) <br>
>> >>> </li>
>> >>></ul>
>> >>><br>
>> >>>If we have just extensionURI without the
namespace URI, BPEL authors
>> >>>and tools would not know which extension syntax
are governed which
>> >>>extensionURI, especially when multiple
extensions are used within
>> the
>> >>>same process definition. It would make the
process definition much
>> >>>harder to comprehend. Also, declaring an
extension with a
>> namespace URI
>> >>>allows BPEL processors and tools identifies
which extension
>> constructs
>> >>>can be safely ignored by just cross checking
namespaces and their
>> >>>corresponding "mustUnderstand" attribute. BPEL
processors do NOT
>> need
>> >>>to understand the definition pointed by
extensionURI, which is a
>> >>>out-of-scope mechanism. <br>
>> >>><br>
>> >>>Please note that similar patterns have been used
in other XML-syntax
>> >>>based language before. E.g.:<br>
>> >>><ul>
>> >>> <li>XSD: <xsd:import
namespace="anyURI"
>> schemaLocation="anyURI"?
>> >>>/> <br>
>> >>> </li>
>> >>> <li>JSP tag library extension:
taglib-uri and taglib-location <br>
>> >>> </li>
>> >>> <li>BPEL:
>> >>>Say, same XQueryX expression (of same namespace
URI) coupled with
>> >>>different XQuery execution context and data
bindings pointed by
>> >>>different expressionLanguage URIs. <br>
>> >>> </li>
>> >>></ul>
>> >>><br>
>>
>>>===========================================<br>
>> >>></body>
>> >>></html>
>> >>>
>> >>>--------------050006030409020902060909--
>> >>>
>> >>>
>>
>>>---------------------------------------------------------------------
>>
>> >>>To unsubscribe, e-mail:
wsbpel-unsubscribe@lists.oasis-open.org <
>> mailto:wsbpel-unsubscribe@lists.oasis-open.org>
>> >>>For additional commands, e-mail:
wsbpel-help@lists.oasis-open.org <
>> mailto:wsbpel-help@lists.oasis-open.org>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>>
>>---------------------------------------------------------------------
>> >>To unsubscribe, e-mail:
wsbpel-unsubscribe@lists.oasis-open.org <
>> mailto:wsbpel-unsubscribe@lists.oasis-open.org>
>> >>For additional commands, e-mail:
wsbpel-help@lists.oasis-open.org <
>> mailto:wsbpel-help@lists.oasis-open.org>
>> >>
>> >>
>> >>
>> >
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail:
wsbpel-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail:
wsbpel-help@lists.oasis-open.org
>>
>>
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail:
wsbpel-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail:
wsbpel-help@lists.oasis-open.org
>>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
|