Thread: PostgreSQL and SOAP, version 7.4/8.0

PostgreSQL and SOAP, version 7.4/8.0

From
mlw
Date:
I have been working on moving some of my software to a more SOAP 
compatible interface. As I was doing it, it occured to me that a generic 
function could be written, in PostgreSQL's new function manager that 
allows multiple columns to be returned, that is a generic SOAP interface.

All one would need do is define what is expected from the SOAP call in 
the "CREATE FUNCTION" statement. Then the generic SOAP function could 
then read what is expected and return the XML/SOAP data as a set of 
results as if it were a subquery.

What is needed is an efficient way to find the data types and names from 
the functions definition. Does anyone know how to do that?

A small program could also parse a WSDL file and write a "CREATE 
FUNCTION" script for the XML as well.

On the flip side, I am also working on a PostgreSQL SOAP interface, 
where one does this:

http://somehost/postgresql?query="select * from table"

And a SOAP compatible resultset is returned.

On a more advanced horizon, one should be able to do this:

select * from localtable, 
mysoap('http://remotehost/postgresql?query=select * from foo') as soap 
where soap.field = localtable.field;

If we can do that, PostgreSQL could fit into almost ANY service 
environment. What do you guys think? Anyone want to help out?



Re: PostgreSQL and SOAP, version 7.4/8.0

From
"Jason M. Felice"
Date:
First, a SOAP query should be posted in SOAP message format, not using the
query string as you do.  Second, I like the idea of calling external SOAP
services, but consider creating a language 'soap' you could do with a CREATE
FUNCTION type thing. e.g.

CREATE FUNCTION "foo" (TEXT) RETURNS INTEGER AS'http://somewhere.com/path/to/.wsdl', 'foo'LANGUAGE 'soap';

(hmm, it is unclear if this is what you are suggesting or not...)

Second, I hate SOAP because it is too bloated (have you read the spec(s)?).
If you can support xmlrpc instead, you'll save yourself a lot of headaches.
If you got SOAP working, though, I'd use it.  It's more an implementation
thing.


On Fri, Mar 28, 2003 at 09:01:08AM -0500, mlw wrote:
> I have been working on moving some of my software to a more SOAP 
> compatible interface. As I was doing it, it occured to me that a generic 
> function could be written, in PostgreSQL's new function manager that 
> allows multiple columns to be returned, that is a generic SOAP interface.
> 
> All one would need do is define what is expected from the SOAP call in 
> the "CREATE FUNCTION" statement. Then the generic SOAP function could 
> then read what is expected and return the XML/SOAP data as a set of 
> results as if it were a subquery.
> 
> What is needed is an efficient way to find the data types and names from 
> the functions definition. Does anyone know how to do that?
> 
> A small program could also parse a WSDL file and write a "CREATE 
> FUNCTION" script for the XML as well.
> 
> On the flip side, I am also working on a PostgreSQL SOAP interface, 
> where one does this:
> 
> http://somehost/postgresql?query="select * from table"
> 
> And a SOAP compatible resultset is returned.
> 
> On a more advanced horizon, one should be able to do this:
> 
> select * from localtable, 
> mysoap('http://remotehost/postgresql?query=select * from foo') as soap 
> where soap.field = localtable.field;
> 
> If we can do that, PostgreSQL could fit into almost ANY service 
> environment. What do you guys think? Anyone want to help out?
> 

I have no time to volunteer for projects, but what the hell...!  It's too
cool.  I can't spend much time on it but bounce things off me and I'll
do whatever hacking I can squeeze in.  What soap implementation would you
use for the PostgreSQL plugin?  libsoap, last I checked, is a wee bit 
out of date.  And not documented.

-Jason



Re: PostgreSQL and SOAP, version 7.4/8.0

From
cbbrowne@cbbrowne.com
Date:
Jason wrote:
> If you can support xmlrpc instead, you'll save yourself a lot of headaches.

XML-RPC has three merits over SOAP:
1.  It's a simple specification, and thus readily implemented.
2.  Microsoft and IBM aren't fighting over control over it, so it's    not suffering from the "we keep adding
pseudo-standardsto it"    problem.  (Which further complicates the specifications.)    You can have a /complete/
implementationof XML-RPC, whereas,    for SOAP, you can hold ghastly long arguments as to what SOAP    means, anyways.
 
3.  There's a (perhaps not "standard", but definitely widely    implemented) scheme for bundling multiple XML-RPC
requestsinto    one message, which improves latency a LOT for small messages.
 

Of course, CORBA has actually been quite formally standardized, suffers
from many fairly interoperable implementations, and is rather a lot less
bloated than any of the XML-based schemes.  It might be worth trying,
too...
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://cbbrowne.com/info/soap.html
I just got skylights put in my place. The people who live above me are
furious.



Re: PostgreSQL and SOAP, version 7.4/8.0

From
"Jason M. Felice"
Date:
On Fri, Mar 28, 2003 at 01:36:43PM -0500, cbbrowne@cbbrowne.com wrote:
> Of course, CORBA has actually been quite formally standardized, suffers
> from many fairly interoperable implementations, and is rather a lot less
> bloated than any of the XML-based schemes.  It might be worth trying,
> too...

The ability to use the HTTP transport has it's advantages with web services--
You can throw something together with a few lines of PHP, you don't have to
worry about how to activate objects, I've never been able to figure out how
to handle transport-layer security and authentication with CORBA (of course,
this was all fairly new stuff when I was working with it), all this stuff
comes for free with the HTTP transport.

I like CORBA, though, and I'd probably find a CORBA module useful, but it
doesn't solve all the same problems.

Hrm, I wonder if the overhead of XML-RPC wouldn't be too bad for the new
PostgreSQL protocol... it probably would, but it would be entirely useful.
You can make XML-RPC calls from mozilla javascript, so you could do some
pretty sweet tweaking to keep your addresses in a pgsql database.

As an "additional" protocol which postmaster can listen to it would rule.
I'm making a habit of putting all the business logic into stored procedures,
and this would basically publish the business logic in a very useful way.

-Jason



Re: PostgreSQL and SOAP, version 7.4/8.0

From
mlw
Date:
<br /><br /> Jason M. Felice wrote:<br /><blockquote cite="mid20030328171757.GD2018@argo.eraserhead.net"
type="cite"><prewrap="">First, a SOAP query should be posted in SOAP message format, not using the
 
query string as you do.  Second, I like the idea of calling external SOAP
services, but consider creating a language 'soap' you could do with a CREATE
FUNCTION type thing. e.g.

CREATE FUNCTION "foo" (TEXT) RETURNS INTEGER AS'<a class="moz-txt-link-freetext"
href="http://somewhere.com/path/to/.wsdl">http://somewhere.com/path/to/.wsdl</a>','foo'LANGUAGE 'soap';
 

(hmm, it is unclear if this is what you are suggesting or not...)

Second, I hate SOAP because it is too bloated (have you read the spec(s)?).
If you can support xmlrpc instead, you'll save yourself a lot of headaches.
If you got SOAP working, though, I'd use it.  It's more an implementation
thing.</pre></blockquote><br /> Here's the thing, yes I know there are a "lot" of alternatives to SOAP, all with
varyinglevels of "being better than SOAP." It still stands that a SOAP interface would be useful for people.<br /><br
/><blockquotecite="mid20030328171757.GD2018@argo.eraserhead.net" type="cite"><pre wrap="">
 


