W3C

SOAPResource Representation SOAP Header Block

W3C Working Draft 8 JuneCandidate Recommendation 16 August 2004

This version:
http://www.w3.org/TR/2004/WD-soap12-rep-20040608/http://www.w3.org/TR/2004/CR-soap12-rep-20040826/
Latest version:
http://www.w3.org/TR/soap12-rep/
Previous version:
http://www.w3.org/TR/2004/WD-soap12-rep-20040428/http://www.w3.org/TR/2004/WD-soap12-rep-20040608/
Editors:
Anish Karmarkar, Oracle Corp.
Martin Gudgin, Microsoft
Yves Lafon, W3C

Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Abstract

This document describes the semantics and serialization of a SOAP header block for carrying resource representations in SOAP messages.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is the W3C Last Call Working Drafta Candidate Recommendation of the SOAP Resource Representation Header document. ItW3C. This document has been produced by the XML Protocol Working Group (WG), which is(WG) as part of the W3C Web Services Activity. Discussion ofPublication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document takes place on the public xml-dist-app@w3.org mailing list (public archive) under the email communication rulesas other than work in progress.

This document is based upon the XML ProtocolSOAP Resource Representation Header Last Call Working Group Charter . CommentsDraft published on this document are welcome. Send them before 298 June 20042004. Changes between these two versions are described in a diff document.

The public is invited to xmlp-comments@w3.orgsend comments to the public mailing list (public archive)xmlp-comments@w3.org (Archive).

Note that all outstandingThe WG is soliciting implementation reports on this draft until at least 15 September 2004. All issues against this document are documented in the Working Group Last CallWG's Candidate Recommendation Issues List. IfWhen implementations of this document's important features are demonstrated to be interoperable between 2 or more different implementations, and the feedback onWG responds formally to all issues against this document is positive,document, then the WG plans to submit it for consideration as a W3C CandidateProposed Recommendation. Records of the interoperation of this document's features are recorded on the WG's Implementation Summary of Optimizations webpage.

This document has been produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy. Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.Table of Contents

1 Introduction
    1.1 Notational Conventions
    1.2 Relation to other specifications
        1.2.1 Relationship to the SOAP Processing model
2 SOAP Feature Name
3 SOAP Module Name
4 Representation Header     2.1Block
    4.1 Introduction
    2.2    4.2 Representation header block Constructs
        2.2.1        4.2.1 rep:Representation element
        2.2.2        4.2.2 resource attribute
        2.2.3        4.2.3 reinsert attribute
        2.2.4        4.2.4 rep:Data element
    2.3    4.3 Extensibility of the Representation header block
        2.3.1        4.3.1 SOAP header block Attributes
        2.3.2        4.3.2 Specifying the media type
        2.3.3        4.3.3 Extension example: HTTP headersresolver extension

Appendices

A References
B Acknowledgements (Non-Normative)

1 Introduction

This document describes the semantics and serialization of a SOAP header block for carrying resource representations in SOAP messages.

1.1 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119].

This specification uses a number of namespace prefixes throughout; they are listed in [Prefixes and Namespaces used in this specification.]. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see XML Infoset [XML InfoSet]).

Prefixes and Namespaces used in this specification.
PrefixNamespace
Notes
env"http://www.w3.org/2003/05/soap-envelope"
A normative XML Schema [XML Schema Part 1], [XML Schema Part 2] document for the "http://www.w3.org/2003/05/soap-envelope" namespace can be found at http://www.w3.org/2003/05/soap-envelope.
rep "http://www.w3.org/2004/02/representation""http://www.w3.org/2004/08/representation"
A normative XML Schema [XML Schema Part 1], [XML Schema Part 2] document for the "http://www.w3.org/2004/02/representation""http://www.w3.org/2004/08/representation" namespace can be found at http://www.w3.org/2004/02/representationhttp://www.w3.org/2004/08/representation.
xs"http://www.w3.org/2001/XMLSchema"
The namespace of XML Schema data types (see [XML Schema Part 2]).
xmlmime"http://www.w3.org/2004/06/xmlmime"
The namespace for representing MIME media-types in XML (see [Assigning Media Types to Binary Data in XML]).

All parts of this specification are normative, with the exception of examples and sections explicitly marked as "Non-Normative".

1.2 Relation to other specifications

TBDThis document along with [XOP] and [MTOM] has been produced in conjunction with the development of requirements, embodied in the requirements document [SOAP Optimized Serialization Use Cases and Requirements].

