Re: Issue 464 (documentation of extensibility) proposal

I meant only that the phrase "does not constrain the use of its defined mechanisms, including those 
explicitly allowing extension..."  seemed a bit clumsy taken out of context.    Let's try one in context:

XML 1.0 - The XOP Document is encoded using XML 1.0; see section XXX. XOP 
does not constrain the use of XML 1.1's defined mechanisms, including those explicitly allowing 
extension.

I think that's what you are proposing.  How about instead:

XML 1.0 - The XOP Document is encoded using XML 1.0; see section XXX. Except as specifically provided herein, XOP does not constrain the use of 
XML 1.0's features and mechanisms.

(I think we do constrain it in small ways, e.g. the use of particular 
values for the href="" attribute on the xop:include element).

What do you think?

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Mark Nottingham <mark.nottingham@bea.com>
03/11/2004 05:52 PM

 
        To:     noah_mendelsohn@us.ibm.com
        cc:     "'XMLP Dist App'" <xml-dist-app@w3.org>
        Subject:        Re: Issue 464 (documentation of extensibility) proposal


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 23:08:03 UTC