On Fri, Mar 28, 2003 at 09:01:08AM -0500, mlw wrote: </pre><blockquote type="cite"><pre wrap="">I have been working on
movingsome of my software to a more SOAP 
 
compatible interface. As I was doing it, it occured to me that a generic 
function could be written, in PostgreSQL's new function manager that 
allows multiple columns to be returned, that is a generic SOAP interface.

All one would need do is define what is expected from the SOAP call in 
the "CREATE FUNCTION" statement. Then the generic SOAP function could 
then read what is expected and return the XML/SOAP data as a set of 
results as if it were a subquery.

What is needed is an efficient way to find the data types and names from 
the functions definition. Does anyone know how to do that?

A small program could also parse a WSDL file and write a "CREATE 
FUNCTION" script for the XML as well.

On the flip side, I am also working on a PostgreSQL SOAP interface, 
where one does this:

<a class="moz-txt-link-freetext" href="http://somehost/postgresql?query=">http://somehost/postgresql?query=</a>"select
*from table"
 

And a SOAP compatible resultset is returned.

On a more advanced horizon, one should be able to do this:

select * from localtable, 
mysoap('<a class="moz-txt-link-freetext"
href="http://remotehost/postgresql?query=select">http://remotehost/postgresql?query=select</a>* from foo') as soap 
 
where soap.field = localtable.field;

If we can do that, PostgreSQL could fit into almost ANY service 
environment. What do you guys think? Anyone want to help out?
   </pre></blockquote><pre wrap="">
I have no time to volunteer for projects, but what the hell...!  It's too
cool.  I can't spend much time on it but bounce things off me and I'll
do whatever hacking I can squeeze in.  What soap implementation would you
use for the PostgreSQL plugin?  libsoap, last I checked, is a wee bit 
out of date.  And not documented.</pre></blockquote><br /> I was thinking of using SOAP over HTTP as the protocol, and
aminimalist version at best. If the people want "more" let them add it.<br /><br /> I have an HTTP service class in my
opensource library. It would br trivial to accept a SQL query formatted as a GET request, and then execute the query
and,using libpq, format the result as XML. It should be simple enough to do. <br /><blockquote
cite="mid20030328171757.GD2018@argo.eraserhead.net"type="cite"><pre wrap="">
 

-Jason


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to <a class="moz-txt-link-abbreviated"
href="mailto:majordomo@postgresql.org">majordomo@postgresql.org</a>
 </pre></blockquote><br />

Re: PostgreSQL and SOAP, version 7.4/8.0

From
Steve Wampler
Date:
On Fri, 2003-03-28 at 14:39, mlw wrote:

> I was thinking of using SOAP over HTTP as the protocol, and a
> minimalist version at best. If the people want "more" let them add it.
> 
> I have an HTTP service class in my open source library. It would br
> trivial to accept a SQL query formatted as a GET request, and then
> execute the query and, using libpq, format the result as XML. It
> should be simple enough to do. 

It would be easy.  I've done something similar (using ODBC to
get to PostgreSQL) - but using a language none of the rest of
you are likely to be interested in (Unicon).  Works just fine,
though the implementation (deliberately, by personal preference)
avoids accepting arbitrary SQL statements from SOAP clients,
instead forcing the clients to use an RPC interface so I can
do sanity checking in the Unicon [which I know better than I know
PostgreSQL...] SOAP servers.

I, too, opted for a 'minimal-SOAP' implementation.  A 'real'
implementation boggles the mind.

-- 
Steve Wampler <swampler@noao.edu>
National Solar Observatory



Re: PostgreSQL and SOAP, version 7.4/8.0

From
Peter Eisentraut
Date:
mlw writes:

> On the flip side, I am also working on a PostgreSQL SOAP interface,
> where one does this:
>
> http://somehost/postgresql?query="select * from table"
>
> And a SOAP compatible resultset is returned.

That looks quite similar to the planned XML functionality.  While that
plan doesn't contain the word "SOAP", one could of course create a small
layer to convert the output format to any other XML format.  If you're
interested, please look up the XML discussion of the last few weeks.

-- 
Peter Eisentraut   peter_e@gmx.net



Re: PostgreSQL and SOAP, suggestions?

From
mlw
Date:
Given a HTTP formatted query:
GET "http://localhost:8181/pgmuze?query=select+*+from+zsong+limit+2"

The output is entered below.

Questions:
Is there a way, without spcifying a binary cursor, to get the data types 
associated with columns? Right now I am just using undefined, as the 
ODBC version works.

Anyone see any basic improvements needed?

<?xml version = "1.0"?>
<soap:Envelope xmlns:MWSSQL="http://www.mohawksoft.com/MWSSQL/envelope"><soap:Header> <!-- Fields in set --> <Columns
count="9"> <muzenbr>undefined</muzenbr>  <disc>undefined</disc>  <trk>undefined</trk>  <song>undefined</song>
<artistid>undefined</artistid> <acd>undefined</acd>  <trackid>undefined</trackid>  <datasrc>undefined</datasrc>
<extid>undefined</extid></Columns></soap:Header><soap:Body> <ROWSET columns="9" rows="2">  <ROW ROWID="0">
<muzenbr>424965</muzenbr>  <disc>1</disc>   <trk>5</trk>   <song>Write My Name In The Groove</song>
<artistid>100021391</artistid>  <acd>A</acd>   <trackid>203429573</trackid>   <datasrc>1</datasrc>
<extid>203429573</extid> </ROW>  <ROW ROWID="1">   <muzenbr>177516</muzenbr>   <disc>1</disc>   <trk>1</trk>
<song>PapaWas A Rolling Stone</song>   <artistid>100000411</artistid>   <acd>P</acd>   <trackid>200000000</trackid>
<datasrc>1</datasrc>  <extid>200000000</extid>  </ROW> </ROWSET></soap:Body>
 
</soap:Envelope>


Steve Wampler wrote:

>On Fri, 2003-03-28 at 14:39, mlw wrote:
>
>  
>
>>I was thinking of using SOAP over HTTP as the protocol, and a
>>minimalist version at best. If the people want "more" let them add it.
>>
>>I have an HTTP service class in my open source library. It would br
>>trivial to accept a SQL query formatted as a GET request, and then
>>execute the query and, using libpq, format the result as XML. It
>>should be simple enough to do. 
>>    
>>
>
>It would be easy.  I've done something similar (using ODBC to
>get to PostgreSQL) - but using a language none of the rest of
>you are likely to be interested in (Unicon).  Works just fine,
>though the implementation (deliberately, by personal preference)
>avoids accepting arbitrary SQL statements from SOAP clients,
>instead forcing the clients to use an RPC interface so I can
>do sanity checking in the Unicon [which I know better than I know
>PostgreSQL...] SOAP servers.
>
>I, too, opted for a 'minimal-SOAP' implementation.  A 'real'
>implementation boggles the mind.
>
>  
>



Re: PostgreSQL and SOAP, suggestions?

From
Hannu Krosing
Date:
mlw kirjutas E, 31.03.2003 kell 03:43:
> Given a HTTP formatted query:
> GET "http://localhost:8181/pgmuze?query=select+*+from+zsong+limit+2"
> 
> The output is entered below.
> 
> Questions:
> Is there a way, without spcifying a binary cursor, to get the data types 
> associated with columns? Right now I am just using undefined, as the 
> ODBC version works.
> 
> Anyone see any basic improvements needed?
> 
> <?xml version = "1.0"?>
> <soap:Envelope xmlns:MWSSQL="http://www.mohawksoft.com/MWSSQL/envelope">
>  <soap:Header>
>   <!-- Fields in set -->
>   <Columns count="9">