This document defines a SOAP Feature, and a SOAP Module that realizes the SOAP Feature, as specified by SOAP 1.2 [SOAP Part 1] 3.1 SOAP Features and [SOAP Part 1] 3.3 SOAP Modules.

Note: The Resource Representation header block is designed to optimize well when used with the SOAP Message Transmission Optimization Mechanism [MTOM].

Note: The Resource Representation header block is designed, but not required, to be used in conjunction with the Assigning Media Types to Binary Data in XML specification [Assigning Media Types to Binary Data in XML].

1.2.1 Relationship to the SOAP Processing model ThisProcessing model

This feature makes no changes to the SOAP processing model.

2 SOAP Feature Name

The Resource Representation header block defined by this document embodies the SOAP feature [SOAP Part 1] 3.1 SOAP Features identified by the URI:

The above SOAP feature URI can be used to identify the semantics and serialization of the Resource Representation header block.

3 SOAP Module Name

The SOAP Module [SOAP Part 1] 3.3 SOAP Modules that realizes the SOAP feature makes no changes todefined in 2 SOAP Feature Name is identified by the URI:

The above SOAP processing model. 2Module URI can be used to identify the semantics and serialization of the Resource Representation header block.

4 Representation Header Block

This section describes a SOAP header block, the Representation header block, that allows a SOAP message to carry representations of Web resources.

2.14.1 Introduction

The Representation header block is designed to allow applications to carry a representation of a Web resource in a SOAP message. Applications of this header include cases where the receiver has limited ability to get the representation using other means, for example because of access restrictions or because the overhead would be unacceptable. The representationRepresentation header block is also requireduseful when multiple references to the same extracted contentresource are required but duplication of extracted contentthe resource is undesirable. See UC2 and UC6 [SOAP Optimized Serialization Use Cases and Requirements] for details.

The meaning of the Representation header block, when present in a SOAP message, is to make available the contained representation of the resource it carries to the processing SOAP node. The SOAP node MAY use this representation when dereferencing the URI of the resource instead of making a network request to obtain a representation of the givenresource. Note that implementations MAY need to process a Representation header block before processing other header blocks that require dereferencing of a URI whose representation is carried in the Representation header block.

SeveralMultiple occurences of the Representation header block MAY be present in the same SOAP Message to carry representationsrepresentation of severalmultiple Web resourceresources or several representationmultiple representations of the same Web resource.

Several occurences of the Representation header block having the same value for the role and resource attribute information item (see 2.2.24.2.2 resource attribute) MAY be present in the same SOAP Message. Such Representation header blocks SHOULD NOT have the same metadata (such as media-type). If such Representation header blocks have the same metadata then any one of them may be used.

An example SOAP Envelope using the Representation header block is given below.

Example: Representation header block in a SOAP Envelope
<soap:Envelope xmlns:soap='http://www.w3.org/2002/12/soap-envelope' 
                xmlns:rep='http://www.w3.org/2004/02/representation'xmlns:rep='http://www.w3.org/2004/08/representation' 
               xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
  <soap:Header>
    <rep:Representation resource='http://example.org/me.png'>
      <rep:Data  xmlmime:contentType='image/png'> /aWKKapGGyQ= </rep:Data>xmlmime:contentType='image/png'>/aWKKapGGyQ=</rep:Data>
    </rep:Representation>
  </soap:Header>
  <soap:Body>
    <x:MyData xmlns:x='http://example.org/mystuff'>
      <x:name>John Q. Public</x:name>
      <x:img src='http://example.org/me.png'/>
    </x:MyData>
  </soap:Body>
</soap:Envelope>

2.24.2 Representation header block Constructs

2.2.14.2.1 rep:Representation element

The Representation element information item has:

The rep:Representation element information item contains a representation of a Web resource. The value of the resource element information item is the URI identifying the Web resource. The value of the rep:Data element information item is a base64-encoded representation of the Web resource.

2.2.24.2.2 resource attribute

The resource attribute information item has:

The type of the resource attribute information item is xs:anyURI. The value of the resource attribute information item is a URI that identifies the Web resource whose representation is carried in the rep:Representation element information item parent of the resource attribute information item.

2.2.34.2.3 reinsert attribute

The reinsert attribute information item has:

