Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document defines the XML-binary Optimized Packaging (XOP) convention, a means of more efficiently serializing XML Infosets that have certain types of content.
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 theW3CLastCallWorkinga Candidate Recommendation of the DraftXML-binaryOptimizedPackagingdocument.W3C.
This document has been produced by the
XML Protocol Working Group It(WG),which(WG)
as part of the W3C
Web Services Activity.
isDiscussionPublication 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 oftakesplaceonthepublicxml-dist-app@w3.orgmailinglist(publicarchive)undertheemailcommunicationas other than work in progress.
rules
This document is based upon the
XMLXML-binary Optimized Packaging
Last Call Working ProtocolGroupCharter.Draft published on Commentsthisdocumentarewelcome.Sendthembefore8 June 292004.
Changes between these two versions are described in a diff document.
2004
The public is invited to send comments to the public mailing list
xmlp-comments@w3.org(publicxmlp-comments@w3.org
(Archive).
archive)
NotethatallThe WG is soliciting implementation reports on this draft until at least
15 September 2004. All issues against this document are documented in the outstandingWorkingGroupLastWG's
Candidate Recommendation Issues List. CallWhen implementations of this
document's important features are demonstrated to be interoperable between
2 or more different implementations, and the IffeedbackWG responds formally to all
issues against this ondocumentisdocument, then the WG plans to submit it for
consideration as a W3C positive,Proposed Recommendation. Records of the
interoperation of this document's features are recorded on the WG's
Implementation Summary of Optimizations webpage.
Candidate
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.
1 Introduction
1.1 Terminology
1.2 Example
1.3 Notational Conventions
2 XOP Infoset ConstructsInfosets
2.1 xop:Include element information item
2.2 href attribute information item
3 XOP Processing ModelXOP's
3.1 Creating XOP Packages
3.2 Interpreting XOP Packages
4 XOP Packages
4.1 MIME Multipart/Related XOP Packages
5 Identifying XOP Documents
5.1 Registration
6 Security Considerations
6.1 XOP Package Integrity
6.2 XOP Package Confidentiality
A Relationship to other specifications
A.1 Dependencies
A.2 Payload
A.3 Extension
A.4 Requirements
B References
B.1 Normative References
B.2 Informative References
C Acknowledgements (Non-Normative)
This specification defines the XML-binary Optimized Packaging (XOP) convention, a means of more efficiently serializing XML Infosets (see [XML InfoSet]) that have certain types of content.
A XOP package is created by placing a serialization of the XML Infoset inside of an extensible packaging format (such a MIME Multipart/Related, see [RFC 2387]). Then, selected portions of its content that are base64-encoded binary data are re-encoded (i.e., the data is decoded from base64) and placed into the package. The locations of those selected portions are marked in the XML with a special element that links to the packaged data using URIs.
In a number of important XOP applications, binary data need never be encoded in base64 form. If the data to be included is already available as a binary octet stream, then either an application or other software acting on its behalf can directly copy that data into a XOP package, at the same time preparing suitable linking elements for use in the root part; when parsing a XOP package, the binary data can be made available directly to applications, or, if appropriate, the base64 binary character representation can be computed from the binary data.
However, at the conceptual level, this binary data can be thought of as
being base64-encoded in the XML Document. As this conceptual form might
be needed during some processing of the XML Document (e.g., for signing
the XML document), it is necessary to have a one to one correspondence
between XML Infosets and XOP Packages. Therefore, the conceptual
representation of such binary data is as if it were base64-encoded,
using the canonical lexical form of XML Schema base64Binary
datatype (see [XML Schema Part 2] 3.2.16
base64Binary). In the reverse direction, XOP is capable of
optimizing only base64-encoded Infoset data that is in the canonical
lexical form.
Asaresult,Only element content can be optimized; attributes,
non-base64-compatible character data, and data not in the canonical
representation of the onlybase64Binary
datatype cannot be
successfully optimized by XOP.
The remainder of this specification is organized in the following fashion:
Section 2 describes the XOP Infoset, which preserves the
non-optimized content and structure of the original XML Infoset.
Two
Section 3 specifies Threethe XOP processing model.
XOP's
Section 4 of this specification describes the form of the XOP
Package.
Four
Section 5 describes how XOP Documents are identified.
Five
Section 6 explores the security considerations of using the XOP
convention.
Six
This specification uses terminology from the XML Infoset (see [XML InfoSet]) when discussing XML content and structure. This
is only a convention for clear specification of XOP behavior.
XOP's
The following terms are used in this specification:
xop:Include
element information items.
Example shows an XML Infoset prior to XOP
processing. Example shows the same
Infoset, serialized using the XOP format in a MIME Multipart/Related
package. The base64-encoded content of the m:photo
and
m:sig
elements have been replaced by a
xop:Include
element, while
the binary octets have been serialized in separate MIME parts. Note
that those examples usesuse [Assigning Media Types to Binary Data in XML] to identify the
media type of the content of the [media-type]m:photo
and
m:sig
elements.
<soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope'xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'> <soap:Body> <m:data xmlns:m='http://example.org/stuff'> <m:photoxmlns:xop='http://www.w3.org/2003/12/xop/include'xmlmime:content-type='image/png'>/aWKKapGGyQ=xmlmime:contentType='image/png'>/aWKKapGGyQ=</m:photo> <m:sig</m:photo>xmlmime:content-type='application/pkcs7-signature'>Faa7vROi2VQ=xmlmime:contentType='application/pkcs7-signature'>Faa7vROi2VQ=</m:sig> </m:data> </soap:Body> </soap:Envelope></m:sig>
MIME-Version: 1.0 Content-Type: Multipart/Related;boundary=MIME_boundary;type="application/xop+xml"; start="<mymessage.xml@example.org>"; startinfo="application/soap+xml; action=\"ProcessData\"" Content-Description:type=text/xml;start="<mymessage.xml@example.org>"AnXMLA SOAP message with mydocumentpic andpicturesig in it --MIME_boundary Content-Type:signaturetext/xml;application/xop+xml; charset=UTF-8; type="application/soap+xml; action=\"ProcessData\"" Content-Transfer-Encoding: 8bit Content-ID: <mymessage.xml@example.org> <soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope'charset=UTF-8xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'> <soap:Body> <m:data xmlns:m='http://example.org/stuff'> <m:photoxmlns:xop='http://www.w3.org/2003/12/xop/include'xmlmime:content-type='image/png'><xop:Includehref='cid:http://example.org/me.png'/>xmlmime:contentType='image/png'><xop:Include xmlns:xop='http://www.w3.org/2004/08/xop/include' href='cid:http://example.org/me.png'/></m:photo> <m:sig</m:photo>xmlmime:content-type='application/pkcs7-signature'><xop:Includehref='cid:http://example.org/my.hsh'/>xmlmime:contentType='application/pkcs7-signature'><xop:Include xmlns:xop='http://www.w3.org/2004/08/xop/include' href='cid:http://example.org/my.hsh'/></m:sig> </m:data> </soap:Body> </soap:Envelope> --MIME_boundary Content-Type: image/png Content-Transfer-Encoding: binary Content-ID: <http://example.org/me.png> // binary octets for png --MIME_boundary Content-Type: application/pkcs7-signature Content-Transfer-Encoding: binary Content-ID: <http://example.org/my.hsh> // binary octets for signature --MIME_boundary--</m:sig>
Example shows anotherserializationan XML Infoset prior to XOP
processing. Example shows the same
ofInfoset, XMLwhenithappensserialized using the thatphotoXOP format in containedthem:photoelementisavailableontheweb.Takingadvantageofthis,theserializationa usesContent-LocationheaderMIME Multipart/Related
package. The base64-encoded content of the insteadm:photo
and
m:sig
elements have been replaced by a
element, while
the binary octets have been serialized in separate MIME Content-IDheadertoxop:Includeidentifypartcontainingtheparts.
photo.
<m:data xmlns:m='http://example.org/stuff'> <m:photo>/aWKKapGGyQ=</m:photo> <m:sig>Faa7vROi2VQ=</m:sig> </m:data>
MIME-Version: 1.0 Content-Type: Multipart/Related;boundary=MIME_boundary;type="application/xop+xml"; start="<mymessage.xml@example.org>"; start-info="text/xml" Content-Description: An XML document with mytype=text/xml;start="<mymessage.xml@example.org>"pic andpicturesig in it --MIME_boundary Content-Type:signaturetext/xml;application/xop+xml; charset=UTF-8; type="text/xml" Content-Transfer-Encoding: 8bit Content-ID: <mymessage.xml@example.org>charset=UTF-8<soap:Envelopexmlns:soap='http://www.w3.org/2003/05/soap-envelope'xmlns:xop='http://www.w3.org/2003/12/xop/include'xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'><m:data xmlns:m='http://example.org/stuff'><soap:Body><m:photoxmlmime:content-type='image/png'><xop:Includehref='http://example.org/me.png'/></m:photo><m:sigxmlmime:content-type='application/pkcs7-signature'><xop:Includehref='cid:http://example.org/my.hsh'/><m:photo><xop:Include xmlns:xop='http://www.w3.org/2004/08/xop/include' href='cid:http://example.org/me.png'/></m:photo> <m:sig><xop:Include xmlns:xop='http://www.w3.org/2004/08/xop/include' href='cid:http://example.org/my.hsh'/></m:sig> </m:data></m:sig></soap:Body>--MIME_boundary Content-Type: image/png Content-Transfer-Encoding: binary</soap:Envelope>Content-Location:Content-ID: <http://example.org/me.png> // binary octets for png --MIME_boundary Content-Type: application/pkcs7-signature Content-Transfer-Encoding: binary Content-ID: <http://example.org/my.hsh> // binary octets for signature --MIME_boundary--http://example.org/me.png
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 below. Note that the choice of any namespace prefix is arbitrary and not semantically significant.
Prefix | Namespace |
---|---|
Notes | |
xop | |
A non-normative XML Schema [XML Schema Part 1], [XML Schema Part 2] document for the
| |
xmlmime | "http://www.w3.org/2004/06/xmlmime" |
The namespace for the content type attribute. | |
xs | "http://www.w3.org/2001/XMLSchema" |
The namespace of XML Schema data types [XML Schema Part 2]. |
Editorial note: HR | |
Note that the "http://www.w3.org/2004/06/xmlmime" URI is not final and will be changed. |
XOP operates by extracting the Optimized Content from the Original
Infoset to create the XOP Infoset. In particular, the character
information item children of element information
items to be optimized are removed and replaced with an
element information item named xop:Include
.
The xop:Include
element information item
contains an attribute information item with a link to
the part of the XOP Package that carries a binary representation of the
data removed from the original element information item.
Details of the construction and processing of XOP serializations are
provided in 3 XOP Processing Model.
XOP's
The Infoset used as input to XOP processing MUST NOT contain any
element information item with a [namespace name]
property of "http://www.w3.org/2004/08/xop/include"
and a [local name] property of "http://www.w3.org/2003/12/xop/include"Include
. Infosets
containing such element information items cannot be
serialized using XOP.
The following subsections provide formal definitions for allowable content in the
element information item and attribute information
items used to construct a XOP serialization; content not explicitly specified
is disallowed. A non-normative XML Schema for [XML 1.0] serializations of those
element information item and attribute
information items can be found at serialization.http://www.w3.org/2004/08/xop/include.
http://www.w3.org/2000/xp/Group/3/06/Attachments/include.xsd
xop:Include
element information item
The xop:Include
element information item
hasthefollowingconstraintsonitsproperties:has:
Its
Include
.
href
attribute information
item (see 2.2 href attribute information item).
xop:Include
element information xop:Include
element information href
attribute information item
The href
attribute information item hasthefollowingconstraintsonitsproperties:has:
Its
href
.
xop:Include
element information item). The [normalized value] MUST be a
valid URI per the cid: URI scheme (see [RFC 2392]). In addition,
the [normalized value] MUST be a valid lexical form of the XML Schema xs:anyURI
datatype (see [XML Schema Part 2]3.2.17
anyURI).
xop:Include
element information item containing the
attribute information item.
This section describes the processing model for creating XOP Packages and interpreting XOP Packages. Unless otherwise stated, the result of such processing MUST be semantically equivalent to performing the specified steps separately, and in the order given.
To create a XOP Package from an Original XML Infoset:
Include
. As discussed in 2 XOP xs:base64Binary
(see [XML Schema Part 2]3.2.16
base64Binary) and MUST xop:Include
element
information item (see 2.1 xop:Include element information item) constructed as follows:
href
attribute information item of
the xop:Include
element information
item (see 2.2 href attribute information item).
xop:Include
element information item)
has a xmlmime:content-typexmlmime:contentType
attribute
information item, its value SHOULD be reflected
appropriately in the Additional parts MAY be added to the package to satisfy application specific requirements. Other content-specific metadata MAY be reflected in the packaging metadata as appropriate.
If content cannot be successfully encoded into the XOP package,
implementations SHOULD behave as if that portion of the Original XML
Infoset was not nominated for optimization.
Infoset,
This section specifies the means by which the Original XML Infoset can be reconstructed from a XOP Package that has been prepared according to the rules of 3.1 Creating XOP Packages.
Note: conventions or error reporting mechanisms to be used in processing packages that incorrectly purport to be XOP Packages are beyond the scope of this specification.
To create a Reconstituted XML Infoset from a XOP Package:
xop:Include
element information item (as defined in 2.1 xop:Include element information item):
xop:Include 'shref
attribute information item of
the xop:Include
element information item (i.e., corresponding to the URI
encoded in the attribute information item's
[normalized value]).
xop:Include
element information item xop:Include
element information item
with the data reconstructed from the
package part).
XOP is capable of using a variety of underlying packaging mechanisms.
Such packaging mechanisms MUST be able to represent, with full fidelity
all the parts created according to 3 XOP Processing Model (see 3.1 Creating XOP Packages XOP's), and MUST be used in a manner that provides a
means of designating a distinguished root (main, primary etc.) part.
).
The subsection below specifies normatively how a particular packaging mechanism, MIME Multipart/Related, is used, but does not preclude the use of other packaging mechanisms with the XOP convention.
This section describes how MIME Multipart/Related packaging (as specified in [RFC 2387]) is used with XOP.
The root MIME part is the root part of the XOP package, MUST be a
serialization of the XOP Infoset using any W3C recommendation-level
version of XML (e.g., [XML 1.0], [XML 1.1]), andasdefinedbelow.ThisrootMIMEand
MUST be identified with a media type partthatisspecifictotheXOPof "application/xop+xml" (as defined below).
The "start-info" parameter of the encodingOriginalXMLInfoset'smediatype,asdescribedin5IdentifyingXOPDocuments.package's media type ThisMAYspecifywhichversionMUST contain the content type
associated with the content's XML ofwasusedserialization. (i.e. it will contain the forsame
value as the "type" parameter of the serializationXOProot part).
Infoset.
Except for purposes of determining the root MIME part, as specified by [RFC 2387], ordering of MIME parts MUST NOT be considered significant to XOP processing or to the construction of the XOP Infoset.
Part metadata is reflected in MIME header fields. Specifically,
the URI used in the value of ifaxop:Includean element'shref
attribute
information item on a has
element
information item contains a URI that uses the 'cid'xop:Includescheme,correspondingMIMEpart'sContent-IDheader'cid:' scheme
(see [RFC field2387]and2392] [RFC), so the corresponding MIME
part MUST have a )correspondingfield-value.Otherwise,theMIMEpart'sContent-ID header field (see [RFC Content-Location2557])MUST2387]
with a havefield-valueidenticaltotheURIinthevalueofthehrefcorresponding field-value.
attribute.
Furthermore, if a
attribute
information item is found (as described in 3 xmlmime:contentTypexmlmime:content-typeXOP Processing Model), it SHOULD be reflected in the field value
of the MIME Content-Type XOP'sheader'sheader.
field-value.
XOP Packagescanuseanyofavarietyofpackagingmechanisms,andfurthermorecanserializeanynumberofXMLformats.ToenableapplicationstoidentifytheuseofXOPaswellDocuments, when used in MIME-like systems, are identified with
the asoriginal"application/xop+xml" media type, Infoset'sadistinctmediatypeMUSTberegisteredforeachapplicationofXOPtoaparticularXMLapplicationvocabulary.Thismediatypewillbeusedtowith the labelXOPpackage'srootpart,required "type" parameter conveying
the whilepackage'smediatypeitselfisunchanged.FormatsMAYalsorestrictwhichversionoriginal XML serialisation's associated content type. Note that when the oftype
mediaparameter contains reserved characters, it needs to be allowsusedintheXOPappropriately quoted and escaped.Infoset.
For example, iftheformatidentifiedby"application/soap+xml"istobepackagedasXOPserializations,a thenXOP-specificmediatype(e.g.,"application/soap_xop+xml")MUSTberegistered.XOP Apackage using PackagetheMIME multipart/related packaging Multipart/Relatedmechanismandserializingto serialize a
SOAP 1.2 message [SOAP Part 1] with an suchaction parameter of "http://www.example.net/foo"
would Infosethavelabel the package amediatypeitself with the "multipart/related"
media type, and ofthe root part with the "application/xop+xml" media type along with a type parameter
containing "application/soap+xml;action=\"http://www.example.net/foo\"".
a
application
xop+xml
This parameter conveys the content type associated with the XML serialization of "application/soap_xop+xml".Processorsthe XOP infoset, including parameters as appropriate.wishing
This parameter has identical semantics to the charset parameter
of the "application/xml" media type as specified in
RFC 3023 [RFC3023].identify
Identical to those of "application/xml" as described in RFC 3023 [RFC3023], section 3.2.
In addition to application-specific considerations, XOP has the same security considerations described in RFC3023 [RFC3023], section 10.
There are no known interoperability issues.
This document
No known applications currently use this media type.type
Mark Nottingham <mnot@pobox.com>
COMMON
The XOP specification is currentlynoconventionforstructuringthea work product of namesXOP-basedmediathe World Wide Web Consortium's XML Protocol Working Group. The W3C has change control over this specification.types.
The integrity of Infosets optimized using XOP may need to be ensured.
As XOP packages can be transformed to recover such Infosets (see
3.2 Interpreting XOP Packages ), existing XML Digital
Signature techniques can be used to protect them. Note, however, that
a signature over the Infoset does not necessarily protect against
modifications of other aspects of the XOP packaging; for example, an
Infoset signature check might not protect against re-ordering of
non-root parts.
,
In the future a transform algorithm for use with XML Signature could provide a more efficient processing model where the raw octets are digested directly.
The confidentiality of XOP Packages may need to be ensured. As such
packages can be transformed to an XML Information Set, existing XML
Encryption (see [XML Encryption]) techniques can be used to
protect such packages. Any part of a package can be encrypted,
whether it includes base64 characters or not. The resulting
CipherData
element information item can then
be optimized because the content of such an element information
item is base64 characters.
In the future a transform algorithm for use with XML Encryption could provide a more efficient processing model where the raw octets are encrypted directly.
This appendix summarizes the XOP dependencies upon underlying
specifications, the nature of appropriate payloads for XOP and the
means of extending XOP.
XOP's
The XOP convention builds upon a number of underlying specifications. They are:
XML (e.g., [XML 1.0], [XML 1.1]) - The XOP Document is encoded using any W3C recommendation-level version of XML (see 3.1 Creating XOP Packages). Formats that use XOP MUST identify which versions of XML are permissible for encoding the XOP Infoset. XOP does not constrain the use of any mechanisms defined by XML, including those explicitly allowing extensions, nor does it constrain the use of underlying specifications.
Namespaces in XML (e.g., [Namespaces in XML], [Namespaces in XML 1.1]) - The XOP Document uses any W3C recommendation-level version of Namespaces in XML compatible with the version(s) of XML used. Formats that use XOP MUST identify which versions of Namespaces in XML are permissible for encoding the XOP Infoset. XOP does not constrain the use of any mechanisms defined by Namespaces in XML, including those explicitly allowing extensions, nor does it constrain the use of underlying specifications.
Uniform Resource Identifiers (see [RFC 2396]) - The XOP Document uses URIs to locate parts in the XOP Package (see 2.2 href attribute information item. XOP does not constrain the use of any mechanisms defined by URIs, including those explicitly allowing extensions, nor does it constrain the use of underlying specifications.
Packaging Mechanism - XOP requires the use of a packaging mechanism that satisfies the requirements in 4 XOP Packages. One such mechanism MUST be in use, but XOP does not require a specific mechanism. Formats using XOP MUST identify at least one such mechanism permissible for creating the XOP Package, and MUST specify how each allowed mechanism is to be used for building the XOP Package.
The relationship of one such mechanism to XOP, The MIME Multipart/Related Content-type, is specified in 4.1 MIME Multipart/Related XOP Packages.
The payload of a XOP Package is an XML Infoset. XOP constrains the
range of admissible characters in the payload to those contained in
the "Char" production of a W3C recommendation-level version of XML.
Additionally, the Original XML Infoset cannot contain an
element information item with a [local name] of of
Include
and a [namespace name] of
"http://www.w3.org/2004/08/xop/include". Finally,
portions of the payload which are nominated for optimization in XOP
MUST be base64-encoded data in the canonical lexical form of XML
Schema "http://www.w3.org/2003/12/xop/include".base64Binary
datatype (see [XML Schema Part 2] 3.2.16
base64Binary).
XOP Documents allow extensions to the xop:Include
element
when they do not change its semantics. Changes to the semantics MUST be
identified by a new namespace URI (i.e., they MUST define a new
formatInclude
element information item in another
namespace).
The extensibility of XOP'sthe specifications underlying XOP is not
constrained by their use in XOP.
underlying
This document along with [MTOM] and [SOAP Representation Header] has been produced in conjunction with the development of requirements embodied in the [SOAP Optimized Serialization Use Cases and Requirements] document.
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): David 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: Yasser 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.).
The people who have contributed to discussions on xml-dist-app@w3.org are also gratefully acknowledged.