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

["Boonserm \(Serm\) Kulvatunyou" <serm@nist.gov>]

Thanks Monica.

My ultimate opinion is as follows. Mere XSD validation could mean little and
also the fact that the message may be EDI, graphics, etc makes XSD
validation less meaningful. Semantically valid message, as you said below,
could be heavy and may permeate several levels back in applicaitons. So
there are a lot of variations associated with legibility.  Consequently, I
think specifying ways to precisely indicate illegibility exceptions in
signals is more worthwhile of an effort (you might have already done so)
than defining this parameter. Again, this may be a naive view because I
still do not get a feel why this parameter was invented in BPSS at the first
place.

Thanks again,
Serm

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "Boonserm (Serm) Kulvatunyou" <serm@nist.gov>
Cc: "Jean-Jacques Dubray" <jeanjadu@Attachmate.com>;
<sallystamand@yahoo.com>; <ebxml-bp@lists.oasis-open.org>
Sent: Monday, September 06, 2004 7:28 PM
Subject: Re: [ebxml-bp] RE: Dubray 8/19/2004: isIntelligibleCheckRequired


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