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

[Rania Khalaf <rkhalaf@watson.ibm.com>]

hi Alex,

I was thinking of

a/b in one NS.

c in another NS.

a is just the base. 'b' is not really a first class citizen so i don't 
see why we are so worried about it. It makes sense to me if we want
only one NS for AP and EP, but if we go with two, one for each of AP and 
EP then we should just address the base properly (a, not b).

Alex Yiu wrote:
> 
> Hi Rania,
> 
> It seems to me that we have started finding more common ground.
> 
> [a] AP with opacity-omission
> [b] AP without opacity-omission
> [c] EP
> 
> I guess all of us would agree that the syntactic difference between [a] 
> and [c] are quite big, while syntactic difference between [b] and [c] 
> are much smaller.
> 
> On the other hand, semantic difference between [a] and [b] may not be 
> that large, while syntactic difference between [a] and [b] are quite 
> large (as large as between [a] and [c])
> 
> I guess all of us would agree with the above analysis and statements.
> 
> 
> There are multiple ways to look at this problem:
> 
>    1. to use two NS to denote the semantic difference: That is my
>       current proposal - use two NSes to mark distinction difference
>       between [a]/[b] and [c], while using "opacityOmissionUsed" to mark
>       the difference between [a] and [b] and tell which validation
>       mechansim people should use [a]: "inject-then-validate" or [b]:
>       "straight-validate"
>    2. to use two NS to denote the syntactic difference: [b] and [c]
>       belongs to the same NS, while [a] has its own NS.
>    3. to use three NS to denote both syntactic and semantic differences:
>       i.e. [a],[b],[c] all have its own NS.
> 
> Last and least (yes the least), one gigantic NS cover all [a],[b],[c] 
> cases. That is the worst situation IMHO. It would present a totally 
> confusing picture to users about what syntactic and semantic distinction 
> between AP and EP (I tend to believe our friends at MSFT would not like 
> that.)
> 
> Among the first 3 options, I still most prefer #1 (next is #3). There 
> are two very overloaded attributes in A.P. - the "profile" attribute and 
> the "opacityOmissionUsed" attribute (assuming we go for it). The 
> "profile" attribute can totally shift how an A.P. implementation 
> interprete an. A.P. Hence, it is a super important attribute that our 
> schema grammar MUST make it REQUIRED. Otherwise, I can forsee a 
> situation where people would generate A.P. without that profile 
> attribute. An A.P. implementation cannot guess what profile the A.P. is 
> using.
> 
> That's why I prefer #1 well above #2 and the one-NS "solution".
> 
> 
> Rania ... your further thoughts?
> Thanks!
> 
> 
> 
> Regards,
> Alex Yiu
> 
> 
> 
> Rania Khalaf wrote:
> 
>> Back to the two namespace issue:
>>
>> 1) If we want a schema for AP that also includes the idea of 
>> omission-shortcut, then the difference between AP and EP is quite big 
>> and two NSs probably make a lot more sense.
>>
>> 2) If we only validate AP after opaque-omission is removed (ie: after 
>> plugging in opaque tokens), then the difference is very small and so 
>> we probably don't need two NSs.
>>
>> I'm  lost at the third position, which is taken in the proposal:
>>
>> Only validate after plugging in opaque, AND have two NSs.
>>
>> If we're going to go through the trouble of two NSs, then we might as 
>> well make the schema of the base properly in line with the resolution 
>> of 82, and allow validation without the extra step of replacing 
>> omitted things with opaque='yes'.
>>
>