John, I am trying understand all this myself, as I am starting to write the XMLTABLE blog. Yours is most advanced case in that! For some reason, this model of two procedures, that user need to execute is not sounding right to me. So, let me understand this correctly. User executes some thing like this right? select t* from (EXEC getRequestProcedure(...)) as in, (EXEC getResponse(in)) Please correct me, if understanding is wrong. thinking out loud - why not create response table based on the response XML using XMLTABLE and have access pattern on the all the scalar input? The one issue I see is input and output elements not matching. Ramesh.. On Mon, 2010-08-16 at 10:13 -0400, John Doyle wrote: > Hi guys, > > Last week I worked on changing the WSDL to source importer to work with the new system functions. I've attached a model project that contains a model for one operation of a WSDL in order to show the tact I've taken, and want to get some feedback from you. It's not complete yet, I need to add namespaces to the SQL, inputs/output for child element XML, etc, but wanted to get feedback on the overall concept. > > The importer will create one physical model for each endpoint defined in the WSLD, since each endpoint might need to be bound to a different URL. I intended this physical model to used across the generated views. > > The importer then creates a schema to contain views for each operation. I added the schemas to the model because operations often reuse the same type/element definitions across operations, but not necessarily with the same XPaths. Containing the views within schema allow me to create multiple views for any type/element with encountering naming clashes. > > The views are created by parsing the declaration of the request and response messages. A request message results in a procedure with scalar inputs that produces and XML result. A response message results in a procedure with XML in and scalar results. The procedures are not yet accounting for child elements for messages with hierarchy and multiplicity. > > Does this make sense, or did you have a different/better vision for how a user would model around the new language features? As it stands right now, I have been unable to create a procedure that executes a service with this structure. Could be my limited abilities with SQL, or that I've missed some limitation around our use of the XML type. I've tried passing the requests to the physical procedure and responses from the physical procedure using nested selects, and tried holding them in variables to pass them, without success. I typically end up with a validation error because I'm using a clob as a criteria. > > I appreciate any and all feedback. > > ~jd