W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2002

RE: Proposal for new last call issue: Some unprocessed headers should stay

From: Jacek Kopecky <jacek@systinet.com>
Date: 17 Oct 2002 00:07:00 +0200
To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Cc: Martin Gudgin <mgudgin@microsoft.com>, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, XMLP Dist App <xml-dist-app@w3.org>
Message-Id: <1034806049.3074.200.camel@krava>

Henrik, please see inline.

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation

On Wed, 2002-10-16 at 23:44, Henrik Frystyk Nielsen wrote:
> Jacek,
> I am not aware of us ever having said anything about whether there is
> one or many nodes that may act in a single role. Unless we are
> introducing such semantics for roles in general (which I would not be
> happy about) then I don't understand why you separate the scenarios of
> the node acting in a role being special from the ones where any
> subsequent nodes acting in that role.

I'm unsure about whether you understood me as saying there is always
only one node playing a given custom role (which I haven't even thought)
or as saying there is always many nodes playing a given custom role
(which is impossible on short paths).

I know that with the exception of SOAP-defined role names, any node can
play any role.

> Settling on a default for what to do will make the other case harder.
> Leaving out the possibility of adding an attribute, the point of my
> scenario was that the relay role AND the current default would allow
> both cases while maintaining the optionality. However, I can't see this
> being the case if the default was turned the other way.

My table shows that flipped default handles more of the 6 targeting
scenarios - basically five well and one partially (number 1) - whereas
the special role only handles one scenario well (number 1) and two
partially (numbers 3 and 6), leaving three scenarios impossible.

My text later after the table shows why I give more weight to scenario 2
than to 1 - because of my perceived semantics of role names and their
role in a system design.

Btw, why are you leaving out the possibility of adding an attribute? I
haven't noticed a message where you'd say you can't live with this
solution (but then I haven't been following the thread in its

If anything in my message is wrong (missing scenarios, wrong values in
the table or the intended semantics of a role name), please say so
explicitly because otherwise I might not catch it.

Received on Wednesday, 16 October 2002 18:07:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:21 UTC