This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: xslt and fuzzy logic


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]