RE: [ebxml-msg] First editorial issues on 1.09

OK, Done.  

 

- David

  
-----Original Message-----
From: Doug Bunting 
  [mailto:]
Sent: Tuesday, November 20, 2001 12:58 
  AM
To: ebXML Msg
Subject: Re: [ebxml-msg] First editorial 
  issues on 1.09

  
I can understand that -- 2.1 is a fine destination if the 
  introduction at the top of 2 still makes sense or if it's updated to make it 
  make sense.

  
 

  
thanx,

  
    doug

  
 

  
----- Original Message ----- 
  
From: David 
  Fischer 

  
To: Doug Bunting ; ebXML Msg 

  
Sent: Monday, November 19, 2001 6:37 PM

  
Subject: RE: [ebxml-msg] First editorial issues on 
1.09

  

  
No, I don't agree to changing the section numbers of every section in 
  the document.  Its not worth that -- too much confusion for minimal 
  gain.

  
 

  
- David.

  
    
-----Original Message-----
From: Doug Bunting 
    [mailto:]
Sent: Monday, November 19, 2001 3:52 
    PM
To: David Fischer; ebXML Msg
Subject: Re: [ebxml-msg] 
    First editorial issues on 1.09

    
And more comments in line.  Hopefully, 
    this will show up for people not using HTML readers.  I'll bracket in 
    [].

    
 

    
----- Original Message ----- 
    
From: David 
    Fischer 

    
To: Doug Bunting ; ebXML Msg 

    
Sent: Monday, 19 November 2001 13:28

    
Subject: RE: [ebxml-msg] First editorial issues on 
    1.09

    

    
<<comments in-line>>

    
      
-----Original Message-----
From: Doug Bunting 
      [mailto:]
Sent: Monday, November 19, 2001 2:56 
      PM
To: ebXML Msg
Subject: [ebxml-msg] First editorial 
      issues on 1.09

      
David,

      
 

      
In a quick read of 1.09, I've noticed a few things we 
      could get started on resolving.  Some are rather picky 
      (sorry).

      
        
The text in section 1.3 has not moved into Part 
        1.  This is not introductory material but the first plank in the 
        standard we're defining.  During the meeting last week, we 
        agreed (after little discussion) to move this material later in the 
        document.  This should primarily be a renumbering of the section to 
        a new section 2 just after the Part 1. title.  

    
 << Yes, you and I discussed 
    this and I agreed with you.  I didn't remember discussing this 
    with the group.  Anyone have any objections to moving 1.3 
    to 2.1?   >> 

    
[I 
    was suggesting moving 1.3 to 2 and 2 to 3 (and so on) because 1.3 concerns 
    itself with MIME packaging and the introductory material in 2 starts with 
    the contents of the SOAP message document.]

    
      
        
The new text does not resolve issues Arvola raised in 
        the week prior to our meeting with regards to the SOAP Fault element and 
        revolving which message was in error.  I suggested (in http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00211.html)

      
        
          
"Note: A SOAP Fault element on its own may not 
          provide the requesting MSH with the context necessary to identify the 
          message in error.  An MSH returning a SOAP Fault should include 
          ebXML MessageHeader and ErrorList SOAP extensions in the same SOAP 
          message.  This would be especially useful when the error is 
          returned asynchronously."

        
but don't see it in the document. 

    
<< I thought we decided against this since 
    the SOAP Fault may be a situation where the MessageHeader itself is corrupt 
    or unreadable or undefined or violates the schema 
    etc.?? >>

    
[That's exactly why this is a note and only a 
    (lowercase) should.]

    
      
        
Please search the document for the word "that".  
        Almost all instances (especially in the phrase "that is" which can be 
        globally deleted with allowance for commas) can be removed. 

    
<<Yes, grammatically, you 
    are correct.  I have not been willing to make 
    such global changes without direction.  Anyone object? 
    >>  

    
      
        
Most references to top level sections should refer to a 
        specific sub-section.  For example, references to section 4 occur 
        when the issue is security, errors, some specific element, et 
        cetera.  

    
 <<Please be 
    specific.>>

    
[I 
    don't remember how (or if) Word handles searches for values output by a 
    field.  If it works, you should be able to find "section 4" in the 
    document.  A quick check showed me that finding "section ^#^w" catches 
    a few cases.  For example, lines 1804, 1818 and 1912 should 
    reference 4.1 or 4.1.1.  Finding "section ^#)" catches a few other 
    cases such as line 239 and many references to section 4 when error handling 
    is meant.  I didn't search for "section ^#.^w" but that'll catch a few 
    cases too.]

    
      
        
It's up to you whether the document uses a comma prior 
        to "and" and "or" but the current document is not consistent in this 
        respect.  It doesn't appear commas are added for "more complex" 
        sentences for example.  

    
<<Again, you are 
    correct.>> 

    
      
        
A bit more on errors should be primarily 
        editorial: The current text is inconsistent with respect to what error 
        should occur under different situations.  For example, a conflict 
        with the CPA is handled using an Inconsistent Error but the description 
        of Inconsistent doesn't cover anything except elements and attributes in 
        the document at hand.  Specific inconsistencies (such as 
        duplicateElimination in 7.4.1) are sometimes handled using a 
        NotSupported error. 

    
<<This is not editorial but I will go ahead 
    and change 7.4.1.  This is a problem any time we add a new 
    flag/feature.  It is appropriate to use NotSupported until CPA adds it 
    to their spec at which time we have to change to Inconsistent.  This 
    causes a continuous cascading problem.  I like your solution to allow 
    either error.  Where/how shall we say 
    this?>> 

    
[I 
    made a suggestion below.  We should probably discuss this more on the 
    list before choosing the final wording.  My suggestion is just the gist 
    of a potential addition.]

    
      
Perhaps this last point isn't an editorial issue?  
      We're requiring a specific and inconsistent processing order at the 
      receiving MSH.  Most issues around features supported by the MSH are 
      captured in the CPA.  Whenever we see "NotSupported" meaning a 
      feature was requested the recipient couldn't handle, an "Inconsistent" 
      error would be just as appropriate.  At the moment, the order is 1) 
      check support for duplicateElimination and a few other things 2) check CPA 
      3) recheck CPA against requested features (even if they're entirely 
      unsupported).

      
 

      
It's up to an enterprise how free they want to be with 
      their supported feature list.  A worried company with a public ebXML 
      service might report everything as inconsistent (with a default CPA 
      they've published to the world).  We shouldn't preclude that mode of 
      operation.  I'd recommend allowing either error in all 
      situations.  The easiest way to do that would be to use 
      "Inconsistent" throughout the document but include explanatory material in 
      4.2 stating that many inconsistencies with a CPA ("as described elsewhere 
      in this document") may also result in a NotSupported error.

      
 

      
thanx,

      
    doug