[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] An amendment to the proposal for issue 103
> The second point to note is that WSDL allows parts to be > based on type systems other than XML, for instance arbitrary > MIME content types. It is possible to have a part that > carries a JPEG image, and it is perfectly reasonable for a > BPEL process to assign the content of such a part from one > message variable to a corresponding part in another message > variable without ever concerning itself with the content > type. We assume that the process knows its message types and > will bind only XML parts into XPath expressions. Any > proposal that attempts to create an XML-based content model > for arbitrary WSDL 1.1 messages will run into trouble with > these issues. > > > > It may be argued that WSDL 2.0 has moved to a pure XML > infoset model for messages, as indeed it has. However, the > WSDL 2.0 WG has not provided a "migration story" for > rendering WSDL 1.1 messages in WSDL 2.0 infoset form, apart > from the fact that the BPEL TC has explicitly declined to > take a dependency on any WSDL 2.0 feature. It hardly seems > our place to provide an XML-based content model for WSDL 1.1 > messages when the WSDL 2.0 WG has not done so. > I think we should distinguish the data model used by WSDL from the data model used by BPEL for its variables. The data model defined by WSDL is limited exclusively to representation of messages *on* the wire. The data model for BPEL variables deals with messages taken *from* the wire and manipulated internally by the BPEL process. So, in my view, WSDL itself has nothing to say about the data model of BPEL variables, and we have to make our own rules there. In particular, I think it is completely legitimate for BPEL to adopt an infoset-based data model for its variables. From that perspective, a JPEG part is just an infoset EII corresponding to the Schema description provided in the WSDL abstract interface. The fact that the concrete representation of that EII is a JPEG binary image is just a matter of infoset serialization (a la MTOM). Ugo
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]