The SOAP 1.1 spec specifies (p4.2) the following about SOAP Header:

The encoding rules for header entries are as follows: 
    1. A header entry is identified by its fully qualified element       name, which consists of the namespace URI and
thelocal name.       All immediate child elements of the SOAP Header element MUST be       namespace-qualified. 
 

I'm not sure that SOAP Header is the right place for Query header info,
as the header is meant for:

 SOAP provides a flexible mechanism for extending a message in a  decentralized and modular way without prior knowledge
betweenthe  communicating parties. Typical examples of extensions that can be  implemented as header entries are
authentication,transaction  management, payment etc.
 

So the definition of structure should probably be inside SOAP:Body .

---------------
Hannu



Re: PostgreSQL and SOAP, suggestions?

From
pgsql@mohawksoft.com
Date:
Actually, as far as I am aware, the header is for metadata, i.e. it is the
place to describe the data being returned. The description of the fields
isn't the actual data retrieved, so it doesn't belong in the body, so it
should go into the header.



> mlw kirjutas E, 31.03.2003 kell 03:43:
>> Given a HTTP formatted query:
>> GET "http://localhost:8181/pgmuze?query=select+*+from+zsong+limit+2"
>>
>> The output is entered below.
>>
>> Questions:
>> Is there a way, without spcifying a binary cursor, to get the data
>> types  associated with columns? Right now I am just using undefined,
>> as the  ODBC version works.
>>
>> Anyone see any basic improvements needed?
>>
>> <?xml version = "1.0"?>
>> <soap:Envelope
>> xmlns:MWSSQL="http://www.mohawksoft.com/MWSSQL/envelope">
>>  <soap:Header>
>>   <!-- Fields in set -->
>>   <Columns count="9">
>
> The SOAP 1.1 spec specifies (p4.2) the following about SOAP Header:
>
> The encoding rules for header entries are as follows:
>
>      1. A header entry is identified by its fully qualified element
>         name, which consists of the namespace URI and the local name.
>         All immediate child elements of the SOAP Header element MUST be
>         namespace-qualified.
>
> I'm not sure that SOAP Header is the right place for Query header info,
> as the header is meant for:
>
>
>   SOAP provides a flexible mechanism for extending a message in a
>   decentralized and modular way without prior knowledge between the
>   communicating parties. Typical examples of extensions that can be
>   implemented as header entries are authentication, transaction
>   management, payment etc.
>
> So the definition of structure should probably be inside SOAP:Body .
>
> ---------------
> Hannu
>
>
> ---------------------------(end of
> broadcast)--------------------------- TIP 5: Have you checked our
> extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html



Re: PostgreSQL and SOAP, suggestions?

From
Hannu Krosing
Date:
pgsql@mohawksoft.com kirjutas E, 31.03.2003 kell 19:52:
> Actually, as far as I am aware, the header is for metadata, i.e. it is the
> place to describe the data being returned.

Did you read the SOAP spec ?

> The description of the fields
> isn't the actual data retrieved, so it doesn't belong in the body, so it
> should go into the header.

That is logical, but this is not what the spec tells.

Also the spec requires immediate child elements of SOAP:Header to have
full namespace URI's.

And another question - why do you have the namespace MWSSQL defined but
never used ?

-------------
Hannu



Re: PostgreSQL and SOAP, suggestions?

From
mlw
Date:

Hannu Krosing wrote:

>pgsql@mohawksoft.com kirjutas E, 31.03.2003 kell 19:52:
>  
>
>>Actually, as far as I am aware, the header is for metadata, i.e. it is the
>>place to describe the data being returned.
>>    
>>
>
>Did you read the SOAP spec ?
>
yes

>
>  
>
>>The description of the fields
>>isn't the actual data retrieved, so it doesn't belong in the body, so it
>>should go into the header.
>>    
>>
>
>That is logical, but this is not what the spec tells.
>
This is exactly what the spec calles for. The spec, at least 1.1, says 
very little about what should not be in the header. For an XML request, 
it should carry. It is very particular about soap header attributes, but 
header contents is very flexable.

>
>Also the spec requires immediate child elements of SOAP:Header to have
>full namespace URI's.
>
Yup, that was a bug.

>
>And another question - why do you have the namespace MWSSQL defined but
>never used ?
>
That was part of the same bug as above, it now outputs this:

<?xml version = "1.0"?>
<mwssql:Envelope xmlns:mwssql="http://www.mohawksoft.com/mwssql/envelope"><mwssql:Header> <exec:sql>update cgrpairs set
ratio=0where srcitem=100098670</exec:sql> <exec:affected>2657</exec:affected> <qry:sql>select * from ztitles limit
2</qry:sql><qry:ROWSET>  <qry:ROW columns="28">   <t:acd>undefined</t:acd>   <t:muzenbr>undefined</t:muzenbr>
<t:cat2>undefined</t:cat2>  <t:cat3>undefined</t:cat3>   <t:cat4>undefined</t:cat4>
<t:performer>undefined</t:performer>  <t:performer2>undefined</t:performer2>   <t:title>undefined</t:title>
<t:artist1>undefined</t:artist1>  <t:engineer>undefined</t:engineer>   <t:producer>undefined</t:producer>
<t:labelname>undefined</t:labelname>  <t:catalog>undefined</t:catalog>   <t:distribut>undefined</t:distribut>
<t:released>undefined</t:released>  <t:origrel>undefined</t:origrel>   <t:nbrdiscs>undefined</t:nbrdiscs>
<t:spar>undefined</t:spar>  <t:minutes>undefined</t:minutes>   <t:seconds>undefined</t:seconds>
<t:monostereo>undefined</t:monostereo>  <t:studiolive>undefined</t:studiolive>   <t:available>undefined</t:available>
<t:previews>undefined</t:previews>  <t:pnotes>undefined</t:pnotes>   <t:artistid>undefined</t:artistid>
<t:datasrc>undefined</t:datasrc>  <t:extid>undefined</t:extid>  </qry:ROW> </qry:ROWSET></mwssql:Header><mwssql:Body>
<ROWSETcolumns="28" rows="2">  <ROW ROWID="0">   <acd>P</acd>   <muzenbr>68291</muzenbr>   <cat2>Performer</cat2>
<cat3>JazzInstrument</cat3>   <cat4>Guitar</cat4>   <performer>Steve Khan</performer>   <performer2>Khan,
Steve</performer2>  <title>Evidence</title>   <artist1></artist1>   <engineer></engineer>   <producer></producer>
<labelname>Novus</labelname>  <catalog>3074</catalog>   <distribut>BMG</distribut>   <released>02/13/1990</released>
<origrel>n/a</origrel>  <nbrdiscs>1</nbrdiscs>   <spar>n/a</spar>   <minutes></minutes>   <seconds></seconds>
<monostereo>Stereo</monostereo>  <studiolive>Studio</studiolive>   <available>N</available>   <previews></previews>
<pnotes></pnotes>  <artistid>100025343</artistid>   <datasrc>1</datasrc>   <extid>68291</extid>  </ROW>  <ROW
ROWID="1">  <acd>P</acd>   <muzenbr>67655</muzenbr>   <cat2>Collection</cat2>   <cat3>Jazz Instrument</cat3>
<cat4></cat4>  <performer>Various Artists</performer>   <performer2>Various Artists</performer2>   <title>Metropolitan
OperaHouse Jam Session</title>   <artist1></artist1>   <engineer></engineer>   <producer></producer>   <labelname>Jazz
Anthology</labelname>  <catalog>550212</catalog>   <distribut>n/a</distribut>   <released>1992</released>
<origrel>n/a</origrel>  <nbrdiscs>1</nbrdiscs>   <spar>n/a</spar>   <minutes></minutes>   <seconds></seconds>
<monostereo>Mono</monostereo>  <studiolive>Live</studiolive>   <available>N</available>   <previews></previews>
<pnotes></pnotes>  <artistid>100050450</artistid>   <datasrc>1</datasrc>   <extid>67655</extid>  </ROW>
</ROWSET></mwssql:Body>
</mwssql:Envelope>



