Re: [ebxml-bp] RE: Dubray 8/19/2004: isIntelligibleCheckRequired

["Monica J. Martin" <Monica.Martin@Sun.COM>]

>
>
>Serm: May I ask a novice question. Why does BPSS need this attribute?
>  
>
>Can't it just be specified in the signal that the message is not readable.
>
>>mm2: I'll defer to JJ or Dale (everyone) to add to this response. I'd
>>say that this is a function outside of the Receipt Acknowledgment. Here
>>is the refined text Serm proposed.  Are you suggesting that a flag be
>>provided in the Receipt Acknowledgment? Thanks.
>>    
>>
><serm>I think it can be subsumed by the Receipt Ack if the spec necessitates
>so. I guess one of the questions I am asking is why do we need the
>flexibility to turn that on and off, what are the real use cases? I also
>think that it is ultimately the application/middleware that decides whether
>the message is legible/understandable. Hence it is also a function of NOF.
>The XSD validation does not mean that it will be legible by the app/mw and
>the document may be EDI.
></serm>
>  
>
There seem to be at least two stages of validation, Serm - that of the 
syntax only and then of the content based on business rules.  Doesn't 
your example address the latter? In the recent past, there was much 
discussion about how much validation should be accommodated, with some 
suggestions more heavyweight than others.  To start to discuss your 
questions: (1)

I guess one of the questions I am asking is why do we need the
flexibility to turn that on and off, what are the real use cases? 

mm1: If the document is EDI, there would not be any XSD validation of the business document. But does preclude that there could still be a document envelope syntactic check? NOF was discussed at length at the editors' F2F (notes located at: http://www.oasis-open.org/archives/ebxml-bp/200407/msg00035.html). At that time, we also discussed if any content validation could be added to the Receipt Acknowledgment (isIntelligibleCheckRequired was discussed as possible not the other QoS attributes). So, I would suggest that you attend the meeting 13 Sept [1]

On the NOF, Hima Mukkamala, the original signals author, has been working with the team on general exception signals, NOF and the current signal structures.  He has been traveling so we won't be able to have a special session until later this month.  As John Yunker indicated (in his thoughts of the technical and business aspects during the editors' session), that NOF is when one or other party realizes they can not proceed, because a necessary part of the business protocol is missing. As John (and the editors' team agreed), a NOF could occur when a timeout happens for failure <<to receive>> a requesting or responding business document (differentiate from legible check above). In the case when there is reliable messaging which shows the receipt of request or response, the party should not be capable of sending NOF. If for example, a response is sent then a NOF by a responder. That is an anomaly and we would defer to the business agreement in that case. [2]

Thanks.

[1] We have a ASAP presentation then but can talk about this item for you towards the end of the call. If this doesn't work with your schedule, please let me know your preferences offline.
[2] More detail is in the notes referenced above.