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

Re: xp requirement document specifies headers

From: Mark A. Jones <jones@research.att.com>
Date: Wed, 24 Jan 2001 09:08:15 -0800
Message-ID: <3A6F0BFF.DFD20A1E@research.att.com>
To: xml-dist-app@w3.org
> Re: xp requirement document specifies headers
>
> From: Hugo Haas (hugo@w3.org)
> Date: Wed, Jan 24 2001
> ...
> I remember a discussion about an XP processor starting to process a
> message (for example starting to send an XP message back with a
> response to an RPC) and then being forced to generate a fault, which
> makes me think that indeed XP messages have to be processed as a
> whole.
>
> On the other hand, R309[2] is about resource constrained device. As
> Noah pointed out[3], the issues related to resource constrained
> devices have not been discussed in detail; I could imagine a system
> with very limited memory wanting to process an XP message "on the
> fly".
>
> So I think that it is an open issue. But I agree that not considering
> XP messages as a whole will lead to complication, and that to keep the
> processing model simple, considering XP messages as a whole is a good
> idea.
> ...

Some of the usage scenarios/cases [DS21] anticipate SAX-style incremental parsing and processing of XP messages
by the recipient.  Long messages could conceivably never be fully stored anywhere!!  They could be written on
the fly by the sender, incrementally passed through intermediaries and incrementally processed by the
recipient.  While it is true that one can imagine XP processing requirements in some cases that require a
complete pre-pass, it would be best if this does not become a hard and fast requirement or design feature.

--
Mark A. Jones
AT&T Labs - Research
Shannon Laboratory
Room A201
180 Park Ave.
Florham Park, NJ  07932-0971

email: jones@research.att.com
phone: (973) 360-8326
  fax: (973) 360-8970
Received on Wednesday, 24 January 2001 12:07:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:58 GMT