Re: PostgreSQL and SOAP, suggestions?

From
Steve Wampler
Date:
Out of curiousity, what is the purpose of putting the qry:ROWSET
description into the message at all (header or not)?  Isn't it a
perfectly valid SOAP message (and just as parseable) with that removed?

I freely admit to not being a soap expert, but similar SOAP
messages I generate from queries seem to work fine without this
metadata.  Is having it required by some part of the SOAP spec
I don't understand?

Thanks!

On Tue, 2003-04-01 at 05:29, mlw wrote:

> That was part of the same bug as above, it now outputs this:
> 
> <?xml version = "1.0"?>
> <mwssql:Envelope xmlns:mwssql="http://www.mohawksoft.com/mwssql/envelope">
>  <mwssql:Header>
>   <exec:sql>update cgrpairs set ratio=0 where srcitem=100098670</exec:sql>
>   <exec:affected>2657</exec:affected>
>   <qry:sql>select * from ztitles limit 2</qry:sql>
>   <qry:ROWSET>
>    <qry:ROW columns="28">
>     <t:acd>undefined</t:acd>
>     <t:muzenbr>undefined</t:muzenbr>
>     <t:cat2>undefined</t:cat2>
>     <t:cat3>undefined</t:cat3>
>     <t:cat4>undefined</t:cat4>
>     <t:performer>undefined</t:performer>
>     <t:performer2>undefined</t:performer2>
>     <t:title>undefined</t:title>
>     <t:artist1>undefined</t:artist1>
>     <t:engineer>undefined</t:engineer>
>     <t:producer>undefined</t:producer>
>     <t:labelname>undefined</t:labelname>
>     <t:catalog>undefined</t:catalog>
>     <t:distribut>undefined</t:distribut>
>     <t:released>undefined</t:released>
>     <t:origrel>undefined</t:origrel>
>     <t:nbrdiscs>undefined</t:nbrdiscs>
>     <t:spar>undefined</t:spar>
>     <t:minutes>undefined</t:minutes>
>     <t:seconds>undefined</t:seconds>
>     <t:monostereo>undefined</t:monostereo>
>     <t:studiolive>undefined</t:studiolive>
>     <t:available>undefined</t:available>
>     <t:previews>undefined</t:previews>
>     <t:pnotes>undefined</t:pnotes>
>     <t:artistid>undefined</t:artistid>
>     <t:datasrc>undefined</t:datasrc>
>     <t:extid>undefined</t:extid>
>    </qry:ROW>
>   </qry:ROWSET>
>  </mwssql:Header>
>  <mwssql:Body>
>   <ROWSET columns="28" rows="2">
>    <ROW ROWID="0">
>     <acd>P</acd>
>     <muzenbr>68291</muzenbr>
>     <cat2>Performer</cat2>
>     <cat3>Jazz Instrument</cat3>
>     <cat4>Guitar</cat4>
>     <performer>Steve Khan</performer>
>     <performer2>Khan, Steve</performer2>
>     <title>Evidence</title>
>     <artist1></artist1>
>     <engineer></engineer>
>     <producer></producer>
>     <labelname>Novus</labelname>
>     <catalog>3074</catalog>
>     <distribut>BMG</distribut>
>     <released>02/13/1990</released>
>     <origrel>n/a</origrel>
>     <nbrdiscs>1</nbrdiscs>
>     <spar>n/a</spar>
>     <minutes></minutes>
>     <seconds></seconds>
>     <monostereo>Stereo</monostereo>
>     <studiolive>Studio</studiolive>
>     <available>N</available>
>     <previews></previews>
>     <pnotes></pnotes>
>     <artistid>100025343</artistid>
>     <datasrc>1</datasrc>
>     <extid>68291</extid>
>    </ROW>
>    <ROW ROWID="1">
>     <acd>P</acd>
>     <muzenbr>67655</muzenbr>
>     <cat2>Collection</cat2>
>     <cat3>Jazz Instrument</cat3>
>     <cat4></cat4>
>     <performer>Various Artists</performer>
>     <performer2>Various Artists</performer2>
>     <title>Metropolitan Opera House Jam Session</title>
>     <artist1></artist1>
>     <engineer></engineer>
>     <producer></producer>
>     <labelname>Jazz Anthology</labelname>
>     <catalog>550212</catalog>
>     <distribut>n/a</distribut>
>     <released>1992</released>
>     <origrel>n/a</origrel>
>     <nbrdiscs>1</nbrdiscs>
>     <spar>n/a</spar>
>     <minutes></minutes>
>     <seconds></seconds>
>     <monostereo>Mono</monostereo>
>     <studiolive>Live</studiolive>
>     <available>N</available>
>     <previews></previews>
>     <pnotes></pnotes>
>     <artistid>100050450</artistid>
>     <datasrc>1</datasrc>
>     <extid>67655</extid>
>    </ROW>
>   </ROWSET>
>  </mwssql:Body>
> </mwssql:Envelope>
-- 
Steve Wampler <swampler@noao.edu>
National Solar Observatory



Re: PostgreSQL and SOAP, suggestions?

From
"Andrew Dunstan"
Date:
I can certainly imagine cases for processing where having the field names
and other metadata up front (maybe add type info, nullable, etc instead of
just "undefined") would be useful.

here's another question:

If the intention is to use field names as (local) tag names, how will you
handle the case where the field name isn't a valid XML name? Of course, one
could do some sort of mapping (replace illegal chars with "_", for example)
but then you can't be 100% certain that you haven't generated a collision,
I should think.

andrew

----- Original Message -----
From: "Steve Wampler" <swampler@noao.edu>
To: "mlw" <pgsql@mohawksoft.com>
Cc: "Hannu Krosing" <hannu@tm.ee>; <jfelice@cronosys.com>;
"Postgres-hackers" <pgsql-hackers@postgresql.org>
Sent: Tuesday, April 01, 2003 12:40 PM
Subject: Re: [HACKERS] PostgreSQL and SOAP, suggestions?


