Re: [xsl] XSLT-related Links/News of Interest

Subject: Re: [xsl] XSLT-related Links/News of Interest
From: "M. David Peterson" <m.david@xxxxxxxxxx>
Date: Mon, 05 Feb 2007 18:21:04 -0700
On Mon, 05 Feb 2007 16:18:28 -0700, Robert Koberg <rob@xxxxxxxxxx> wrote:

I have been spending a good deal of time in the browser world and wonder
if this is the best place for MS to place their bet.

Oh, I don't think they're placing their bet on the browser, and instead covering all of their bases.

I mean I see a very small amount of interest in client side XSL (even
though I use it alot).

Agreed, though I do believe that has more to do with the previous lack of cross-browser support than it does with actual interest. When Apple first introduced support in Jan. 2005 for Safari, and Opera then followed up in October 2005 with their initial XSLT support, the lack of cross-browser support is no longer a concern.

Of course, tools have every bit as much to do with this as anything else.
The more tools that provide default support for client-side XSLT, the more
use it would get, though that's obviously nothing profound -- This is true
in pretty much all cases for technology deployment > Go with what the
tools support by default.

What I am seeing is a bunch of ajax toolkits trying to find fast ways to
navigate HTML (not even XHTML) in the browser efficiently.

For what purpose? Navigating the internal tree structure, or for something more along the lines of screen-scraping data? If the latter, while I do recognize this to be a valid use-case, it's a brittle solution, at best, and as we move forward into a more webfeed-oriented world, it would seem to be that the use of proxies and/or JSON will become the prefered method for traversing and rendering data on the client.

Firefox, Opera and Webkit are developing HTML XPath.

Cool! Wasn't aware of this...


Of course the 80% browser has the lead, but more and more browser devs
are going to really like HTML XPath. There will be XPath hacks created
for IE, but it will operate much more slooowly. As rich browser apps
become more prevalent people might notice the difference??

Well, for sure, though it seems to me that it really comes down to where the data is coming from and how it's getting to the browser apps for processing. If the world ahead of us is a world filled with screen-scraping hacks to get data of interest, then HTML XPath becomes a central focus to rendering data on the client. If it becomes more of a proxied webfeed world, then it seems that the standard XML XPath tools would be sufficient. Of course, even with web feeds, you still have HTML embedded into the content payload, so from this perspective, HTML XPath is necessary, regardless.


Does anyone know if HTML XPath is in the works for IE?

Well, not specifically for IE, but as Oleg points out last Decemember [http://www.tkachenko.com/blog/archives/000647.html], there's both the HtmlAgilityPack[1] and, of course, Chris Lovett's SgmlReader[2] which has been around for a good four+ years (if I am remembering correctly.) Both of these *should* be usable inside of a WPF/e application, which would provide some pretty powerful tools

[1] http://www.codeplex.com/htmlagilitypack
[2]
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=B90FDD
CE-E60D-43F8-A5C4-C3BD760564BC

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354

Current Thread