xml-dev - Didier's lab report

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

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@netfolder.com
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/
***************************************************************************