Re: [wsbpel] Issue 82.1 - proposal to vote (directional vote)

[Monica J Martin <Monica.Martin@Sun.COM>]

As Ron indicated in his previous email, there are other TCs (in OASIS no 
less) that have faced this challenge and concluded that a single 
namespace was impractical for several technical or functional reasons. 
This decision was irrespective of any decision on redefine. At least one 
TC has much experience on the model that Alex Yiu has proposed. Although 
a different venue, their experience has provided some indicators of 
practices to avoid. 

As we found in negotiating the BPEL usage profiles for abstract 
processes, there are compelling differences if even in focus between 
abstract and executable processes. We also may well consider how this 
encourages the effective adoption and use of abstract and executable 
processes - also a compelling reason underlying Ron, Alex and 
Alexandre's responses. We want adopters to understand the relevant use 
of abstract and executable processes, and their relationship.

Thanks.

> yiu: Hi Rania,
> You asked whether we have compelling reason to have two NS.
>
> Maybe, I could pose some other questions back:
>
>     * Why do we want to have XMLNS in first place?
>       I would say: to partition namespace for XML elements and
>       attributes with different structural definition and semantic
>       meaning by sharing the same local-name/ncname.
>     * Why do we want to use XML as the source code format for BPEL?
>       I would say: we can leverage XML grammar facilities (e.g. xml
>       schema or relax ng or schematron) to perform big chunks of
>       syntax validation.
>
>     * Why do we want to have a different NS for BPEL 2.0?
>       Why don't we reusing the same NS for both BPEL 1.1 and 2.0 by
>       adding a process-level "version" attribute? 
>       (i.e. version="1.1" vs version="2.0") 
>
>           o The version attribute approach is actually sometimes
>             practiced in an ancient part of XML world which pre-dates
>             XMLNS and does not leverage any grammar structure (e.g.
>             schema and DTD)
>           o Obliviously, BPEL XML source code lives in the XML world
>             where XMLNS and XML Grammar matter.
>           o I also would add the difference between Abstract BPEL
>             (with opacity omission) and Exec BPEL is MUCH larger than
>             the difference between BPEL 1.1 and BPEL 2.0.
>           o Merging Abs and Exec into one NS is a big violation of
>             design and usage principle of XMLNS and xml grammar. The
>             violation is bigger than merging BPEL 1.1 and BPEL 2.0
>             into one XMLNS (at least in my own book).
>           o I would suggest people to consult their in house xml
>             experts to see whether mix-and-merge two different XML
>             animals into one NS is a bad idea. And, it would surprise
>             me that if one XML expert wants to enforce XMLNS usage
>             principle more strictly, they would even further partition
>             into 3 NSes.
>
>
> Whether to use <xsd:redefine> or not to describe two NS is that is the 
> MEANS issue. We _cannot put the MEANS before the ENDS_. Otherwise, it 
> would be similar to _putting the cart in front of the horse_.  At the 
> same time, we are still open to other ideas alternative to 
> <xsd:redefine>. During my XSD editing for BPEL TC, I have been using 3 
> kinds of tools to verify that our XSD can be understood and 
> well-supported by a varieties of env. (a) Xerces (b) W3C's XSV (c) 
> Oracle XDK.
>
> For the cut-and-paste case, it depends on whether you are using VI or 
> some XML-aware editor. If one use an XML-aware editor, the 
> copy-and-paste would copy the NS Declaration also. (Similar to those 
> Java-aware IDE tool, the copy and paste Java fragment will copy its 
> related Java's import as well).
>
>
> Regards,
> Alex Yiu
>
>
> Rania Khalaf wrote:
>
>> Hi Alex,
>>
>> I think going with the second point, that it doesn't make much sense 
>> to split the namespaces. Especially, as Yuzo had mentioned, that most 
>> tools don't support advanced XSD features and as Danny also said if 
>> there's no really compelling reason to manage several XSDs and 
>> changes we should try to keep it simple.
>>
>> As for cut and paste, the ns decl is up top anyway, so in many cases 
>> a cut and paste is just that and people will be able to copy bits 
>> with opaque in them.
>>
>> my .02.
>> rania
>>
>> Alex Yiu wrote:
>>
>>>
>>> Hi all,
>>>
>>> I think we should still have distinct namespaces between Abstract 
>>> and Executable BPEL, after most of 82.* got resolved. Major reasons 
>>> are:
>>>
>>>     *  There are _significant amount of syntax differences_ between an
>>>       Abstract Process with _opacityOmissionUsed="yes"_ and Exec
>>>       Process. (I am talking about the Abstract base, not AP11 profile;
>>>       essentially all compulsory element and attributes becomes 
>>> optional.).
>>>     * On the other hand, there are _moderate amount of syntax
>>>       differences_ between an between an Abstract Process with
>>>       _opacityOmissionUsed="no"_ and Exec Process. (I already capture
>>>       those differences in my previous email).
>>>     * I am worrying people uses _copy-and-paste and mix-and-match
>>>       between Abstract and Executable BPEL_. (e.g. copying a 
>>> fragment of
>>>       empty <scope> from an Abstract BPEL into Exec BPEL). If we use 
>>> the
>>>       same namespace for both kinds of BPEL, it would be difficult for
>>>       us to tell that users are doing this kind of mistakes. If we use
>>>       different namespace, if people use an XML-aware tool to do such a
>>>       copy-and-paste, we can detect that kind of mistakes more easily.
>>>     * With both AP11 and Template profiles, I tend to forseee people
>>>       would create the Executable Process based on Abstract Process 
>>> with
>>>       sometool help, given with constraints specified in the profile.
>>>       Even when people want to create an Executable BPEL based on
>>>       Abstract BPEL with just emacs/notepad. People just need to 
>>> following:
>>>          1. copy the BPEL file
>>>          2. _make one-line of change_: changing XMLNS declaration from
>>>             Abstract to Exec BPEL.
>>>          3. add extra BPEL constructs for Execution Completion.
>>>
>>>             Having two distinct namespace will allow us to _validate 
>>> the
>>>             Exec BPEL code during step (3) by using XSD_. Hence, having
>>>             multiple NS gives us more tool to do BPEL validation, while
>>>             collapsing Abstract and Executable do not yield any user
>>>             benefits.
>>>
>>>
>>> Thanks!
>>>
>>>
>>> Regards,
>>> Alex Yiu
>>>
>>>
>>>
>>> Peter Furniss wrote:
>>>
>>>> I thought we said (or maybe it was just me) that we should revisit 24
>>>> once we had sorted out (in 82.*) just how much difference there was
>>>> between syntax e and syntax a. When issue 24 was resolved we were
>>>> anticipating a quite different scale of differences.  I had to drop 
>>>> out
>>>> of active involvement in 82 soon after that, I do think we should
>>>> consider rescinding 24 (sorry Diane)
>>>>
>>>> Peter
>>>>
>>>>  
>>>>
>>>>> -----Original Message-----
>>>>> From: Rania Khalaf [mailto:rkhalaf@watson.ibm.com] Sent: 22 
>>>>> November 2005 16:28
>>>>> To: Alex Yiu
>>>>> Cc: wsbpeltc; Rania Khalaf; Danny van der Rijn; Ron Ten-Hove; 
>>>>> 'Monica J. Martin'
>>>>> Subject: Re: [wsbpel] Issue 82.1 - proposal to vote (directional 
>>>>> vote)
>>>>>
>>>>>
>>>>> Hi guys,
>>>>>
>>>>> If we agree about the schema of abstract will only add the opaque 
>>>>> tokens then I don't see any motivation any more for 24's resolution .
>>>>>
>>>>> Is it really worth all the pain of xsd:redefine and managing three 
>>>>> schemas instead of just saying in the text that you can only use 
>>>>> abstract tokens in AP ?
>>>>>
>>>>> regards,
>>>>> Rania
>>>>>
>>>>>   
>>>>
>>>
>>
>>
>