> Out of curiousity, what is the purpose of putting the qry:ROWSET
> description into the message at all (header or not)?  Isn't it a
> perfectly valid SOAP message (and just as parseable) with that removed?
>
> I freely admit to not being a soap expert, but similar SOAP
> messages I generate from queries seem to work fine without this
> metadata.  Is having it required by some part of the SOAP spec
> I don't understand?
>
> Thanks!
>
> On Tue, 2003-04-01 at 05:29, mlw wrote:
>
> > That was part of the same bug as above, it now outputs this:
> >
> > <?xml version = "1.0"?>
> > <mwssql:Envelope
xmlns:mwssql="http://www.mohawksoft.com/mwssql/envelope">
> >  <mwssql:Header>
> >   <exec:sql>update cgrpairs set ratio=0 where
srcitem=100098670</exec:sql>
> >   <exec:affected>2657</exec:affected>
> >   <qry:sql>select * from ztitles limit 2</qry:sql>
> >   <qry:ROWSET>
> >    <qry:ROW columns="28">
> >     <t:acd>undefined</t:acd>
> >     <t:muzenbr>undefined</t:muzenbr>
> >     <t:cat2>undefined</t:cat2>
> >     <t:cat3>undefined</t:cat3>
> >     <t:cat4>undefined</t:cat4>
> >     <t:performer>undefined</t:performer>
> >     <t:performer2>undefined</t:performer2>
> >     <t:title>undefined</t:title>
> >     <t:artist1>undefined</t:artist1>
> >     <t:engineer>undefined</t:engineer>
> >     <t:producer>undefined</t:producer>
> >     <t:labelname>undefined</t:labelname>
> >     <t:catalog>undefined</t:catalog>
> >     <t:distribut>undefined</t:distribut>
> >     <t:released>undefined</t:released>
> >     <t:origrel>undefined</t:origrel>
> >     <t:nbrdiscs>undefined</t:nbrdiscs>
> >     <t:spar>undefined</t:spar>
> >     <t:minutes>undefined</t:minutes>
> >     <t:seconds>undefined</t:seconds>
> >     <t:monostereo>undefined</t:monostereo>
> >     <t:studiolive>undefined</t:studiolive>
> >     <t:available>undefined</t:available>
> >     <t:previews>undefined</t:previews>
> >     <t:pnotes>undefined</t:pnotes>
> >     <t:artistid>undefined</t:artistid>
> >     <t:datasrc>undefined</t:datasrc>
> >     <t:extid>undefined</t:extid>
> >    </qry:ROW>
> >   </qry:ROWSET>
> >  </mwssql:Header>
> >  <mwssql:Body>
> >   <ROWSET columns="28" rows="2">
> >    <ROW ROWID="0">
> >     <acd>P</acd>
> >     <muzenbr>68291</muzenbr>
> >     <cat2>Performer</cat2>
> >     <cat3>Jazz Instrument</cat3>
> >     <cat4>Guitar</cat4>
> >     <performer>Steve Khan</performer>
> >     <performer2>Khan, Steve</performer2>
> >     <title>Evidence</title>
> >     <artist1></artist1>
> >     <engineer></engineer>
> >     <producer></producer>
> >     <labelname>Novus</labelname>
> >     <catalog>3074</catalog>
> >     <distribut>BMG</distribut>
> >     <released>02/13/1990</released>
> >     <origrel>n/a</origrel>
> >     <nbrdiscs>1</nbrdiscs>
> >     <spar>n/a</spar>
> >     <minutes></minutes>
> >     <seconds></seconds>
> >     <monostereo>Stereo</monostereo>
> >     <studiolive>Studio</studiolive>
> >     <available>N</available>
> >     <previews></previews>
> >     <pnotes></pnotes>
> >     <artistid>100025343</artistid>
> >     <datasrc>1</datasrc>
> >     <extid>68291</extid>
> >    </ROW>
> >    <ROW ROWID="1">
> >     <acd>P</acd>
> >     <muzenbr>67655</muzenbr>
> >     <cat2>Collection</cat2>
> >     <cat3>Jazz Instrument</cat3>
> >     <cat4></cat4>
> >     <performer>Various Artists</performer>
> >     <performer2>Various Artists</performer2>
> >     <title>Metropolitan Opera House Jam Session</title>
> >     <artist1></artist1>
> >     <engineer></engineer>
> >     <producer></producer>
> >     <labelname>Jazz Anthology</labelname>
> >     <catalog>550212</catalog>
> >     <distribut>n/a</distribut>
> >     <released>1992</released>
> >     <origrel>n/a</origrel>
> >     <nbrdiscs>1</nbrdiscs>
> >     <spar>n/a</spar>
> >     <minutes></minutes>
> >     <seconds></seconds>
> >     <monostereo>Mono</monostereo>
> >     <studiolive>Live</studiolive>
> >     <available>N</available>
> >     <previews></previews>
> >     <pnotes></pnotes>
> >     <artistid>100050450</artistid>
> >     <datasrc>1</datasrc>
> >     <extid>67655</extid>
> >    </ROW>
> >   </ROWSET>
> >  </mwssql:Body>
> > </mwssql:Envelope>
> --



Re: PostgreSQL and SOAP, suggestions?

From
pgsql@mohawksoft.com
Date:
>
> I can certainly imagine cases for processing where having the field
> names and other metadata up front (maybe add type info, nullable, etc
> instead of just "undefined") would be useful.
>
> here's another question:
>
> If the intention is to use field names as (local) tag names, how will
> you handle the case where the field name isn't a valid XML name? Of
> course, one could do some sort of mapping (replace illegal chars with
> "_", for example) but then you can't be 100% certain that you haven't
> generated a collision, I should think.
>

I'm not sure, I have to really research how to handle that case. I have been
simply doing a %hex translation on characters that do not conform to XML,
that may actually be "good enough(tm)."

As for the field names being undefined, if you can find a way to get the
field types without having to specify a binary cursor I'd like that.
Admitedly, I have not looked very hard. This is a small part of a bigger
project. The SQL/XML provider currently supports PG and ODBC.

The web services project, which contains the SQL/XML provider, has a bunch
of other services.



Re: PostgreSQL and SOAP, suggestions?

From
Peter Eisentraut
Date:
mlw writes:

> Given a HTTP formatted query:
> GET "http://localhost:8181/pgmuze?query=select+*+from+zsong+limit+2"
>
> The output is entered below.

That looks a lot like the SQL/XML-style output plus a SOAP header.  Below
is the output that I get from the SQL/XML function that I wrote.  A simple
XSLT stylesheet should do the trick for you.

Btw., I also have an XSLT stylesheet that can make an HTML table out of
this output and I have a table function that can generate a virtual table
from this output.


=> select table2xml('select * from products');

<?xml version='1.0'?>
<table   xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'   xsi:noNamespaceSchemaLocation='#'> <!-- XXX this needs
tobe fixed -->
 

<xsd:schema   xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:sqlxml='http://www.iso-standards.org/mra/9075/2001/12/sqlxml'>
 <xsd:import     namespace='http://www.iso-standards.org/mra/9075/2001/12/sqlxml'
schemaLocation='http://www.iso-standards.org/mra/9075/2001/12/sqlxml.xsd'/>
 

<xsd:simpleType name='peter.pg_catalog.text'> <xsd:restriction base='xsd:string'>   <xsd:maxLength value='MLIT' /> <!--
XXXneeds actual value --> </xsd:restriction>
 
</xsd:simpleType>

<xsd:simpleType name='INTEGER'> <xsd:restriction base='xsd:integer'>   <xsd:maxInclusive value='2147483647'/>
<xsd:minInclusivevalue='-2147483648'/> </xsd:restriction>
 
</xsd:simpleType>

<xsd:simpleType name='NUMERIC'> <xsd:restriction base='xsd:decimal'>   <xsd:totalDigits value='PLIT'/> <!-- XXX needs
actualvalues -->   <xsd:fractionDigits value='SLIT'/> </xsd:restriction>
 
</xsd:simpleType>

<xsd:complexType name='RowType'> <xsd:sequence>   <xsd:element name='name' type='peter.pg_catalog.text'
nillable='true'></xsd:element>  <xsd:element name='category' type='INTEGER' nillable='true'></xsd:element>
<xsd:elementname='price' type='NUMERIC' nillable='true'></xsd:element> </xsd:sequence>
 
