xml-dev - Portal experiment

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

Hi,

I made an experiment with xlinks and XSLT.

The XML document uses recursive topic elements. Each topic element has the
same property (xlink:type) by not the same xlink:type value. If a topic
contains other topics, it takes the xlink:type="extended" value. If the
topic is an link to a resource, then its xlink:type attribute takes the
value "locator". I have found that to encode links as found in portal the
xlink constructs reduce the number of elements required compared to other
kind of encoding like for instance RDF. Also, the main difference is that
contrary to RDF encoding, it uses links and then these links can be
interpreted by xlink engine. You'll see with the example, that you can
create your own xlink engine with XML to DHTML transformation using XSLT.

The Portal document using xlink can be accessed with the following address:
http://www.netfolder.com/XML/topic.xml?query="news". The XML server is not
yet sophisticated enough to recognize the user agent type and adapt to it
(this is my next step). When that will be the case, the server will
recognize the user agent XML rendition capabilities and do the
transformation server side for non-xml browsers (i.e. HTML browsers).
However, if you have IE5, the xml document can be rendered. to do so, I had
to do some minor modifications to the style sheet like removing the
<xsl:output> element and changing the name space URI. Otherwise everything
else is the same as the original style sheet tested with XT. Here is what's
happening behind the scene.

a) the XML server receives the query
b) the index server is queried (actually this is hardcoded since I am
developing it so you'll always get the news topic whatever you type in or
not type in - the news topic is my default test query). The index server (an
Alta Vista engine) uses the "news" category, get from this category the
query to be applied to the index server, do the query to the Alta Vista
index and return an XML document composed of the following hierarchy
netfolder
    |___ topic
           |__ topic

a netfolder is mapped to a Portal widget as found in Yahoo (in fact you'll
recognize that this portal page has a Yahoo style).
c) An XML document is created with a <document> element used as an enclosing
element. Then a style sheet PI is inserted (usually the style sheet is based
on the user profile - but not in this test version). When the final XML
document is composed, then it is sent to the user agent.
d) the user agent renders the XML document using the XSLT style sheet which
in this case act an XLink engine. This engine has a model where Xlink
extended element are listed with their content displayed as usual
uni-directional links. An other kind of Xlink interpreter created with XSLT
could as well use a menu metaphor to render the links (or any other kind of
user interface element that you can imagine with xlinks)

What is different from a usual HTML portal document? Simple, what is
transferred to the client is the model not the appearance. The client may
store the document, syndicate it, modify it, store it in a database, etc..
Otherwise, if you get an HTML portal page you'll have to know the HTML
document structure and extract the information. if the Portal modify the
HTML page, your information extraction script may no longer work. Also, it
could be possible to envision some browsers sophisticated enough (and I have
in Didier's labs doing that) that could have different ways to interpret
xlinks based on several stylesheets. Then the user may decide (client side)
how to interpret the links (for instance, with a portal widget or with a
menu)

Off course, to render the XML document you'll need the IE5 browser. But, to
support browsers legacy the XML server will, in a near future recognize the
user agent and allow the transformation to occur server side or client side.
As we saw in the famous last week thread, at least a third of the browsers
will render the document client side (this is an average and numbers may
differ for different site attracting different type of clients - i.e. early
adopters, visionnaries, pragmatists, followers, laggards). Thus only 2 out
of 3 client require server side transformation.  Some site will attract
laggards and the numbers may be 3 out of 3 server side transformation or
pragmatists, in this case 1 out of 3 (client side) or Early adopters (2 out
of 3 or 3 out of 3 for client side transformation). At the end of the year,
probably we'll have an average of 2 out of 3 client side transformation. In
this case, this does not impose too much strain on the server. And XML +XSLT
rendition can make a lot of sense.

I see some problems however for Portals with this new model since, what is
rendered is like before but what is sent to the client is the information.
Thus, developers can do queries to servers, get the information, repackage
it, add to it a new XSLT or CSS style sheet and then get a new page. In this
case, the word information aggregation or information syndication takes all
its sense but from the intellectual property point of view, this is a real
nightmare.

Anyway, this is fun to see that Xlink can be used also for portal widgets
(which usually contain links to other sites).

Cheers
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: Web New York (http://www.mfweb.com)
Book to come soon: XML Pro published by Wrox Press
Products: http://www.netfolder.com

Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: Web New York (http://www.mfweb.com)
Book to come soon: XML Pro published by Wrox Press
Products: http://www.netfolder.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Unsubscribe by posting to majordom@ic.ac.uk the message
unsubscribe xml-dev  (or)
unsubscribe xml-dev your-subscribed-email@your-subscribed-address

Please note: New list subscriptions now closed in preparation for transfer to OASIS.