Issue 464 (documentation of extensibility) proposal

This proposal partially fulfils my AI to suggest a means of documenting 
extensibility in XOP and MTOM; it concentrates on XOP. If, after 
discussion, we can agree on this or a suitable replacement, I'll extend 
it to include MTOM.

This is written as an Appendix to XOP; other editorial approaches may 
be more appropriate.

---8<---

A.x Relationships To and Constraints Upon Other Specifications

This appendix summarizes the dependencies upon XOP's underlying 
specifications, the nature of appropriate payloads for XOP, and the 
means of extending XOP.

A.x.1 Dependencies

This format builds upon a number of underlying specifications, whose 
use is required. They are;

* XML 1.0 - The XOP Document is encoded using XML 1.0; see section XXX. 
XOP does not constrain the use of extensions or underlying 
specifications in XML 1.0.

* Namespaces in XML - The XOP Document uses Namespaces in XML; see 
section XXX. XOP does not constrain the use of extensions or underlying 
specifications in Namespaces in XML.

* Uniform Resource Identifiers - The XOP Document uses URIs to locate 
parts in the XOP Package; see section XXX. XOP does not constrain the 
use of extensions or underlying specifications in URIs.

Additionally, some underlying functions might be performed by a number 
of specifications. They are;

* Packaging Mechanism - XOP requires the use of a packaging mechanism 
that sastisfies the requirements in Section XXX; one such mechanism 
must be in use, but XOP does not require a specific mechanism.

The relationship of one such mechanism to XOP, The MIME 
Multipart/Related Content-type, is specified in Section XXX.

A.x.2 Payload

The payload of a XOP Package is an XML Infoset. XOP constrains the 
range of permissable characters in the payload to those contained by 
the XML 1.0 "Char" production. Additionally, the Input Infoset cannot 
contain an element with a localname of "Include" and a namespace URI of 
"XXX". Finally, portions of the payload which are nominated for 
optimization in XOP must be legally and canonically base64-encoded. See 
section XXX for more information.

A.x.3 Extension

XOP Documents do not allow extension; changes to the format must be 
identified by a new namespace identifier.

The extensibility of XOP's underlying specifications is not constrained.

---8<---

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Tuesday, 9 March 2004 21:24:30 UTC