ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> xml-dev
xml-dev
Re: Fwd: Re: [xml-dev] What does SOAP really add?
by Paul Prescod other posts by this author
Apr 24 2002 1:20AM messages near this date
Re: [xml-dev] What does SOAP really add? | Re: [xml-dev] What does SOAP really add?
Didier PH Martin wrote:
>  
>  Hello Paul,
>  
>  Paul said:
>  > Please give a concrete example where you have run into these
>  > limitations.
>  
>  Didier replies:
>  With pleasure. To give you the exact query is beyond the limits of my memory
>  but  I can explain the difficulties I encountered. When I wanted to obtain a
>  particular document from an Oracle DB using the XDK[1] to be included with
>  the XSLT document function, this ended with the limitations of the actual
>  "document" function limitations. 

My point in the article I referenced is that the web is a system with
its own data model. If you want to get the full benefit of the Web you
need to map things into that model in the same way that you only get the
benefit of SQL by mapping things into the relational model. The web is
flexible enough that you can hack your way around the model (much easier
than you can in, e.g. SQL) but then you will run into limitations like
the SQL encoding issue.

Rather than trying to figure out a One True SQL mapping, I would
encourage you to think: "what are the resource types that I am trying to
transmit." Invent XML vocabularies for those. Use simple ASPs or CGIs to
build those XML documents based on URI queries. This shifts effort from
the client to the server. That's usually good in and of itself (it
allows simpler clients) but it also means that you will work better with
other parts of the Web infrastructure like XInclude, RDF, XSLT, etc.
Most important, it means that your clients are much less coupled to the
schema of your database.

>  ... Can we say to the people "do not create
>  query languages on XML - you are not allowed to benefit from all its
>  advantages". Can the web ignore that sophisticated query language could be
>  used to fetch documents and that original URLs where created to emulate file
>  hierarchies and simple command lines (as found in Unix, Linux or DOS). Dont
>  we stretch URLs by pretending that they could be as sophisticated as some
>  query languages?

If the query language is *application specific* (as Google's is) then
you will hardly ever have a problem, if ever.

If you are trying to send a generic query language, like XQL then you
are essentially tunnelling through the Web model rather than adapting to
it. You could similarly complain that there is no way to tunnel XQL
through SQL or SQL through OQL or OQL through XQL. URIs are their own
"query language" and the model behind them is not the relational model,
nor the OMG object model nor the infoset, but rather the resource model.
If you adapt to that things get easier, just as SQL gets easier if you
adapt to the relational model (rather than trying to apply it to an
unnormalized infoset, for example!).

 Paul Prescod

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl> 
Thread:
Joshua Allen
Didier PH Martin
Paul Prescod
Didier PH Martin
Didier PH Martin
Jeff Greif
Paul Prescod
Paul Prescod
Didier PH Martin
Paul Prescod
Paul Prescod
Thomas B. Passin
Didier PH Martin
Didier PH Martin
Thomas B. Passin
Paul Prescod
Paul Prescod
Paul Prescod
Didier PH Martin
Didier PH Martin
Alaric Snell
Didier PH Martin
Didier PH Martin
Julian Reschke
John Cowan
Alaric Snell
Jim Ancona
Didier PH Martin
Alaric Snell
Jim Ancona
John Cowan
Thomas B. Passin
Didier PH Martin
Michael Kay
Francis Norton
Adam Turoff
Mike Brown
Julian Reschke
Alaric Snell
Nischal Muthana
Thomas B. Passin
Didier PH Martin
John Cowan
Didier PH Martin
John Cowan
Trevor Croll
Peter Murphy
Didier PH Martin
Didier PH Martin
Paul Prescod

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved