OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Didier's labs: experiments with xinclude - corrections

[ 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 16:00:55 -0400


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
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
c) non-structured or semi-structured data indexing engines requests
AltaVista with some wrapper code that returns an XML document for each
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
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
to resolve in the most optimal way any parallel xinclude. This last feature
should not affect the
declarative format of the xinclude construct.


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
and make it to fit into a single line string. In fact, a majority of sql
are more readable when expressed on several lines. On the other hand, a more
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
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"

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

Now back to the labs, I have some lines of codes screaming for some
attention. Do you ear them? :-))
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/


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS