RE: Wire Trace approach to MEP/Binding descriptions.

Hi Chris,

Thank you... the notational approach is a little amateur process algebra on
my part and is very close to either CCS or CSP. I can get some help locally
on making it properly one or the other. The point about an algebra being
that it has a set of rules for its manipulation that preserve meaning.

I don't think I would be in favour wholly inventing a new notation for
this... I would much rather that we use a common existing PA notation,
reference the appropriate work (spec/text book) and if necessary provide a
brief and informal note on how to read it.

Another point of the presentation was to abstract away from < and the low
level structure and encoding of the message itself, whereas i have the sense
of you trying to pull those things back in... what about the binding
specific wrappers that preceed/follow the infoset serialisation... it don't
think we want to go there.

The presentation avoids 'in'ness and 'out'ness which you introduce:

> srrmessage := out SOAPRequest in ( SOAPResponse | SOAPFault | null )

This is perhaps a subtlety, but imagine monitoring the 'wire' close to the
requester and/or close to the responder. PA expressions describe what
happens on the wire irrespective of whether you are thinking of requester or
responder. Your expression, quoted above, is written from the POV of a
requester, not from the POV of the 'wire' or a 'responder'.

A further subtlety worth noting is that monitoring close to the requester or
responder may reveal differing experiences of the interaction - monitoring
close to the responder its is possible for message exchange to appear to
have been successful, whereas close to the requester it may appear to have
failed.

One last point is that the PA/wire-trace based presentation turns each
message into a start (or fail) and an end (or fail) event and makes the
potential for temporal overlaps explicit (in response to Eamon's observation
[1]). In contrast, the expression above, turns request and response messages
back into discrete units which make it difficult to expose the possibilities
for such overlap - as Eamon points out a flaw of the current FSM design (the
FSM presentation could be fixed to treat both the start an end each message
with a graphical and tabular presentation that refelected the state machine
implicit in the PA expression - ie we could get something that was
absolutely equivalent with our current diagram/tabular style - the main
advantages of this approach are terseness, and formality).

Feel's like I'm pushing back strongly... I don't mean to... personally I
think it would be a lot more work to 'invent' a notation rather than
'borrow' one. That said, I would agree that BNF could/can be use to capture
this kind of behaviour too and that a BNF style of notation could be
adopted, personnally I am less familar with it's use for such purposes. If
we were to go that way, then I think we would still have to abstract away
from the particular encodings of infosets (when describing MEPs) and focus
on tokens that represent the start, end and failure of messages from the
point of view of monitoring the wire.

regards and thanks,

Stuart
[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0038.html


> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: 10 January 2002 23:16
> To: xml-dist-app@w3.org
> Subject: Re: Wire Trace approach to MEP/Binding descriptions.
> 
> 
> +1
> 
> I like the direction that this is taking.
> I find the notation to be succinct, if not a little
> confusing, but that can be worked...
> 
> Specifically, I find the dot notation to be
> a little akward. It might be useful instead to
> express the concept of "followed by" such that
> it also included the direction (although, this
> would bias things to one perspective I suppose).
> 
> It might also be interesting to explore use of BNF
> or a derivative for the notation so that it was
> more familiar to the reader. This would also provide
> for the ability to describe with more specificity
> any specific constraints on the messages such as
> required headers, faults, etc.
> 
> e.g.
> 
> srrmessage := out SOAPRequest in ( SOAPResponse | SOAPFault | null )
> SOAPRequest := SOAPEnvelope SOAPHeader
> 	SOAPRequestBody SOAPEnvelopeTerminator
> SOAPResponse := SOAPEnvelope SOAPHeader
> 	SOAPRequestBody SOAPEnvelopeTerminator
> SOAPFault := SOAPEnvelope SOAPHeader
> 	SOAPFaultBody SOAPEnvelopeTerminator
> 
> SOAPRequestBody := "<" [NSQ ":"] "Body" { attr } ">" [CRLF]
> 	request SOAPBodyTerminator
> SOAPResponseBody := "<" [NSQ ":"] "Body" { attr } ">" [CRLF]
> 	response SOAPBodyTerminator
> SOAPFaultBody := "<" [NSQ ":"] "Body" { attr } ">" [CRLF]
> 	SOAPFault SOAPBodyTerminator
> SOAPFault := "<fault>" [CRLF]
> SOAPEnvelopeTerminator := "</" [NSQ ":"] "Envelope>"
> SOAPHeaderTerminator := "</" [NSQ ":"] "Header>"
> SOAPBodyTerminator := "</" [NSQ ":"] "Body>"
> attr := NSDecl | STRING "=" STRING
> NSDecl := "xmlns" [":" NSQ] "=" URI
> URI := ...
> 
> Cheers,
> 
> Chris
> 
> Marc Hadley wrote:
> 
> > Jean-Jacques Moreau wrote:
> > 
> >> +1
> >>
> >> IMHO, the current tables are not accurate enough (compared 
> to this other
> >> approach) and consumme too much space (I hate to say this 
> now that I have
> >> done the HTML to XML conversion, but...).
> >>
> > 
> > +1, I find this notation very succinct.
> > 
> > Marc.
> > 
> 
>

Received on Friday, 11 January 2002 05:28:46 UTC