question about client-side xslt rendering (was Re: [uf-discuss] Microformats vs XML, redundancy)

Xiaoming Liu liu_x at
Thu Apr 27 10:03:47 PDT 2006

This helps a lot, and I still have remaining issues:

say I have an xml file 

In order to use client-side xslt to render this xml file, and make sure 
the result is Microformats-compliant, I wrote an xslt file 
"microformats.xsl", and insert a link to xslt in xml file:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<?xml-stylesheet href="microformat.xsl" type="text/xsl"?>

This file can be rendered in IE and Firefox, because they do xslt 
client-side rendering, so the display is correct, but when I check page 
source, it's still the raw xml file. And when writing a script to fetch 
Microformats fragments, I have to do XSLT rendering first to get HTML 

So I am wondering if the above scenario is a good practice, and how well 
it's supported by current Microformats tools.


On Thu, 27 Apr 2006, brian suda wrote:

> Microformats can be built on HTML 4.0 and newer, because of this there
> are a few minor issues that make it difficult to depend on client-side
> XSLT. The simplest issues are well-formedness and validity, but simpler
> things like <br> being <br/> and <img> being <img/> are all important to
> XSLT processors.
> The Microsoft Live Clipboard uses XPATH, but not XSLT on the client-side
> with javascript. All other implementations that are using XSLT are doing
> so server side, for several reasons.
> 1) you can clean-up the input
> 2) you can manage errors better
> So to answer your questions:
> (1) is this a solved problem? does Microformats encourage (allow) this
> practice?
> --- i don't think this is a solved problem (althought i'm not sure what
> the problem really is?) There are several client-side implementations
> such as Tails[1]. I think a combination of client-side and server-side
> options are important. Server-side options are important for content
> developers, by using these web services, site owners can link to them
> and have their vCard/iCal/AtomFeeds all created for a user no matter
> what their browser. Client-side options are important because they can
> be used to find encoded data, and have the ability to extract data that
> is behind authentication - something server-side implementations can not
> really do. The downside to client-side options is adoption of the tools
> to do so. Tails is great for Firefox, but there currently isn't that
> support for IE (i don't think IE applies XSLT transformations either?
> partly because they do not use the application/xml mime-type - someone
> will correct me if i am wrong)
> (2) how well is it supported by Microformats tools?
> Well if it is client-side then the biggest tool at the moment is
> Tails[1], there are also XSLT files available for download for
> hCalendar[4]/hCard[3]/hAtom[5] which can be used client-side.
> I hope that helps answer your questions, or at least starts down the
> right path.
> -brian
> [1] -
> [2] -
> [3] -
> [4] -
> [5] -
> Xiaoming Liu wrote:
>> while we are on this topic, I saw real world examples of generating
>> microformat (well, sort of) by client-side xslt rendering. To put it
>> concrete:
>> - The server generates XML page with link to xslt file.
>> - xslt file includes instructions of generating Microformats.
>> - modern browser happily render the XML page with xslt.
>> - however greasemonkey script or some other tools don't do dynamic
>> rendering by default.
>> So on the positive side, both XML and Microformats are avaiable; on
>> the negative side, this pattern may not be well supported by some tools.
>> My questions are :
>> (1) is this a solved problem? does Microformats encourage (allow) this
>> practice?
>> (2) how well is it supported by Microformats tools?
>> thanks,
>> xiaoming
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discuss at
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at

More information about the microformats-discuss mailing list