[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Didier's lab report
Didier's Lab Report Vol 1 No 5 ---------------------------------------------- In the last month, my lab was located in an airplane, I used the long hours flying from one continent to an other, working on my experimental XML site. As usual, I will share with you the results of the research. Introduction: ------------- In the 20th century, the web was based on a homogeneous world. Microsoft's windows on most PC, HTML used for electronic publication and rendered by a PC Web browser, HTTP servers used as file servers or as application servers. In the 21st century the web ecosystem is evolving and new species are appearing. Mobile devices with an OS not owned by Microsoft (Ex: PalmOS, Symbian's EPOC), new electronic publishing languages (i.e. rendering languages) are appearing: VoiceXML for aural rendering, WML for visual rendering on small devices, SVG for complex page layout, drawings and animation, etc.. This lead me to try to find an answer to the question: What is an XML server? ---------------------- In the 20th century we simply posted a file on an HTTP server using the FTP protocol. We didn't cared about the server's operating system as long as at least HTTP and FTP where supported by the server. In the 21st century, we use webdav to update the server. At it was the case in the beginning of the century, not everybody was traveling with a car, most of the people where traveling with horses and buggies. A lot of people are still using HTTP/FTP and few are using Webdav. But this may change later on in the 21st century. The drawback of an XML server as a file server is that the XML documents are static and not dynamically created. People in the 20th century where also saying that about HTML. The second drawback is that if the XML document contains an abstract data model, this model has to be translated into a view or said differently in practical terms, translated into a rendering format. Thus, the client requesting an XML document has to perform the transformation. For the new species appearing on the 21st century market, this is not very pragmatic since these devices cannot locally perform the transformation. The transformation has to be performed server side. Now back to the question "What is an XML server?". We can say that an simple HTTP or WebDAv server can be perceived as an XML server but a very primitive one only able to serve desktop browsers. To be more adapted to the 21st century this server has to be able to detect the user agent, based on the information provided by the HTTP request, determine the user agent's rendition capabilities and perform the necessary transformation. To illustrate a concrete situation let's imagine three scenarios: a) a user using a plain old phone to ask for a flight schedule (in some situations, I was seriously thinking of trading my kingdom for a flight schedule :-)) The user dial a certain number. A voice server is responding. In fact, this latter is simply rendering a voiceXML document. When the user called the voice server, this latter act as a gateway to a particular site (let's call it: gizmoflight.com). The voice server, when responding to the call, first requests the gizmoflight.com home page with an HTTP GET /. The gizmoflight.com site returns a VoiceXML document to be rendered. The end user listen to the voice asking for more info: the airplane company name. The user answers by specifying the airplane company. The voice server decodes the aural message using speech recognition technologies. When the aural message is translated into data, the voice server continue the VoiceXML document's interpretation. Thus, the voiceXML document specifies that when the company name data is available, that the "companyname".vxml document is requested from the HTTP server. The voice server(i.e. voice/web gateway) requests the voiceXML document to the gizmoflight.com site and this latter sends back a VoiceXML document to be rendered. and so on and so forth. Notice that the gizmoflight server detected the user agent, recognized that a voice server was at the other end and then sent a VoiceXML document home page. Off course, in that case, the VoiceXML pages are probably created dynamically from data sources. b) A user is using a WAP device to obtain a flight schedule. The user selects a stored bookmark pointing to the gizmoflight.com site. This latter recognizes the user agent. Notices that this time, it is a WAP device which made an HTTP GET / request. The server sends back an index.wml file to be rendered by the device. And so forth. (Notice here that the same HTTP GET / request as in the first scenario is made to the server) c) A user is using a Wireless palmpilot to obtain a flight schedule Again, the server recognizes the user agent and redirect the user to an avantGo server. This latter download an AvantGo channel to the palmpilot. and so forth. (again, notice here that the same HTTP GET / request is mode to the same gizmofilght.com server) In these three scenarios, Microsoft's windows wasn't involved on the client side. We had to recognize the capabilities of the requesting device and to provide the right document for final rendition and interaction. The same HTTP GET / request is made by three different gateways/devices to the gizmoflight.com server. The server return a different home page for each requesting device. In fact, most of these scenarios are not science fiction scenarios. For voice interaction using the plain old telephone you can use Motorola's Mya. The Lucent or Locus dialog voice server could be used as well to the same intent. For WAP interaction you can use a WAP phone and for the last simply a Wireless PalmPilot. Off course, the WAP, in north America is a new phenomenon, Voice servers are in pre market testing and Wireless palmpilot an expensive toys. But, do you know how much a car was costing at the beginning of the century? Do you remember the old movies showing these expensive mechanics and how primitive you thought they where. Just imagine one of your descendent in year 2100 looking at today's car and asking himself why these primitive mechanics where not connected to the web. Did you took a look at what OnStar is working on? I'll simply let you answer to these questions. So, 21st century XML servers (servicing XML documents and remember that XHTML, WML and VoiceXML are all XML documents) need to be more sophisticated than 20th century plain old HTML servers. And imagine, I simply took a simple scenario. More sophisticated scenarios would involve more sophisticated XML servers. Just think of the problem of Enterprise Application Integration (EAI). What are the different techniques used on the server side? ---------------------------------------------------------- I experimented two main techniques: a) An XML data source is providing an XML document. This XML document is transformed into a document appropriate to the user agent. The process is 1- recognize the user agent 2- Get the XML document from the data source (the document is an XML document simply stored in the file system, obtained from an external XML data source such as an SQL server or locally created by a script) 3- transform the document's abstract data model into a rendering data model (i.e. into a WML document for WAP devices, into HTML for PC browsers, into VoiceXML for voice servers) 4- send the document to either the gateway (i.e. the WAP or Voice gateway) or directly to the device (i.e. HTML). gateway user device | | get abstract data model encoded in XML (result XML document) | | transform the model into a rendering model (XSLT used for the transformation) | | gateway or user device b) A different template is used for each requested format. The template is based on a particular rendering language. For instance, a WML document is used for WAP devices, an XHTML document for PC browsers, a VoiceXML document for POTs (plain Old Telephones). Because all these rendering language are XML applications, I can use an XML technology like Xinclude to dynamically include content. This methodology is different from the first one since we start from the end result as a template and include the desired content. So the process is: gateway or user device | | include external content in the template (using the xinclude construct in the XML documents) | | gateway or user device. I am writing a more detailed document about these two XML based methodologies. But I can give you my early conclusions: a) The methodology based on XML templates is more adapted to a development group having graphic artists and programmers. The graphic artists create the layout, they think of the end result. Off course, WAP devices are not fun for them since they are very restricted but they can use a What You See Is What You Get kind of tool to create the different layouts. They include the "function calls" to external services as xinclude elements. Or The programmers include the xinclude constructs pointing to the right web services using the right service request. However, as I previously said in a previous Didier's lab report, the xinclude construct, as actually defined, has some limits and do not allow, for instance, SOAP "service calls". This XML tool is thus restricted only to HTTP GET based "service calls". But, the main point is that a template can be easily created and maintained in actual WYSIWYG tools make it a strong candidate for actual web teams. In this situation, XSLT can be useful when the service provide only an abstract model encoded in XML. In that case, before including the external content we need to transform it into the same format as the template. So, XSLT is useful in that case but not necessarily applied to the end result document (i.e the template). XSLT style sheets ate applied to some documents returned from web services that provide only an abstract data model. Some today's service simply return a document already packaged in a rendering format. For instance, a lot of new services return either an HTML or a WML response. But, better be prepared to both kind of services responses: abstract model encoded in XML or rendering format also encoded in XML (A person sitting next to me in the airplane and reading what I was writing on my laptop asked me if XML is a language. I had a hard time to explain to this person that XML is a meta language, it is like the alphabet. The alphabet is used to encode a language but the alphabet is not the language - It's good to be reminded sometime of this basic reality - even with a question from a fellow airplane passenger :-) b) The other conclusion form this experiment is that the methodology solely based on an abstract data model and XSLT to transform it into a rendering format is not for graphic artists and WYSIWYG tools. This is because the final rendering instructions are embedded in the XSLT style sheet and this is not easily if not at all maintainable with actual WYSIWYG tools. So, this technique is more for developers but create a gap for graphic artists. Even if in my labs I prefer to use an abstract model transformed into a rendering format with XSLT, I discovered that template based methodologies are probably more adapted to actual web teams. Because of this, certain XML tools like xlink or xinclude can be tremendously useful if adapted to web services. Web services are a species that interact with the world with either HTTP GET or HTTP POST calls. As long as xinclude do not allow HTTP POST, the plethora of HTTP POST based services are out of reach. What is missing though is a standard XML element allowing to include content either with an HTTP POST or an HTTP GET. So, for instance, to reach a SOAP service acting a wrapper to a EJB server or to a COM+ server, we would have: <xinclude:include> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="Some-URI"> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> </xinclude:include> This implies also that the xinclude interpreter has to know that this is a SOAP service request and that the HTTP header should contain: SOAPAction: "Some-URI" OK, there is still some thoughts to give to this issue. Anyway, a big conclusion form these airplane experiments. There is more than one way to go to Rome :-)) Also, every ecosystem starts with simple species and over time get more complex with more species and obviously more relationship between species. If wireless devices evolve like PCs did in the last 20 years.... I still remember an IBM guy looking at my Xerox Dorado machine and him to say "this is a toy". Today, I have a descendant of this toy having nearly one ghz and 20 gigs power on my desktop and this machine is simply an improved version of the Dorado. And my toy is thousandfold more powerful than the "real computer" this guy was refering. Lesson learned from this? Be careful of new species able to evolve and think of how this new specie can be in 10 or 20 years from now. The ecosystem evolution can be more powerful than the Feds to bring some diversity and break monopolies. Ok enough food for thought, I have other experiments to do and other flights to catch up. Yep, after the mobile office, I maybe have invented the mobile lab :-) Cheers Didier PH Martin ---------------------------------------------- Email: martind@n... 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@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ ***************************************************************************
|
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
|