question about client-side xslt rendering (was Re: [uf-discuss]
Microformats vs XML, redundancy)
liu_x at lanl.gov
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
> 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
> --- 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. 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, there are also XSLT files available for download for
> hCalendar/hCard/hAtom which can be used client-side.
> I hope that helps answer your questions, or at least starts down the
> right path.
>  - http://blog.codeeg.com/tails-firefox-extension
>  -
>  - http://suda.co.uk/projects/X2V/xhtml2vcard.xsl
>  - http://suda.co.uk/projects/X2V/xhtml2vcal.xsl
>  - http://rbach.priv.at/hAtom2Atom/
> 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
>> - 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
>> (2) how well is it supported by Microformats tools?
>> microformats-discuss mailing list
>> microformats-discuss at microformats.org
> microformats-discuss mailing list
> microformats-discuss at microformats.org
More information about the microformats-discuss