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

["Yaron Y. Goland" <ygoland@bea.com>]

BTW, using colors with me doesn't work well because, for security 
reasons, I only read my e-mail in plain text form. But in this case 
everything was fine because your text was interspersed amongst the 
commented text.

Requiring that a namespace can only be associated with a single 
extension is exactly the problem. It effectively prohibits two 
extensions from re-using elements from the same namespace. That is 
exactly the kind of extension hostile design we should be trying to 
avoid. There is no reason why two different extensions can't draw from 
the same namespace.

I think the fundamental problem with the proposal is that it makes 
exactly the mistake I drew out in my blog article, it assumes that 
people who define namespaces will do so in absolutely perfect re-usable 
packages. No one has ever managed to do that and there is no reason to 
believe anyone ever will. We shouldn't block extensions from being able 
to re-use namespaces.

		Yaron

Alex Yiu wrote:
> 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
> 
>