</xsd:complexType>

<xsd:complexType name='TableType'> <xsd:sequence>   <xsd:element name='row' type='RowType' minOccurs='0'
maxOccurs='unbounded'/> </xsd:sequence>
 
</xsd:complexType>

<xsd:element name='table' type='TableType' />

</xsd:schema>
 <row>   <name>screwdriver</name>   <category>3</category>   <price>7.99</price> </row>
 <row>   <name>drill</name>   <category>9</category>   <price>12.49</price> </row>

</table>

-- 
Peter Eisentraut   peter_e@gmx.net



Re: PostgreSQL and SOAP, suggestions?

From
mlw
Date:
That function looks great, but what happens if you need to return 1 
million records? Wouldn't you exhaust all the memory in the server? Or 
can you stream it somehow?

I have an actual libpq program which performs a query against a server, 
and will stream out the XML, so the number of records has very little 
affect on efficiency. I think the table2xml function is great for 99% of 
all the queries, but for those huge resultsets, I think it may be 
problematic.

What do you think?

BTW, I routinely have queries that return millions of rows.


Peter Eisentraut wrote:

>mlw writes:
>
>  
>
>>Given a HTTP formatted query:
>>GET "http://localhost:8181/pgmuze?query=select+*+from+zsong+limit+2"
>>
>>The output is entered below.
>>    
>>
>
>That looks a lot like the SQL/XML-style output plus a SOAP header.  Below
>is the output that I get from the SQL/XML function that I wrote.  A simple
>XSLT stylesheet should do the trick for you.
>
>Btw., I also have an XSLT stylesheet that can make an HTML table out of
>this output and I have a table function that can generate a virtual table
>from this output.
>
>
>=> select table2xml('select * from products');
>
><?xml version='1.0'?>
><table
>    xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
>    xsi:noNamespaceSchemaLocation='#'> <!-- XXX this needs to be fixed -->
>
><xsd:schema
>    xmlns:xsd='http://www.w3.org/2001/XMLSchema'
>    xmlns:sqlxml='http://www.iso-standards.org/mra/9075/2001/12/sqlxml'>
>
>  <xsd:import
>      namespace='http://www.iso-standards.org/mra/9075/2001/12/sqlxml'
>      schemaLocation='http://www.iso-standards.org/mra/9075/2001/12/sqlxml.xsd' />
>
><xsd:simpleType name='peter.pg_catalog.text'>
>  <xsd:restriction base='xsd:string'>
>    <xsd:maxLength value='MLIT' /> <!-- XXX needs actual value -->
>  </xsd:restriction>
></xsd:simpleType>
>
><xsd:simpleType name='INTEGER'>
>  <xsd:restriction base='xsd:integer'>
>    <xsd:maxInclusive value='2147483647'/>
>    <xsd:minInclusive value='-2147483648'/>
>  </xsd:restriction>
></xsd:simpleType>
>
><xsd:simpleType name='NUMERIC'>
>  <xsd:restriction base='xsd:decimal'>
>    <xsd:totalDigits value='PLIT'/> <!-- XXX needs actual values -->
>    <xsd:fractionDigits value='SLIT'/>
>  </xsd:restriction>
></xsd:simpleType>
>
><xsd:complexType name='RowType'>
>  <xsd:sequence>
>    <xsd:element name='name' type='peter.pg_catalog.text' nillable='true'></xsd:element>
>    <xsd:element name='category' type='INTEGER' nillable='true'></xsd:element>
>    <xsd:element name='price' type='NUMERIC' nillable='true'></xsd:element>
>  </xsd:sequence>
></xsd:complexType>
>
><xsd:complexType name='TableType'>
>  <xsd:sequence>
>    <xsd:element name='row' type='RowType' minOccurs='0' maxOccurs='unbounded' />
>  </xsd:sequence>
></xsd:complexType>
>
><xsd:element name='table' type='TableType' />
>
></xsd:schema>
>
>  <row>
>    <name>screwdriver</name>
>    <category>3</category>
>    <price>7.99</price>
>  </row>
>
>  <row>
>    <name>drill</name>
>    <category>9</category>
>    <price>12.49</price>
>  </row>
>
></table>
>
>  
>



Re: PostgreSQL and SOAP, suggestions?

From
Hannu Krosing
Date:
mlw kirjutas T, 01.04.2003 kell 15:29:
> Hannu Krosing wrote:
> 
> >pgsql@mohawksoft.com kirjutas E, 31.03.2003 kell 19:52:
> >  
> >
> >>Actually, as far as I am aware, the header is for metadata, i.e. it is the
> >>place to describe the data being returned.
> >>    
> >>
> >
> >Did you read the SOAP spec ?
> >
> yes

???


What you have come up with _is_not_ a SOAP v1.1 message at all. It does
use some elements with similar names but from different namespace.

the SOAP Envelope, Header and Body elemants must be from namespace
http://schemas.xmlsoap.org/soap/envelope/

Per section 3 paragraph 2 of SOAP spec a conforming SOAP processor MUST
discard a message that has incorrect namespace.

> <?xml version = "1.0"?>
> <mwssql:Envelope xmlns:mwssql="http://www.mohawksoft.com/mwssql/envelope">
>  <mwssql:Header>

The <SOAP-ENV:Header> "is a generic mechanism for adding features to a
SOAP message in a decentralized manner without prior agreement between
the communicating parties. SOAP defines a few attributes that can be
used to indicate who should deal with a feature and whether it is
optional or mandatory (see section 4.2)".

The <SOAP-ENV:Body> "is a container for mandatory information intended
for the ultimate recipient of the message (see section 4.3). SOAP
defines one element for the body, which is the Fault element used for
reporting errors."


The Header element is encoded as the first immediate child element of
the SOAP Envelope XML element. All immediate child elements of the
Header element are called header entries.

The encoding rules for header entries are as follows: 
    1. A header entry is identified by its fully qualified element       name, which consists of the namespace URI and
thelocal name.       All immediate child elements of the SOAP Header element MUST be       namespace-qualified.
 

...

An example is a header with an element identifier of "Transaction", a
"mustUnderstand" value of "1", and a value of 5. This would be encoded
as follows:

<SOAP-ENV:Header>  <t:Transaction     xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">         5  </t:Transaction>
</SOAP-ENV:Header>

>   <exec:sql>update cgrpairs set ratio=0 where srcitem=100098670</exec:sql>
>   <exec:affected>2657</exec:affected>
>   <qry:sql>select * from ztitles limit 2</qry:sql>
>   <qry:ROWSET>
>    <qry:ROW columns="28">

where are namespaces exec:, qry: abd t: defined ?

----------------
Hannu



Re: PostgreSQL and SOAP, suggestions?

From
mlw
Date:

Hannu Krosing wrote:

>mlw kirjutas T, 01.04.2003 kell 15:29:
>  
>
>>Hannu Krosing wrote:
>>
>>    
>>
>>>pgsql@mohawksoft.com kirjutas E, 31.03.2003 kell 19:52:
>>> 
>>>
>>>      
>>>
>>>>Actually, as far as I am aware, the header is for metadata, i.e. it is the
>>>>place to describe the data being returned.
>>>>   
>>>>
>>>>        
>>>>
>>>Did you read the SOAP spec ?
>>>
>>>      
>>>
>>yes
>>    
>>
>
>???
>
>
>What you have come up with _is_not_ a SOAP v1.1 message at all. It does
>use some elements with similar names but from different namespace.
>
>the SOAP Envelope, Header and Body elemants must be from namespace
>http://schemas.xmlsoap.org/soap/envelope/
>
[snip]
Hmm, I read "SHOULD" and "MAY" in the spec, assuming that it was not 
"MUST" are you saying it is invalid if I do not use the SOAP URIs for 
the name spaces? If so, no big deal, I'll change them.

