xml-dev - RE: Proposed New XSL Element -" xsl:insert" - Could it be considered

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

Hi David,

David said:
Or XInclude.  old syntax: <xml:include href="mystuff.xml">.  Oh right,
nobody's implemented XInclude inside XSLT yet.

Didier replies:
Yes we did it. Take a look at our experimental site. The default server
state is xinclude=false, so you have to set the switch on to get the
xinclude elements to be processed. In fact, we do the xinclude processing
before processing the document for XSLT. Thus, the info set is modified
before any XSLT processing.

In the example, you'll find two spots where we do an xinclude processing. We
are still using the old notation and didn't jump on the new notation yet.
During the process we also discovered some missing functionality that I
mentioned in previous posts (see Didier's lab).

Server processing:
First and foremost, this is an XML server able to process XML documents. No
convoluted URLs, just use simple HTTP GET methods to request an XML
document. As simple and intuitive as that. The server identify the user
agent. The user agents capabilities are stored in a table. The server will
do server side processing for any XML processing the user agent cannot
handle. For instance, if the user agent is not able to do xinclude
processing, the server will do it on its side (already implemented). Idem
for XSLT processing (already implemented), idem for Xform processing (a work
in progress, no solid code yet to demonstrate). So, when the user agent has
been identified with a pattern match made on the HTTP headers, the server
identify the document type of the document referred by the HTTP GET and
finds in a table the matching pair Doctype/stylesheet. The table contains
the default style sheet for a particular doc type. The default
document/stylesheet matching can be overridden by a declaration in the xml
document or by a parameter in the URL. Actually, even if the mechanism is
working well, some style sheets are missing for several user agent. However,
part of the lab's experiment is to create wml and voiceXML style sheets in
addition to HTML style sheets. We are actually doing some very interesting
things with VoiceXML and you'll see a future article on that in the
XML.com's "style matters" column. Even more, you'll be able to see a real
life VoiceXML server... Hoops, I was about to tell the surprise. Wait for
the article, you'll see, sorry, you'll hear it.

Instructions on how to use the lab's experiment:
a) go to http://talva.dyndns.org/home/login.xml (notice that it is an XForms
document transformed by an XSLT style sheet for rendering the document on
the connected user agent)
b) log with user id=didier, password=didier, then you'll then see my home
page.
c) to see the xinclude in action, click on the Moreover news feed small
window's "edit" button. You'll then see the xinclude engine in action. The
button in fact is an anchor pointing to
http://talva.dyndns.org/home/didier/customize-moreover.xml?xinclude=yes (
the document is displayed at the end of this message). You can also invoke
an xinclude processing by clicking on the "get your news feed" link but the
result will be slow to come since the calls are made to the Moreover server
and this could take seconds before the moreover server returns the results
(even if each xinclude processing is running in its own thread and all
xinclude requests are made in parallel). If you are patient you can click on
it, but the snail speed has nothing to do with the xinclude processing. In
fact, this is due to the moreover server response time, we made the
suggestion to Moreover to include a time to live HTTP header so that caching
could be used for a news feed. In this case, because, we handle the caching
of documents, the xinclude would be a lot faster since the document would be
in the cache. However, right now, Moreover publish the XML documents without
a time to live so we cannot rely on the cache. Hence, the xinclude processor
has to get the document each time. This implies that for server that do not
use the time to live header (unfortunately a lot do that) the inclusion
element should "include" :-) an attribute to set the time to live so that
even if the producer didn't set the TTL in the HTTP headers, that the
document would be cached and thus, the performance would be improved. I know
that theoretically, this may not be required of an inclusion element but
practically, you cannot live without it. So experiments are great to help
you discover the gap between the real life and the ideasphere (Stephan our
permanent lab's resident says that I am the re-incarnation of Bacon :-))

conclusion:
Finally, as value for the xinclude href, we used an experimental XPATH URI
notation (we did that simply to try and because we are tremendously curious
:-)) but the final release will support Xpointers. From reading the document
below you can notice that document fragments are included in the <customize>
element/infoset. The fragments are specified by an XPath expression. But
later on, an XPointer expression like
file://D:/XMLSite/home/didier/profile.xml#profile will be recognized.

So yes there is an xinclude engine on earth and we would be more than happy
to share with the W3 working group our day to day _concrete_ and _empirical_
experience with xinclude constructs. Until then, let's share it with our
XMLdev colleagues.

Sample document (customize-moreover.xml):
<?xml version="1.0"?>
<customize  xmlns:xlink="http://ww.w3.org/TR/xlink"
	    xmlns:xinclude="http://www.w3.org/1999/XML/xinclude">

	<xinclude:include
href="document('D:\XMLSite\home\didier\profile.xml')/profile"/>
	<xinclude:include href="document('D:\XMLSite\home\moreover.xml')/folders"/>

</customize>

OK now back to my lab, I have other very interesting experiments to do with
XForms. Stay tuned, like my colleague here like to say "Something wonderful
is happening". Note: he's a big fan of Arthur C Clark books :-)). I cannot
contradict him, if we succeed with xforms processing this could be probably
the beginning of a full XML form processing without a java component or an
ASP script at the other end (yes just scriplets used to validate but not to
process the forms). But I won't say more, we have a lot of work to do before
you can see the concrete xforms processing.

Note: most of the XML documents and style sheet have been made by our friend
and stylesheet magician, Nikita Ogievetski who, for a while was a lab's
resident member.

Cheers
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: XML devConf2000 (http://www.xmldevconf2000.com)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)