W3C home > Mailing lists > Public > xmlp-comments@w3.org > January 2004

Re: Resolution for Issue 446

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 28 Jan 2004 11:32:24 -0500
To: "Martin Gudgin" <mgudgin@microsoft.com>
Cc: xmlp-comments@w3.org
Message-ID: <OF69938F77.708CD30D-ON85256E29.00597AAA@lotus.com>

First, I apologize for missing the call where this was discussed.  I have 
some doubts about the overall direction chosen, but I will happily defer 
to the will of the group in an area where anything we do involves 
compromises.  So, I accept the overall direction of outlawing xop:Include 
in the input.

That said, I don't think the proposed text is acceptable for at least two 
reasons, and so with regret I must indicate that for now the overall issue 
resolution is not acceptable to me.  The two reasons are:

1)  I think the use of the word "Note" in the phrase "Note that the data model used as input to XOP processing MUST
NOT contain any element nodes" is unfortunate, as it unnecessarily suggests informal advice.  I think 
we should avoid using "Note" and capitalized "MUST"/"MUST NOT" in the same 
sentence."  Suggested resplution:  delete the word "Note".

2) As I read the attached, it puts changes in XOP but not in the 
SOAP-specific portions of the spec.  I think that is unacceptable, 
especially since in this particular way we are proposing a (marginally) 
non-conforming SOAP binding, and one that has at least some security or 
integrity exposures if not implemented carefully.  In other words, if 
either your API or some inbound message at an intermediary allows a 
xop:include element to creep in and you fail to detect it, you can send 
erroneous data downstream.  Furthermore, nothing in the SOAP Rec licenses 
a binding that is incapable of transmitting more or less arbitrary 
elements within SOAP bodies or header element children.  I propose the 
following additional text to be included (with suitable editorial cleanup) 
into the HTTP binding:  "Implementations of this binding MUST enforce the 
restriction [link to XOP spec] that XOP not be used with data models that 
contain element nodes of name xop:include.  In any case where a SOAP 
envelope containing such a node is to be sent the binding MUST do one of 
the following:  a) fall back to use of the application/soap+xml media type 
or (b) reflect a binding-dependent SOAP fault.   Note that such envelopes 
could in principle arise either from data created locally at the sending 
node, or in data relayed at an intermediary, and bindings are responsible 
for checking all such input as necessary to ensure that the rule just 
stated is enforced. 

The first of these is an editorial matter that I am sure we can handle 
easily.  I propose that, if the chair is willing, we discuss the second on 
the call today.  Again, my apologies for being on the road at the Schema 
WG meeting during last week's call.

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








"Martin Gudgin" <mgudgin@microsoft.com>
Sent by: xmlp-comments-request@w3.org
01/26/2004 06:30 AM

 
        To:     <xmlp-comments@w3.org>
        cc:     <noah_mendelsohn@us.ibm.com>
        Subject:        Resolution for Issue 446



Noah,

You raised issue 446[1] regarding whether MIFFY/XOP can serialize a data
model that already contains xop:Include elements. The XMLP WG adopted
the following text into Section 3 of the XOP document:

                 Note that the data model used as input to XOP processing 
MUST
NOT contain any element nodes with a dm:node-name
{http://www.w3.org/2003/06/soap/features/binary-inclusion;Include};
data models containing such elements cannot              be serialized 
using XOP.

I trust the resolves the issue to your satisfaction.

Regards

Martin Gudgin
For the W3C XMLP WG

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x446
Received on Wednesday, 28 January 2004 11:33:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:08 UTC