W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2001

Re: [AMG] Comments on strawman: Terminology and Diagrams

From: Mark Baker <mark.baker@canada.sun.com>
Date: Tue, 30 Jan 2001 10:47:37 -0500
Message-ID: <3A76E219.506CA398@canada.sun.com>
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
CC: xml-dist-app@w3.org
Oops, sorry, just getting to these now ...

"Williams, Stuart" wrote:
> Mark,
> Thanks for your comments - much appreciated. I thought I'd respond in two
> chucks to separate out the discussion threads.
> I think your comments are made against a PDF version I sent to the WG. It
> looks like I have broken the section numbering in the HTML version [1].
> There seem to be two section 2's in [1]. I'll get that one fixed when we
> update the document.

Ah, didn't notice that.  I'll keep that in mind for future referencing.

> > - I'd like to see the synchronicity between client & server in this
> > architecture leveraged in this document.  In particular, I'd
> > like to see what is described as an "XP Client" to be considered an XP
> processor
> > that terminates.  i.e. XP processors process XP messages - some XP
> > processors pass along their messages to another processor,
> > others don't.
> Ray Dennenburg has made similar remarks with different suggestions.
> Unfortunately his message only went to thw WG list, but you can find it
> embedded in [2] in the xml-dist-app archive.
> Taken together I think the sugestions are to rename "XP Client" to one of
> "XP Processor", "XP User" or "XP Service User". In all cases an intermediary
> would be an "XP Client" (however relabelled) that happens to pass messages
> along.
> "XP Processor" is fine by me and does bring about some alignment with the
> glossary in the requirements document.

Yes, I think so.  Thanks.

I wouldn't mind using the word "intermediary" there someplace though. 
Perhaps we could have "Terminating XP Processors", and "XP Processing
Intermediaries".  But then "XP Processor" wouldn't have any meaning.  Oh
well, we can talk about this on the call.

> Ray: any comments?
> > - re diagram in section 2 and subsequent question about layering, I'd
> > like to see 2 layers only; an XP layer with intermediaries and
> > terminating processors, and a "transport" layer with "transport"
> > intermediaries.
> So... if I understand how you'd like to see the picture drawn... you'd like
> to move the initiating and responding XP Clients (my labeling) and the
> intermediaries down below the horizontal line they currently sit above. You
> may also be seeking to then have those entities merged with the 'XP_Layer
> Entities' shown in the 'XP layer'.

If I understand you correctly, then yes.  As a picture is supposed to be
worth a thousand words ...

   [TXPP] <-> [XPP] <-> [XPP] <-> [TXPP]
    [TTI]    <->   [TI]    <->   [TTI]

TXPP = "terminating XP processor"
XPP = "XP processor"
TTI = "terminating transport intermediary"
TI = "transport intermediary"

BTW, is it really too late to change our use of "transport"?  I cringe
every time I write it.  It marginalizes the value that application
protocols like HTTP provide.

Can't we just call them "underlying protocols", as you do in your
diagram?  "application or transport protocols" would work too.  As would
"transfer or transport protocols".

> > - would like to see notation synchronized with Henrik's (private, it
> > appears) glossary submission (and vice-versa, if necessary)
> I am both sympathetic to this, but I also have a difficulty The main problem
> I have is that we have a glossary in a *requirements* document that seems to
> be constraining our ability to create terminology as we being rough out the
> space of a *solution*. I see the purpose of a glossary in a requirements
> document to be to help elaborate requirement.
> It may be that what we really need is a separate and living glossary. It
> seems to me that there are knock-on effects when you 'play' with one term,
> it has an effect on others. Getting a fully rounded set that fit comfortably
> together is hard.

I agree.  And I had actually forgotten that we tacked it onto the end of
the requirements draft we published.  Breaking it out so as to emphasize
that it's relevant to more than just the requirements document (in
particular, the abstract model), is a good idea.

Received on Tuesday, 30 January 2001 10:47:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:30 UTC