As for defining the namespaces, yea that's easy enough, just tack on an 
attribute.

I still don't see where putting the field definitions in the soap header 
is an invalid use of that space.



Re: PostgreSQL and SOAP, suggestions?

From
Peter Eisentraut
Date:
Andrew Dunstan writes:

> If the intention is to use field names as (local) tag names, how will you
> handle the case where the field name isn't a valid XML name? Of course, one
> could do some sort of mapping (replace illegal chars with "_", for example)
> but then you can't be 100% certain that you haven't generated a collision,
> I should think.

The SQL/XML draft specifies an reversible escape mechanism.  Basically,
when mapping an SQL identifier to an XML name you replace problematic
characters with an escape sequence based on the Unicode code point, like
_x2A3B_.

-- 
Peter Eisentraut   peter_e@gmx.net



Re: PostgreSQL and SOAP, suggestions?

From
Peter Eisentraut
Date:
mlw writes:

> That function looks great, but what happens if you need to return 1
> million records?

The same thing that happens with any set-returning function: memory
exhaustion.

> I have an actual libpq program which performs a query against a server,
> and will stream out the XML, so the number of records has very little
> affect on efficiency. I think the table2xml function is great for 99% of
> all the queries, but for those huge resultsets, I think it may be
> problematic.
>
> What do you think?

Clearly, my approach is not sufficient if you need to handle big result
sets.  But perhaps a compromise based on cursors could be designed so that
large parts of the format can be managed centrally.  Such as:

DECLARE foo CURSOR FOR SELECT ... ;

-- gives you the XML Schema for the result set
SELECT xmlschema_from_cursor(foo);

-- gives you ones row (<row>...</row>)
SELECT xmldata_from_cursor(foo);

-- 
Peter Eisentraut   peter_e@gmx.net



Re: PostgreSQL and SOAP, suggestions?

From
Hannu Krosing
Date:
mlw kirjutas K, 02.04.2003 kell 15:56:
> Hannu Krosing wrote:
> 
> >What you have come up with _is_not_ a SOAP v1.1 message at all. It does
> >use some elements with similar names but from different namespace.
> >
> >the SOAP Envelope, Header and Body elemants must be from namespace
> >http://schemas.xmlsoap.org/soap/envelope/
> >
> [snip]
> Hmm, I read "SHOULD" and "MAY" in the spec, assuming that it was not 
> "MUST" are you saying it is invalid if I do not use the SOAP URIs for 
> the name spaces? If so, no big deal, I'll change them.

AFAICS you can _leave_out_ the namespace, but not put in another,
nonconforming namespace.

> As for defining the namespaces, yea that's easy enough, just tack on an 
> attribute.
> 
> I still don't see where putting the field definitions in the soap header 
> is an invalid use of that space.

It is not strictly nonconforming, just not the intended use of
"transparently adding" new info:
 4.2 SOAP Header
 SOAP provides a flexible mechanism for extending a message in a decentralized and modular way without prior knowledge
betweenthe communicating parties. Typical examples of extensions that can be implemented as header entries are
authentication,transaction management, payment etc.
 

I.e. the intended use of *SOAP* Header is *not* defining the structure
of the message but is rather something similar to e-mail (rfc822)
Headers.

The XML way of defining a message is using a DTD, XML-schema, Relax NG
schema or somesuch, either embedded (forbidden for DTD's in SOAP) or
referenced.

Also for me the following:
 The Header element is encoded as the first immediate child element of the SOAP Envelope XML element. All immediate
childelements of the Header element are called header entries.
 
 The encoding rules for header entries are as follows: 
    1. A header entry is identified by its fully qualified element       name, which consists of the namespace URI and
thelocal name.       All immediate child elements of the SOAP Header element MUST be       namespace-qualified.
 

describes an element with a full embedded URI, not just
namespace-qualified tagname, but I may be reading it wrong and the
namespace could be defined at outer level. But defining namespace at the
outer level is counterintuitive for cases where the header element is to
be processed and removed by some "SOAP intermediary".

Also this seems to support *not* using Header for essensial structure
definitions:
 4.3.1 Relationship between SOAP Header and Body
 While the Header and Body are defined as independent elements, they are in fact related. The relationship between a
bodyentry and a header entry is as follows: A body entry is semantically equivalent to a header entry intended for the
defaultactor and with a SOAP mustUnderstand attribute with a value of "1". The default actor is indicated by not using
theactor attribute (see section 4.2.2).
 

This suggests that putting the structure definition as 1-st Body element
and data as second would be equivalent to putting structure in Header

-----------------
Hannu



Re: PostgreSQL and SOAP, suggestions?

From
mlw
Date:

Hannu Krosing wrote:

>mlw kirjutas K, 02.04.2003 kell 15:56:
>  
>
>>Hannu Krosing wrote:
>>
>>    
>>
>>>What you have come up with _is_not_ a SOAP v1.1 message at all. It does
>>>use some elements with similar names but from different namespace.
>>>
>>>the SOAP Envelope, Header and Body elemants must be from namespace
>>>http://schemas.xmlsoap.org/soap/envelope/
>>>
>>>      
>>>
>>[snip]
>>Hmm, I read "SHOULD" and "MAY" in the spec, assuming that it was not 
>>"MUST" are you saying it is invalid if I do not use the SOAP URIs for 
>>the name spaces? If so, no big deal, I'll change them.
>>    
>>
>
>AFAICS you can _leave_out_ the namespace, but not put in another,
>nonconforming namespace.
>
[snip]

I think you are interpreting the spec a bit too restrictively. The 
syntax is fairly rigid, but the spec has a great degree of flexibility. 
I agree that, syntactically, it must work through a parser, but there is 
lots of room to be flexible.



Re: PostgreSQL and SOAP, suggestions?

From
cbbrowne@cbbrowne.com
Date:
mlw wrote:
> I think you are interpreting the spec a bit too restrictively. The 
> syntax is fairly rigid, but the spec has a great degree of flexibility. 
> I agree that, syntactically, it must work through a parser, but there is 
> lots of room to be flexible.

This is /exactly/ the standard problem with SOAP.

There is enough "flexibility" that there are differing approaches
associated, generally speaking, with "IBM versus Microsoft" whereby it's
easy to generate SOAP requests that work fine with one that break with
the other.

For a pretty simple example of a longstanding bug that has never been
fixed, see:
<http://sourceforge.net/tracker/index.php?func=detail&aid=559324&group_id=26590&atid=387667>

The precis:

The SOAP implementation used by the XMethods folks to publish stock
prices is buggy, rejecting perfectly legitimate messages submitted using
ZSI (a Python SOAP implementation).

The bug isn't with ZSI; it is quite clearly with the server, apparently
implemented in Java using one of the EJB frameworks.  

In practice, what happens is that since that service is fairly popular,
particularly for sample applications, the implementors of SOAP libraries
wind up coding around the bugs.

The problem is that it gets difficult to tell the difference between
bugs and variations in interpretations of the standards.

If the specs were more strictly defined, it would be a lot easier to use
SOAP, because you wouldn't be left puzzling over whether the
interoperability problems you're having are:
a) Problems with the client;b) Problems with the server;c) Problems with interpretation of specs;d) ...

