[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Proposed New XSL Element -" xsl:insert" - Could it be considered
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@n... Conferences: XML devConf2000 (http://www.xmldevconf2000.com) Book: XML Professional (http://www.wrox.com) column: Style Matters (http://www.xml.com)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|