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

say I have an xml file "<person><fn>foo</fn><ln>bar</ln></person>"

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"?>
<person><fn>foo</fn><ln>bar</ln></person>

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 back.

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

thanks,
xiaoming


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] - http://blog.codeeg.com/tails-firefox-extension
[2] -
http://spaces.msn.com/editorial/rayozzie/demo/liveclip/liveclipsample/clipboardexample.html

[3] - http://suda.co.uk/projects/X2V/xhtml2vcard.xsl
[4] - http://suda.co.uk/projects/X2V/xhtml2vcal.xsl
[5] - 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
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
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss


_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss



_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss

Reply via email to