[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Venting

Subject: Re: Venting
From: Guy_Murphy@xxxxxxxxxx
Date: Fri, 5 Feb 1999 17:46:08 +0000
andy phillips oracle
Hi.

Your point is well made.... would anybody care to suggest that Calculus be
split away from maths because it has uses that don't require the rest of
the maths bagage?

If only a part of XSL is of interest to an individual, cool. Nobody is
suggesting that they have to use every single expression within XSL. Just
because somebody doesn't express interest in another part of XSL doesn't
mean that that part should be thrown out.

For me, the transformation and the formatting are both essential parts of
expressing style. I understand if this isn't so for you.

Some vendors may want an XTL, a generic transformation language, without
formatting. If so *go make one*, please don't hijack XSL as a style
language.

We have vendors on the list comming forward saying that because they only
impliment the transformation they can't declare 100% XSL compliance (an
impossibility at this stage anyway), so please hack off the formatting. I
must be missing something here, as I respect the intelligence of the people
gathered on this list.... but I can't see why. The purpose of XSL isn't to
produce a generic transformative language, but a styling language. If good
transformation is a side-effect all the better.

People saw the potential of XSL pattern matching syntax, and wheren'y
interested in the formatting. They didn't try and hijack XSL... they
instead went off and talked about XQL based upon XSL pattern matching. If
you don't want formatting go develop XTL in any which way suits you. XSL
however is for styling. If it doesn't serve your need for inter-process
communication, go find something that does, if it doesn't deal with 101
other transformative needs tough... *it's purpose is styling*.... can we
please remember that.

If we decide that we don't need transformation for styling, why did we
waste all this time, we could have just beefed up CSS some more? But as has
been discussed at length, we do need transformation with formatting for
styling hence XSL.

Why should I worry about the language being split, and the transformation
part being carried off, and moulded to a more generic purpose, then layered
with FOs.... becaus then the focus wouldn't be on producing optimal
transformation for styling, and I fear it would get bent in several
different directions, none of which have anything to do with XML styling.

Cheers
     Guy.





xsl-list@xxxxxxxxxxxxxxxx on 02/05/99 07:37:45 PM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:   aphilips@xxxxxxxxxxxxx (bcc: Guy Murphy/UK/MAID)
Subject:  Re: Venting




Thu, 04 Feb 1999 11:25:18, Paul Prescod writes:
 But there will always be transforming parsers because *they are useful*.
[SNIP]
Would anyone argue that Calculus should be taught and used only with
Physics?  Are transistors only to be used with telecommunications?  Should
the wheel only be used with farm equipment?  XSL's transformation language
may not be in the same league as these other inventions (some on this list
may argue that point), but the analogy holds.
[SNIP]

Sincerely,
Andy Philips
Oracle Corporation
My opinions may not represent those of my employer.



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list






 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.