This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: xslt and fuzzy logic
- From: Wendell Piez <wapiez at mulberrytech dot com>
- To: xsl-list at lists dot mulberrytech dot com
- Date: Thu, 24 Jan 2002 13:57:09 -0500
- Subject: RE: [xsl] xslt and fuzzy logic
- References: <60A8664AEEB2D511B631000476AAB1A386CD32@ma-atl81>
- Reply-to: xsl-list at lists dot mulberrytech dot com
At 11:44 AM 1/24/02, Bryan wrote:
>thanks, I like it, but I was thinking more along the lines of what way would
>one do fuzzy logic in xslt 2.0, and could one handle the computation without
>big drain on resources.
Well, XSLT 1.0 was not designed with heavy computation as a primary use
case. Rather, the expectation of its designers would be that you would
already have done your computation by the time your stuff was in XML, and
XSLT would be for getting it into a nice pretty human-readable form.
It's like using a Model T Ford to haul furniture around. They were only
trying to make a little buggy for you and your girlfriend. You're saying
"Hey I could haul furniture around" but they haven't designed the pickup
truck yet.
> However it was helpful in that I'm currently having
>to do a lot of generation of xslt from xml, and it had some things that gave
>food for thought, this is a problem, it seems when people generate xslt from
>xml it's very difficult to get a proper balance of xml, either the xml is
>too simple and one can't derive much benefit from it, or the xml is too
>complex and approaches the nature of a scripting language. (and who wants to
>learn a new language?) :)
Nor was XML designed to provide a syntax for "languages" in the sense of C,
Java or Perl -- or XSLT -- but rather for *markup* languages, which is
quite a different kind of critter. If you have an application that can
really make use of semi-structured data and can use XML for storing and
managing it, this balance may be easier to find. There's a big difference
(even given an interesting overlap) between designing the structure of a
data set, and designing a grammar to be interpreted or compiled for execution.
The overlap is in using XML to design a processing specification or even,
like XSLT, a declarative language. I don't have experience in this area
(I'd like to hear from readers who do) -- but XSLT itself "approaches the
nature of a scripting language" doesn't it? (And there are those who feel
its XML syntax is, on balance, a liability not an asset. I say "well it
depends" -- again, on the problem you're trying to solve and how close that
is to the class of problems XSLT was designed for.)
But check out an interesting article at
http://www-106.ibm.com/developerworks/xml/library/x-sbxml.html?dwzone=xml.
Anyway, food for thought, for sure. It's cool to hear about people trying
stuff like this!
Cheers,
Wendell
======================================================================
Wendell Piez mailto:wapiez@mulberrytech.com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list