W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2000

RE: [DR008] - passing arbitrary content

From: Oisin Hurley <ohurley@iona.com>
Date: Wed, 13 Dec 2000 05:57:46 -0000
To: "Paul Denning" <pauld@mitre.org>, <xml-dist-app@w3.org>
Message-ID: <000b01c064c9$9df07700$d1cd0b3f@psychobilly>

[deleted]
> >"The XP specification must define a mechanism or mechanisms that
> >allow applications to submit application-specific content or information
> >  for delivery by XP.
>
> Does "for delivery by XP" imply part of the XP envelope?  Or by the same
> transport to which XP is bound?

I think that it means 'in the XP message' which, I humbly submit, means
'in the envelope or referred to from within the envelope'. Note that this
may imply that data which is referenced from within the envelope may be
fetched using a transport alternate to the one by which the XP message
was delivered.

> >In forming the standard for the mechanisms, the XP
> >  specification may consider support for:
>
>
> The word "may" is weak language.  The desire by some for a Normative
> approach to this "content" is why I suggested a new DR.

Intentional. What is listed in that requirement is a number of items
that are intended to stimulate discussion of various solutions. The
wording used to be stronger, but there was broad general feeling that
the result was too prescriptive for a requirement.

> Is it not redundant to say "outside the XP message" and "completely
> independent of that XP message"?

If there is an envelope abstraction and the envelope is the message,
then this is is true (that it is redundant). We should change terms
to speak about the envelope rather than the message.

[some deletia]

> An XP module "may" refer to arbitrary content independent of the protocol
> binding (or instance thereof) used to carry the XP envelope.  That is,
> minimal compliance to XP would require arbitrary content outside the XP
> message but inside the instance of the protocol binding used to carry the
> XP message.

What the working group needs to define is a standard extension mechanism
which may then be mapped to the various protocol bindings. For example,
the HTTP protocol binding could use MIME as one extension mechanism.

> If initially the XP spec only defines an HTTP
> binding, then it would define how this is done in an interoperable way.
Any
> updates to the XP spec or separate protocol binding specs should comply
with the XP
> requirement document's section on protocol bindings.

Yes.

[deletia]
> Or the intermediary could simply pass the reference along rather
> than fetch
> it.

Absolutely - whatever does the job as required.

> How should XP specify whether the intermediary should fetch the data
> or pass the reference?  It may be that the Ultimate XP receiver would
> prefer that the intermediary fetch the data, and the original XP
> sender may
> not really care.  How does the XP receiver tell XP senders whether or not
> to fetch out-of-band data and put it in-band (or take in-band data, cache
> it, and pass a reference to the cached data)?

This is the kind of thing we (the WG) are supposed to decide :)

  --oh
Received on Wednesday, 13 December 2000 00:58:14 GMT

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