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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

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

I'd agree except that the current document describes sending an ErrorList with highestSeverity="Error" together with a SOAP Fault already (see section 4.2).  The wording suggested below doesn't change the contents of a SOAP Fault element or when it might be generated, just recommends additional information (other SOAP extensions) in the overall SOAP message.
I wasn't aware SOAP errors must be returned the synchronous channel in the HTTP binding.  If that's the case, this will be less of an issue.  Not sure it does any harm...
----- Original Message -----
Sent: Monday, 19 November 2001 13:47
Subject: RE: [ebxml-msg] First editorial issues on 1.09

I don't think there should be any changes to what a SOAPFault contains. If the received message was parsed so that the receiving MSH can get the MessageHeader, then it should use "ErrorList" to send back an error. SOAPFault should be used for messages that can't be understood at all from a MSH. IMO this means a async message can get a SOAPFault returned in the same connection. If the sending MSH is not listening for returned Faults than it gets no error message.
-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Monday, November 19, 2001 1:28 PM
To: Doug Bunting; ebXML Msg
Subject: RE: [ebxml-msg] First editorial issues on 1.09

<<comments in-line>>
-----Original Message-----
From: Doug Bunting [mailto:dougb62@yahoo.com]
Sent: Monday, November 19, 2001 2:56 PM
To: ebXML Msg
Subject: [ebxml-msg] First editorial issues on 1.09

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?   >> 
"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.?? >>
  • 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.>>
  • 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?>> 
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.

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

Powered by eList eXpress LLC