OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Fw: [wsbpel] Issue - 92 - Proposal for vote


Hi Dieter et. al,

I have a couple of comments:

1. First a minor one:   The "<extension namespace="anyURI" ..." schema permits literally any namespace.
   I think we need to make it clear that extensions must not be defined in the bpws reserved namespace  (http://schemas.xmlsoap.org/ws/2004/03/business-process).
  
2. Making "all" extensions in a namespace  required/optional as an "all or nothing" via @mustUnderstand at the namespace level is too restrictive and undesirable IMO.  Even though I like declaring extensions (namespaces) at the top level.

I think as a practical case, one would typically want to make "some" of extensions required and some of them optional. Requiring one to invent a new namespace for each extension is undesirable as well.

Given BPEL has a open-content extensibility model (as defined by extending tExtensibleElements), IMHO we should try and preserve as much of that as possible.

This problem exists in other description languages like WSDL, that define a wsdl:required attribute, that can be placed on a specific extension with a value of true or false. Having a wsdl:required  with a value of "true" unambiguously identifies that the extension is required and MUST be understood. If the attribute value is "false" or not present then the extension is an optional one.   I would like to propose that we explore a similar option via the "@bpel:rquired".

Thanks.

Prasad

------- Original Message --------
Subject: Fw: [wsbpel] Issue - 92 - Proposal for vote
Date: Fri, 21 Jan 2005 07:54:16 -0800
From: Dieter Koenig1 <dieterkoenig@de.ibm.com>
To: wsbpeltc <wsbpel@lists.oasis-open.org>

Updates:
   (a) changed true|false to yes|no
   (b) clarified that ALL extensions must be declared
Kind Regards
DK

---------------------------------
Proposed resolution for Issue 92:
A new subelement of the process root element is used to declare extensions
used in the process and specify whether they must be understood by the
BPEL runtime.

Rationale:
This declaration provides information needed by the process deployer in
order to decide whether a BPEL process containing language extensibility
elements can be executed by the runtime.

Add text to section 6.2. The Structure of a Business Process

   <process ...>
      ...
      <extensions>?
         <extension namespace="anyURI" mustUnderstand="yes|no"/>+
      </extensions>
      ...
   </process>

Add text to section 6.3. Language Extensibility

   The "extensions" subelement of the process is used to declare the
   namespaces of ALL BPEL extension attributes/elements and indicate
   whether they carry runtime semantics that must be understood by
   the BPEL runtime. If this criteria is not met, then the BPEL
   implementation MUST reject the process.

   If the runtime does not support one or more of the extensions with
   mustUnderstand="true", then the process MUST NOT be deployed.
   Extensions declared with mustUnderstand="false" MAY be ignored by the
   runtime.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]