W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2004

Re: Binding framework & XML Version / Infoset

From: <noah_mendelsohn@us.ibm.com>
Date: Sat, 24 Apr 2004 20:51:26 -0400
To: Yves Lafon <ylafon@w3.org>
Cc: xml-dist-app@w3.org
Message-ID: <OFFEAFACFB.2D119D9B-ON85256E81.000A19BF@lotus.com>

Yves Lafon writes:

> > This seems like a good solution at the receiver, but the question I 
was
> > raising related to a sender.  What do you do if:
> >
> > a) You are an original sender at a node that is in general XML 1.1
> > capable, but the particular link you are using employs the traditional
> > SOAP/HTTP binding.  The application prepares an infoset that is 
perfectly
> > legal SOAP, but you can't send it.  As far as we know, we have no 
error
> > for failure to prepare a media type when sending, only for failure to
> > accept one upon receipt.
> 
> This is between application layers, no need to define a SOAP specific
> binding, it has to be defined per application used (or per toolkit used)

It seems to me that the fact that a particular binding will or won't be 
able to handle XML 1.x, 2.x, etc. is a characteristic of the binding, 
except in the particular case that a particular binding allows lattitude 
to the implementation.  I'm not sure if it was accepted, but that is why 
the text that I proposed for the binding framework suggested that a 
binding-dependent, or perhaps binding-independent error be reflected.  I 
still think this is the more architecturally robust way to go.

> > b) You are an intermediary and the inbound message used 1.1 
constructs.
> > Again, it's your outbound link that can't handle the content.
> 
> The "unsupported media type" error applies in that
> case, as what has been received caused the intermediary
> node to fail to do its duty. Of course it is extending
> a bit the use of "unsupported media type" but that
> looks like the easiest way to handle the case without
> changing the REC.

I wonder whether minimizing changes to the recommendation here is the best 
long term solution?  As you suggest, relating this to the "media type" of 
the inbound stream seems a stretch, particularly since the inbound binding 
need not be based on a transport that uses media types at all.  Again,  I 
think the better solution is to do what I suggested in the proposed text 
for the binding framework, and to follow that framework in specifying some 
error for the HTTP binding in particular.  The fact that this is a small 
change to the rec. doesn't bother me, since until now we've never 
supported XML versions greater than 1.0, and the error cannot in any case 
occur unless someone tries to exploit the newly enabled capability for XML 
1.1 or higher.

Noah

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2004Apr/0012.html
--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Received on Saturday, 24 April 2004 22:08:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:16 GMT