[
Lists Home |
Date Index |
Thread Index
]
- From: "Didier PH Martin" <martind@netfolder.com>
- To: "Xml-Dev" <xml-dev@xml.org>
- Date: Tue, 4 Apr 2000 10:46:34 -0400
Hi,
Under the overall theme of information integration, information set (GROVE),
I made an xinclude interpreter and encountered some problems. This reports
state some results of these xinclude experiments.
Experiment protocol:
--------------------
The xinclude interpreter behaves are requested by the W3C Working draft
(ref: http://www.w3.org/TR/xinclude ). The xinclude construct has been used
to include result of SQL request (i.e. XML documents), result of request to
news feed engines (moreover.com and On24.com that provides XML result),
non-structure or semi-structured data indexing engines (Thunderstorm,
AltaVista with a wrapper that returns an XML document for a topic query) and
to simple xml document obtained through HTTP request (HTTP 1.1 or WebDAV).
The XML document contained only one xinclude request at a time since,
parallel request is not yet implemented in the Xinclude interpreter (the
next step).
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 request I had to flatten out sql request into a single string
and make it fit as an HTTP protocol query. In fact a majority of sql queries
are more visible when expressed on several lines. For example, I needed to
do some request with an HTTP POST method to an engine that would reply with
an XML document.
Proposed solution:
------------------
The actual xinclude query universe is restricted to accessing documents with
single URLs and does not take into account the possibility to do a multiple
line request through, for instance, a POST HTTP request. The actual xinclude
construct is then limited to, for instance, the HTTP GET method or any
protocol that can be expressed as 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 have a data
content. The data content may then contain (a) a structured or
semi-structured request or a multi-line request (such as sql). If the
privileged protocol is HTTP, then a data content query 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 made to the gizmo located at
"http://www.mydomain.com/MyEngine" and which returns either an XML document
or 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
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: Web Chicago(http://www.mfweb.com)
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/
***************************************************************************
|