The vast degree to which messages can get rewritten behind your back
adds to the fun.

Of course, it's only fun if you *enjoy* having interoperability
problems...
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www.ntlug.org/~cbbrowne/soap.html
He who laughs last thinks slowest. 



Re: PostgreSQL and SOAP, suggestions?

From
Hannu Krosing
Date:
cbbrowne@cbbrowne.com kirjutas N, 03.04.2003 kell 02:01:
> mlw wrote:
> > I think you are interpreting the spec a bit too restrictively. The 
> > syntax is fairly rigid, but the spec has a great degree of flexibility. 
> > I agree that, syntactically, it must work through a parser, but there is 
> > lots of room to be flexible.
> 
> This is /exactly/ the standard problem with SOAP.
> 
> There is enough "flexibility" that there are differing approaches
> associated, generally speaking, with "IBM versus Microsoft" whereby it's
> easy to generate SOAP requests that work fine with one that break with
> the other.

Do you know of some:

a) standard conformance tests

b) recommended best practices for being compatible with all mainstream
implementations (I'd guess a good approach would be to generate very
strictly conformant code but accept all that you can, even if against
pedantic reading of the spec)

-----------------
Hannu



Re: PostgreSQL and SOAP, suggestions?

From
mlw
Date:

Hannu Krosing wrote:

>cbbrowne@cbbrowne.com kirjutas N, 03.04.2003 kell 02:01:
>  
>
>>mlw wrote:
>>    
>>
>>>I think you are interpreting the spec a bit too restrictively. The 
>>>syntax is fairly rigid, but the spec has a great degree of flexibility. 
>>>I agree that, syntactically, it must work through a parser, but there is 
>>>lots of room to be flexible.
>>>      
>>>
>>This is /exactly/ the standard problem with SOAP.
>>
>>There is enough "flexibility" that there are differing approaches
>>associated, generally speaking, with "IBM versus Microsoft" whereby it's
>>easy to generate SOAP requests that work fine with one that break with
>>the other.
>>    
>>
>
>Do you know of some:
>
>a) standard conformance tests
>
Off the top of my head, no, but I bet it is a goole away. If you know 
any good links, I'd love to know. I have been working off the W3C spec.

>
>b) recommended best practices for being compatible with all mainstream
>implementations (I'd guess a good approach would be to generate very
>strictly conformant code but accept all that you can, even if against
>pedantic reading of the spec)
>
I have been planning to "test" the whole thing with a few .NET 
applications. I am currently using expat to parse the output to ensure 
that it all works correcty.

>
>  
>

>  
>



Re: PostgreSQL and SOAP, suggestions?

From
cbbrowne@cbbrowne.com
Date:
> cbbrowne@cbbrowne.com kirjutas N, 03.04.2003 kell 02:01:
> > mlw wrote:
> > > I think you are interpreting the spec a bit too restrictively. The 
> > > syntax is fairly rigid, but the spec has a great degree of flexibility. 
> > > I agree that, syntactically, it must work through a parser, but there is 
> > > lots of room to be flexible.
> > 
> > This is /exactly/ the standard problem with SOAP.
> > 
> > There is enough "flexibility" that there are differing approaches
> > associated, generally speaking, with "IBM versus Microsoft" whereby it's
> > easy to generate SOAP requests that work fine with one that break with
> > the other.
> 
> Do you know of some:
> 
> a) standard conformance tests
> 
> b) recommended best practices for being compatible with all mainstream
> implementations (I'd guess a good approach would be to generate very
> strictly conformant code but accept all that you can, even if against
> pedantic reading of the spec)

The problem with a) is that SOAP, unlike CORBA, doesn't have the notion of 
standardized language bindings.  That makes it tough to be sure that your 
implementation is "standard" in any meaningful way in the first place.

The "best practices" have involved scripting up interoperability tests where 
they construct sets of functions with varying data types and verify that "my 
client implementation can talk to your server implementation," and vice-versa.

And when you run into problems, you chip off bits of code until the block of 
stone starts looking like an elephant.

In order to have confidence of interoperability, you have to test your client 
library against all the servers you care about, or vice-versa.  That's 
definitely not the same thing as being a "conformance" test.

Trying to be "really strict" doesn't seem to be a viable strategy, as far as I 
can see...
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www3.sympatico.ca/cbbrowne/wp.html
"The cost of living has just gone up another dollar a quart."  
-- W.C. Fields



Re: PostgreSQL and SOAP, suggestions?

From
cbbrowne@cbbrowne.com
Date:
> I have been planning to "test" the whole thing with a few .NET 
> applications. I am currently using expat to parse the output to ensure 
> that it all works correcty.

That, unfortunately, probably implies that your implementation is almost 
totally non-interoperable.

You should put out of your mind the notion of being "correct."  Being 
"correct" is pretty irrelevant if 80% of the requests that come from a VB.NET 
client fail because Microsoft implemented part of their request differently 
than what you interpreted as "correct."

The point is that "correctness" isn't the thing you need to aim for; what you 
should aim for is interoperability with the important client implementations.

SOAP::Lite, .NET, probably some Java ones, C++ ones, and such.

Nobody does "correctness" testing; they do interoperability tests where they 
try to submit requests to Apache AXIS, .NET, WebSphere, and the lot of other 
important implementations.  If you're testing a server (as is the case here), 
then the point is to run tests with a bunch of clients.

Head to the SOAP::Lite and Axis projects; you'll see matrices describing this 
sort of thing...
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www.ntlug.org/~cbbrowne/advocacy.html
"Fear leads to anger. Anger leads to hate. Hate leads to using Windows
NT for mission-critical applications."  --- What Yoda *meant* to say



Re: PostgreSQL and SOAP, suggestions?

From
"Jason M. Felice"
Date:
On Thu, Apr 03, 2003 at 07:54:13AM -0500, cbbrowne@cbbrowne.com wrote:
> > I have been planning to "test" the whole thing with a few .NET 
> > applications. I am currently using expat to parse the output to ensure 
> > that it all works correcty.
> 
> That, unfortunately, probably implies that your implementation is almost 
> totally non-interoperable.
> 
> You should put out of your mind the notion of being "correct."  Being 
> "correct" is pretty irrelevant if 80% of the requests that come from a VB.NET 
> client fail because Microsoft implemented part of their request differently 
> than what you interpreted as "correct."
> 
> The point is that "correctness" isn't the thing you need to aim for; what you 
> should aim for is interoperability with the important client implementations.
> 
> SOAP::Lite, .NET, probably some Java ones, C++ ones, and such.
> 
> Nobody does "correctness" testing; they do interoperability tests where they 
> try to submit requests to Apache AXIS, .NET, WebSphere, and the lot of other 
> important implementations.  If you're testing a server (as is the case here), 
> then the point is to run tests with a bunch of clients.
> 
> Head to the SOAP::Lite and Axis projects; you'll see matrices describing this 
> sort of thing...

Hmmm.  Can I reiterate my support of XML-RPC here?  <g>

-Jay 'Eraserhead' Felice

> --
> (reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
> http://www.ntlug.org/~cbbrowne/advocacy.html
> "Fear leads to anger. Anger leads to hate. Hate leads to using Windows
> NT for mission-critical applications."  --- What Yoda *meant* to say
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)