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

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

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