Re: Issue 464 (documentation of extensibility) proposal

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

Received on Thursday, 11 March 2004 16:56:31 UTC