OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-spec-edit message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsbpel] Issue 247 - Applied

I have added the new Static Analysis appendix B to the spec. in sourceforge version 1.162.

As mentioned earlier, This was added as appendix B. I have fixed the appendix numbers for subsequent sections and I have fixed the TOC. 
 - I have also added a tag (eg: [SA00001]) for each of the static analysis item in the main body of the text. The tag is bookmarked and is referenced from the Appendix by (a) clicking on the SA code (eg: SA00001 ) or (b) the section reference eg: Section 3 ). 
 - I have also added a bookmark in the appendix for each SA code description. The tag in the main body references this bookmark and so one can click on the main body tag to reach appendix description. This will allow rapid switching from the main body to appendix and vice versa to help us keep the text in sync.

While adding appendix B, I encountered following problems which may require further action:
  (1) SA00047 is no longer applicable ( section 10.1, description: The name of a named activity MUST be unique among all named activities present within the same immediately enclosing scope. ). I have removed this SA code and renumbered codes. We now have SA 91 codes. 
  (2) Cannot find description for these two codes in main body.  
      SA00053 : section 10.3.1
         For all <fromPart> elements the part attribute MUST reference a valid message part in the WSDL message for the operation.
     SA00054 : section 10.3.1
         For all <toPart> elements the part attribute MUST reference a valid message part in the WSDL message for the operation.

I believe these are valid constraints but I cannot find the text in the main body that explicitly calls this out. Maybe someone can help me locate the text else we can open an issue to add text.
  (3) There appears to be no SA code in the appendix for the following Static analysis text in the main body. We can open an action item/issue to address this: 
section 12.4.3 around line 4956 "Within a scope, the name of all named immediately enclosed scopes MUST be unique. This requirement MUST be statically enforced."

Releasing pen back to editors group.  


Vinkesh O.  Mehta 
Manager,  Deloitte Consulting LLP
Mobile: + 1 512 750 2006

-----Original Message-----
From: Mehta, Vinkesh (US - Austin) 
Sent: Wednesday, June 21, 2006 12:42 PM
To: Thomas Schulze; Mark Ford
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 247

I have uploaded version 26 of the Static Analysis Appendix document. 

As part of editing when I get the pen I would like to do the following.
   (a) Add this as Appendix B in the spec. ( adjust Appendix numbers for current B,C,...)
   (b) Add a reference from Appendix B to relevant text in the main body for each item
   (c) Add the SA reference number in the main body adjacent to the relevant text ( eg: [SA000xx] )
   (d) Verify that the current text for each of the items in the appendix is correct(based upon text in the main body). Else fix it.

Since there 92 items I would like to do (b),(c) and (d) in a single pass of the document. I can only do this after I have the editors pen and complete step (a). 

I would like to propose that we accept version 26 of this document as part of issue 247 resolution in the next Conf. call. Then I can proceed with the editing steps.


Vinkesh O.  Mehta 
Manager,  Deloitte Consulting LLP
Mobile: + 1 512 750 2006

-----Original Message-----
From: Thomas Schulze [mailto:ThomasSchulze@de.ibm.com] 
Sent: Monday, June 05, 2006 4:34 AM
To: Mark Ford
Cc: Mehta, Vinkesh (US - Austin); wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue 247

Hi Mark,

1) We have currently different approaches. Appendix A-G does not say
anything (in the heading) while H says it is normative and I and J say they
are not normative. I think this must be discussed in a call and the result
should be applied to all appendixes. I would prefer that each appendix says
in the heading if it is normative or not.

2) I've discussed this shortly with Vinky and I think we agreed that this
chapter applies to both kinds of processes, executable and abstract. Rules
which apply to only one of them should be marked in the description
accordingly. That are currently SA15 (see Issue 292), SA32 and SA88.
There are some other rules which might need to be adapted like SA15. IMO
that are: SA59, SA62 and SA64. Of course, the spec text from where these
rules come might be adapted, too.
IMO all other rules apply to both kinds.

3) I have not seen any objection to that yet, so I've removed these
statements where possible.

Other changes:
I've dropped SA74, because it's a duplicate of SA73.

Best regards/Mit freundlichen Gren,

       Thomas Schulze

             "Mark Ford"                                                   
             -endpoints.com>                                            To 
                                       Thomas Schulze/Germany/IBM@IBMDE    
             31.05.2006 19:56                                           cc 
                                       "'Mehta, Vinkesh \(US - Austin\)'"  
                                       [wsbpel] Issue 247                  

I'd like to propose that we adopt Vinky's latest submission as the proposed
appendix but I think there are a couple of small things to iron out first.

1) The sub heading of the appendix says that it's non-normative but the 2nd
paragraph hints that the section is normative although subordinate to the
main document in case of discrepancy. Do we have similar (Non-Normative)
indicators on other appendices?

2) As Rania pointed out in the call today, these requirements should apply
to executable processes. I was initially ok with adding something to the
introductory paragraph making this explicit but there are some rules that
apply to both and some rules that apply to only executable. For example,
can an abstract process use WSDL with overloaded operations? Should we add
another column onto the list indicating if the rule applies to an abstract
process, executable process, or both? I found one rule that applies to only
abstract processes SA00088 but this rule refers to Section 13.3.4 which
doesn't exist anymore so perhaps it's no longer valid.

3) Some of the rules contain the text "This requirement MUST be statically
enforced." This is likely a result of this statement occuring in the
original section that the rule was extracted from. It seems redundant to
state that the rule MUST be statically enforced since if it didn't need to
be then why is it in the appendix? This statement should either be on all
of the rules or none of the rules. My preference is for removing it. 

This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law.  If you are not the intended recipient, you should delete this message. 

Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1]

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]