The type of the reinsert attribute information item is xs:boolean. When this attribute is specified on the Representation header block with a value of "true", it indicates that a SOAP forwarding intermediary node processing the header block must reinsert the header block. This means that when used in conjunction with the relay attribute, defined in [SOAP Part 1] 5.2.4 SOAP Relay Attribute, with a value of "true", the Representation header block will always be relayed by a SOAP forwarding intermediary. When this attribute is specified on the Representation header block with a value of "false", the behavior of the SOAP node processing the header block is the same as that when the attribute is not specified, and normal SOAP processing rules apply. The presence of this attribute has no effect on the processing of a Representation header by a SOAP endpoint.

2.2.44.2.4 rep:Data element

The Data element information item has:

The type of a rep:Data element information item is xs:base64Binary. The value of this element information item is a base64-encoded representation of the Web resource carried in the rep:Representation element information item parent of the resource attribute information item.

2.34.3 Extensibility of the Representation header block

The Representation header block is built to be extensible. This section describes several possible usage of this extensibility.

2.3.14.3.1 SOAP header block Attributes

Attributes defined in [SOAP Part 1] 5. SOAP Message Construct for SOAP header blocks MAY be used with the Representation header block.

Adding a env:mustUnderstand attribute information item with a value of "true" in the [attributes] property of the rep:Representation element information item ensures that the SOAP receiver is aware that the Web resource representation is available to it.

A env:role attribute information item in the [attributes] property of the rep:Representation element information item indicates the SOAP node for which the Web resource representation is intended.

2.3.24.3.2 Specifying the media type

An xmlmime:contentType attribute information item (See [Assigning Media Types to Binary Data in XML]) MAY be used to convey the media type of the representation conveyed by a header. Media type information can be useful in determining whether a given representation is suitable for processing and if it is, how best to interpret the representation provided. If used, the xmime:contentType attribute information item MUST appear within the [attribute] property of the rep:Data element information item. An example of this usage is showshown in Example Example.

2.3.34.3.3 Extension example: HTTP headersresolver extension

A receiving SOAP node MAY act as a resolver, with all the rules pertaining to HTTP caches, for some or all of the http: scheme URIs for which representations have been provided. To enable this, one or more element information items MAY be added to the [children] property of the rep:Representation element information item to transmit the information needed at the HTTP level.

To avoid requiring that all SOAP senders understand HTTP caching mechanism, all the data required by a processor that wants to act as a local cache needs to be carried along with the message. This includes the complete request, reply as well as the time the original HTTP request has been sent and the time the HTTP response has been received.

Example: HTTP extension
<soap:Envelope xmlns:soap='http://www.w3.org/2002/12/soap-envelope' 
               xmlns:rep='http://www.w3.org/2004/08/representation' 
               xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
  <soap:Header>
    <rep:Representation resource='http://example.org/me.png'>

      <rep:Data xmlmime:contentType='image/png'>/aWKKapGGyQ=</rep:Data>
      <htx:env  xmlns:htx="http://www.w3.org/2004/02/xop/http">xmlns:htx="http://www.w3.org/2004/08/representation/http">
        <htx:request>
          <htx:request-line name="GET" version="HTTP/1.1">
             /someuri/xmlp.png/me.png
          </htx:request-line>
          <htx:header name="Host">
             www.example.comexample.org
          </htx:header>
          <htx:header name="Accept">
            image/png,image/jpeg,image/gif
          </htx:header>
          <htx:header name="Accept-Encoding">
            gzip,deflate,compress;q=0.9
          </htx:header>
          <htx:header name="Date">
            Fri, 13 Feb 2004 11:23:28 GMT
          </htx:header>
          [...]
          <htx:time>
            Fri, 13 Feb 2004 11:23:28 GMT
          </htx:time>    
        </htx:request>
        <htx:reply>
          <htx:status-line version="HTTP/1.1" status="200">
            OK
          </htx:status-line>
        <htx:header name="Content-Type">
          image/png
        <htx:header>
        <htx:header name="Date">
          Fri, 13 Feb 2004 11:23:28 GMT
        </htx:header>
        [...]
        <htx:time>
          Fri, 13 Feb 2004 11:23:32 GMT
        </htx:time>    
        </htx:reply>
      </htx:env>
      
    </rep:Representation>
  </soap:Header>
  <soap:Body>
    <x:MyData xmlns:x='http://example.org/mystuff'>
      <x:name>John Q. Public</x:name>
      <x:img src='http://example.org/me.png'/>
    </x:MyData>
  </soap:Body>
</soap:Envelope>

Note that if the clocks of the SOAP sender and the SOAP recipient are not synchronized, all the expiration/age computed at the receiving side will not accurately reflect what could have been computed at the SOAP sender side.

