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

Re: why split? [was RE: XSL intent survey]

Subject: Re: why split? [was RE: XSL intent survey]
From: Guy_Murphy@xxxxxxxxxx
Date: Tue, 24 Nov 1998 10:41:07 +0000
xml split object
Hi Oren.

If consensus is that trnsformation is secondary then fair enough. Personaly
I can't get my head around it being this way round my heads going round in
a loop saying "but you transform *to* formatting objects" therefore the
transformation comes first. It doesn't matter what formatting object you
have, or how they're implimented, if you can't transform XML into them
they're no good to you... to my mind this places transformative concerns
first.

Also given that I may not want to use these formatting object (personaly I
probably would prefer them), I may want to transform to well formed HTML,
in which case I'll only ever use the transformation part of the language.
Also, how long will it be before browser rendering engines support these
formatting objects?

Think on it this way... I can run XSL transformation on a server, not using
formatting objects, simply using the transformative part of XSL, delivery
HTML to the client browser. Given the wide ranging support for HTML 3.2, on
a practical level I need never worry about the rendering abilities of the
client.

Unless XSL can play to this strength, it will fall into the same problems
as IE and NS have done with CSS rendering, with it's formatting objects,
and I don't see that we'll be that much further down the road.

In short the scenario I describing is en effective replacement for the
likes of ASP and PHP on the server when dealing with XML. If I can't
process XML with XSL and get the desired result tree I wanr, then I'm
pretty much going to stick with an ASP/PHP like option. I suspect that many
other developers would make a similar choice.

I'm not arguing that the formatting object shouldn't be there, they should,
simply that I want to be confident that I can get to the flow objects I
want (deliberate use of the term because they may not be XSL FOs) before I
concern myself with what they are. If I can't get to them they're useless
to me.

Cheers
     Guy.





xsl-list@xxxxxxxxxxxxxxxx on 11/24/98 04:17:05 AM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  Re: why split? [was RE: XSL intent survey]




Guy_Murphy@xxxxxxxxxx wrote:
>... So we'd have transformative declarative syntax, with optional flow
objects,
>and optional scripting. To my mind (and I realise
>everybody has their own biased interests) this would be an appropriate
>order for prioritising consideration.

This is fine, except it places the transformation issues "before" the
formatting. This whole thing started when it was pointed out that the
transformation issues were secondary - if you go by the original intent.
You
get a different language if you want a "transformation language with
optional formatting" or a "formatting language with some transformations".
This isn't just playing with words - each part requires a lot of effort to
do well, and there's only so much to go around. There are also downright
conflicts - with regard to the language complexity and intended audience,
for example.
Have fun,
    Oren Ben-Kiki

 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.