Re: [wsbpel] Issue 92 - 92.1 - a newer and potentially unifying proposal

[Alex Yiu <alex.yiu@oracle.com>]

Hi, Yaron,

You are reading my proposal not-so-correctly.
See my quick comment and clarification inline in GREEN:

Yaron Y. Goland wrote:

You identify two goals for adding in namespace:

> (a) partition different extensions (from Dieter's proposal) (b) to lookup the
> owner / definer of extension.

Regarding (a): As I explain in the Blog article there are good reasons for wanting multiple namespaces in a single extension. Dieter's proposal makes such behavior illegal. Your proposal makes such behavior effectively illegal because you explicitly require people to draw conclusions about the contents of an extension from a namespace attribute and since only a single namespace can be specified it is impossible to use elements from two namespaces.

My proposal allows one extension-URI defines extension multiple namespace URIs.
However, I DO want to disallow that one namespace URI is defined by multiple extension-URIs.
Because, I want to make sure there is ONE owner per namespace.

Regarding (b): As I pointed out in the letter to Danny the XML namespace proposal explicitly states that there is no requirement that namespaces be dereferencable and yet your proposal is based on the assumption that such de-referencing is possible.

NEITHER namespace-URI NOR extensionURI need to be de-referenceable. The BPEL implementation just needs to recognize the extensionURI. Similar situation in your proposal. Just look at what happened in the JSP and XSD world. URI used in XSD:schema-location and JSP:taglib-location do NOT need to be de-referenencable. Those URI just needs to be known by the implementation. People misunderstood that they must be de-referenceable, because de-referenceable is the simplest usecase that people learn first.

To achieve the goals you laid out I believe you need to adopt a variant of Yuzo's proposal and include optional namespace declarations and allow for multiple such declarations to be used. But I really think that is over engineering. At this point just putting in an extensionURI is sufficient.

Hmm ... you lost me here ... :-) ... I would say I would not go to the direction of Yuzo's proposal in general.

> 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 />.

If the implementation understand http://foo2impl.com then clearly it must already know which elements are part of http://foo2impl.com and therefore already knows if <bar:ExtElm3> is part of http://foo2impl.com. If ExtElm3 is a part of http://foo2impl.com then there is no issue, the engine knows what to do. If ExtElm3 is not part of foo2impl.com then there is also no issue since the engine knows to ignore it. Hence there is no issue.

"If ExtElm3 is not part of foo2impl.com then there is also no issue since the engine knows to ignore it." ...
Why can the engine safely ignore it? The "must-understand" information in Dieter's proposal is "moved" to the semantics represented by the extensionURI in your proposal. "bar:ExtElem3" may be defined as MUST-understand by "http://bar2impl.com". It's just a particular implementation don't recognize it.

Bascially, my proposal is to make your proposal less opaque by  exposing relation between namespace-URI and MUST-understand (which is factored out of Dieter's proposal).
 


Thanks!


Regards,
Alex Yiu