- From: Mark Nottingham <mark.nottingham@bea.com>
- Date: Thu, 11 Mar 2004 14:52:40 -0800
- To: noah_mendelsohn@us.ibm.com
- Cc: "'XMLP Dist App'" <xml-dist-app@w3.org>
OK, thanks. I'll noodle on it some more; I'd like it to be as tight as possible (really, the whole point of this section IMO). On Mar 11, 2004, at 1:55 PM, noah_mendelsohn@us.ibm.com wrote: > I think I raised the concern. Your proposal is fine with me (though I > suspect that with some effort we might make it a bit tighter, but I > don't > have any bright ideas to suggest just now.) All set as far as I'm > concerned. Thanks. > > -------------------------------------- > Noah Mendelsohn > IBM Corporation > One Rogers Street > Cambridge, MA 02142 > 1-617-693-4036 > -------------------------------------- > > > > > > > > > Mark Nottingham <mark.nottingham@bea.com> > Sent by: xml-dist-app-request@w3.org > 03/10/04 04:25 PM > > > To: "'XMLP Dist App'" <xml-dist-app@w3.org> > cc: (bcc: Noah Mendelsohn/Cambridge/IBM) > Subject: Re: Issue 464 (documentation of extensibility) > proposal > > > > On today's call, there was some concern expressed about the phrase > "does not constrain the use of extensions..." > > I'd propose that the phrase "does not constrain the use of its defined > mechanisms, including those explicitly allowing extension..." > > Does that address the concern? > > > On Mar 9, 2004, at 6:24 PM, Mark Nottingham wrote: > >> >> 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 >> >> > > -- > Mark Nottingham Principal Technologist > Office of the CTO BEA Systems > > > > > -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
Received on Thursday, 11 March 2004 17:52:46 UTC