A References

SOAP Part 1
W3C Recommendation "SOAP Version 1.2 Part 1: Messaging Framework", M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. F. Nielsen, May 2003. (See http://www.w3.org/TR/soap12-part1/.)
SOAP Part 2 W3C Recommendation "SOAP Version 1.2 Part 2: Adjuncts", M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. F. Nielsen, May 2003. (See http://www.w3.org/TR/soap12-part2/.)XOP
W3C Working Draft "XML-binary Optimized Packaging", N. Mendelsohn, M. Nottingham, H. Ruellan, JuneAugust 2004. (See http://www.w3.org/TR/2004/WD-xop10-20040608/.) SOAP 1.2 Attachment Featurehttp://www.w3.org/TR/2004/CR-soap12-xop-20040816/.)
MTOM
W3C Working Group NoteDraft "SOAP 1.2 Attachment Feature", H. F. Nielsen,Message Transmission Optimization Mechanism", N. Mendelsohn, M. Nottingham, H. Ruellan, JuneAugust 2004. (See http://www.w3.org/TR/2004/NOTE-soap12-af-20040608/.)http://www.w3.org/TR/2004/CR-soap12-mtom-20040816/.)
SOAP Optimized Serialization Use Cases and Requirements
W3C Working Draft "SOAP Optimized Serialization Use Cases and Requirements", M. A. Jones, Tony Graham, Anish Karmarkar, June 2004. (See http://www.w3.org/TR/2004/WD-soap12-os-ucr-20040608/.)
XML 1.0 W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (See http://www.w3.org/TR/2000/REC-xml-20001006.) Namespaces in XML W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (See http://www.w3.org/TR/1999/REC-xml-names-19990114/.) XMLInfoSet
W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (See http://www.w3.org/TR/2001/REC-xml-infoset-20011024/.)
XML Schema Part 1
W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.)
XML Schema Part 2
W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.)
XML Schema Part 2 Errata W3C Internal Working Draft 7 March 2003 Id: datatypes-with-errata.xml,v 1.5 2003/03/07 19:54:00 (See http://www.w3.org/XML/Group/2002/09/xmlschema-2/datatypes-with-errata.html.) XML Query Data Model "XQuery 1.0 and XPath 2.0 Data Model", Mary Fernández, Ashok Malhotra, Jonathan Marsh, Marton Nagy, Norman Walsh, November 2003. (See http://www.w3.org/TR/xpath-datamodel/.)RFC 2119
IETF "RFC 2119: Keywords for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)
RFC 2387 IETF "The MIME Multipart/Related Content-type", E. Levinson, August 1998. (See http://www.ietf.org/rfc/rfc2387.txt.) PASWA "Proposed Infoset Addendum to SOAP Messages with Attachments", April 2003. (See http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html.)Assigning Media Types to Binary Data in XML
W3C Working Draft "Assigning Media Types to Binary Data in XML", Anish Karmarkar, Ümit Yalçınalp, June 2004. (See http://www.w3.org/TR/2004/WD-xml-media-types-20040608.)

B Acknowledgements (Non-Normative)

This specification is the work of the W3C XML Protocol Working Group.

Participants in the Working Group are (at the time of writing, and by alphabetical order): TBDDavid Fallside (IBM), Tony Graham (Sun Microsystems), Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor), Marc Hadley (Sun Microsystems), Gerd Hoelzing (SAP AG), John Ibbotson (IBM), Anish Karmarkar (Oracle), Suresh Kodichath (IONA Technologies), Yves Lafon (W3C), Michael Mahan (Nokia), Noah Mendelsohn (IBM, formerly of Lotus Development), Jeff Mischkinsky (Oracle), Jean-Jacques Moreau (Canon), Mark Nottingham (BEA Systems, formerly of Akamai Technologies), David Orchard (BEA Systems, formerly of Jamcracker), Herve Ruellan (Canon), Jeff Schlimmer (Microsoft Corporation), Pete Wenzel (SeeBeyond), Volker Wiechers (SAP AG).

Previous participants were: TBDYasser alSafadi (Philips Research), Bill Anderson (Xerox), Vidur Apparao (Netscape), Camilo Arbelaez (webMethods), Mark Baker (Idokorro Mobile, Inc., formerly of Sun Microsystems), Philippe Bedu (EDF (Electricite De France)), Olivier Boudeville (EDF (Electricite De France)), Carine Bournez (W3C), Don Box (Microsoft Corporation, formerly of DevelopMentor), Tom Breuel (Xerox), Dick Brooks (Group 8760), Winston Bumpus (Novell, Inc.), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), Michael Champion (Software AG), David Chappell (Sonic Software), Miles Chaston (Epicentric), David Clay (Oracle), David Cleary (Progress Software), Dave Cleary (webMethods), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Fransisco Cubera (IBM), Jim d'Augustine (Excelon Corporation), Ron Daniel (Interwoven), Glen Daniels (Macromedia), Doug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE Corporation), Frank DeRose (TIBCO Software, Inc.), Mike Dierken (DataChannel), Andrew Eisenberg (Progress Software), Brian Eisenberg (DataChannel), Colleen Evans (Sonic Software), John Evdemon (XMLSolutions), David Ezell (Hewlett Packard), James Falek (TIBCO Software, Inc.), Eric Fedok (Active Data Exchange), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Michael Freeman (Engenia Software), Dietmar Gaertner (Software AG), Scott Golubock (Epicentric), Mike Greenberg (IONA Technologies), Rich Greenfield (Library of Congress), Hugo Haas (W3C), Mark Hale (Interwoven), Randy Hall (Intel), Bjoern Heckel (Epicentric), Frederick Hirsch (Zolera Systems), Erin Hoffmann (Tradia Inc.), Steve Hole (MessagingDirect Ltd.), Mary Holstege (Calico Commerce), Jim Hughes (Fujitsu Limited), Oisin Hurley (IONA Technologies), Yin-Leng Husband (Hewlett Packard, formerly of Compaq), Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.), Scott Isaacson (Novell, Inc.), Kazunori Iwasa (Fujitsu Limited), Murali Janakiraman (Rogue Wave), Mario Jeckle (DaimlerChrysler Research and Technology), Eric Jenkins (Engenia Software), Mark Jones (AT&T), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Jacek Kopecky (Systinet), Alan Kropp (Epicentric), Julian Kumar (Epicentric), Peter Lecuyer (Progress Software), Tony Lee (Vitria Technology Inc.), Michah Lerner (AT&T), Bob Lojek (Intalio Inc.), Henry Lowe (OMG), Brad Lund (Intel), Matthew MacKenzie (XMLGlobal Technologies), Murray Maloney (Commerce One), Richard Martin (Active Data Exchange), Alex Milowski (Lexica), Kevin Mitchell (XMLSolutions), Nilo Mitra (Ericsson), Ed Mooney (Sun Microsystems), Dean Moses (Epicentric), Highland Mary Mountain (Intel), Don Mullen (TIBCO Software, Inc.), Rekha Nagarajan (Calico Commerce), Raj Nair (Cisco Systems), Masahiko Narita (Fujitsu Limited), Mark Needleman (Data Research Associates), Art Nevarez (Novell, Inc.), Eric Newcomer (IONA Technologies), Henrik Nielsen (Microsoft Corporation), Conleth O'Connell (Vignette), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Andreas Riegg (DaimlerChrysler Research and Technology), Vilhelm Rosenqvist (NCR), Marwan Sabbouh (MITRE Corporation), Waqar Sadiq (Vitria Technology Inc.), Rich Salz (Zolera Systems), Krishna Sankar (Cisco Systems), George Scott (Tradia Inc.), Shane Sesta (Active Data Exchange), Lew Shannon (NCR), John-Paul Sicotte (MessagingDirect Ltd.), Miroslav Simek (Systinet), Simeon Simeonov (Macromedia), Aaron Skonnard (DevelopMentor), Nick Smilonich (Unisys), Seumas Soltysik (IONA Technologies), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Anne Thomas Manes (Sun Microsystems), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Jim Trezzo (Oracle), Asir Vedamuthu (webMethods), Randy Waldrop (WebMethods), Fred Waskiewicz (OMG), David Webber (XMLGlobal Technologies), Ray Whitmer (Netscape), Stuart Williams (Hewlett Packard), Yan Xu (DataChannel), Amr Yassin (Philips Research), Susan Yee (Active Data Exchange), Jin Yu (MartSoft Corp.).

This document has its genesis as a separate section in the SOAP Message Transmission Optimization Mechanism (MTOM) document. The editors of the MTOM document, specifically Mark Nottingham and Hervé Ruellan are gratefully acknowledged.

The people who have contributed to discussions on xml-dist-app@w3.org are also gratefully acknowledged.