xml-dev - Didier's labs: experiments with xinclude - corrections

["Didier PH Martin" <martind@netfolder.com>]

Hi,

Excuse me for the last post that has several typos. I pressed the wrong key
and the message was sent without a previous proofread. So here is a new one.

Under the overall theme of information integration and information set
(GROVE).
I made an xinclude interpreter and encountered some problems. This report
states some of the results concerning these xinclude experiments.

Experiment protocol:
--------------------

The xinclude interpreter behaves as requested by the W3C Working draft
(ref: http://www.w3.org/TR/xinclude ). The xinclude construct has been used
to include, in an XML document:
a) results of SQL requests (i.e. XML documents)
b) results of requests to news feed engines (moreover.com and On24.com
services),
c) non-structured or semi-structured data indexing engines requests
(Thunderstorm,
AltaVista with some wrapper code that returns an XML document for each
query)
d) results of HTTP requests to obtain an xml document or an XML fragment
(HTTP 1.1 or WebDAV).

To create the XML fragment, I had to include an xpointer interpreter to the
xinclude engine .

The tested XML documents contained only one xinclude request at a time
since,
parallel requests are not yet implemented in the Xinclude interpreter
(reserved for the
next step). It is pre-conceived that it is to the implementer's
responsability
to resolve in the most optimal way any parallel xinclude. This last feature
should not affect the
declarative format of the xinclude construct.

Issues:
-------

For any XML document accessible through a simple URL, the construct does not
pose any problems.

When the included document or document fragment is the
result of a more sophisticated query, the construct poses some readability
problems. Furthermore, the actual construct poses some limitation problems
and is a bit out of synch with current XML developements. For instance, to
do some sql requests I had to flatten out an sql request into a single
string
and make it to fit into a single line string. In fact, a majority of sql
queries
are more readable when expressed on several lines. On the other hand, a more
severe
experimented limitation is when I needed to do some requests with the HTTP
POST method to an
engine that replies with XML documents. I wasn't able to include a fragment
with such
method (using the xinclude construct).

Proposed solution:
------------------
The actual xinclude query universe is restricted solely to accessing
documents with
URLs and does not take into account the possibility to do requests like,
for instance, an HTTP POST request. The actual xinclude
construct is then limited to, as an example, the HTTP GET method or to any
protocol that can be expressed with a single URL. Several systems currently
"a
work in progress" in the e-commerce land take - as input for a request - an
XML document through an HTTP POST method and reply with an XML document.

The proposed solution is to allow the xinclude construct to allow
<xinclude:include> elements' data
content. The data content may then contain (a) a structured or
semi-structured request, a multi-line request (such as sql) or any valid
query. If the
privileged protocol is HTTP, then, the data content would be interpreted
as an HTTP POST content. Thus a construct like

<xinclude:include href="http://www.mydomain.com/MyEngine">
select wheel, spike, brake
from my_bike-database
where wheel="Mavic" and break="shimano"
</xinclude>

Would result into an HTTP POST method targeted to the gizmo located at
"http://www.mydomain.com/MyEngine" and which returns either an XML document
or an XML document fragment. This latter is then inserted into the
information
set.

Now back to the labs, I have some lines of codes screaming for some
attention. Do you ear them? :-))
Cheers
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: XML Europe (http://www.gca.org)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)
Products: http://www.netfolder.com


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************