[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: Thu, 11 Feb 1999 10:42:38 +0000
html pagination css
Hi.

An interesting post, and one that gave me pause for thought.

I believe it's the WGs aim to get the whole package out by August including
FOs, I am not aware of any slippage in this area, but then again I haven't
been tracking this very close the last month.

As to when FOs will be supported, certainly not until tehy become a final
Rec. I would urge however that we not persue the arguement that "That bit's
going to be a while comming, so we need not bother". If we applied this
attitude to standards we would have precious few, including CSS2.

CSS is easier than FOs, but the equation in one of CSS+HTML, which even at
a simple level I would suggest is not, and if one where to take exception
to that I would suggest that expressing pagination in CSS+HTML is not
simpler. You're arguements don't even begin to address the needs of our
brothers in print design, they wont be impressed by your suggestion that
they should use CSS+HTML.

Your point d) seems to lead on to suggest that the standards should only
follow implimentation, This approach again would kill nearly all the Web
standards we have. Also movements like WaSP have been established due to
the outrage at the ensuing chaos of implimentation running ahead of
standards, hence the nightmare that was HTML 4 + CSS browsers
implimentations.

You then return to say 90% of all implimentation are transformative, so
that can be taken as the definative decisiion. I would suggest as I have
before that this is a rediculous stance to take for a standard not yet
complete, aspecially for FOs. Everybody knows that neither MS nor NS will
impliment FOs until they're set in stone, as it requires serious reworking
of aspects of their browsers. They aren't going to do this while stood on
shifting sand, they'd be nuts to. I regard your line of reasoning here as a
non-arguement and against all reasonable expectations.

On your own practical working practice, I simply respect that that is what
you like and percieve to be "a good thing", and I wouldn't seek to knock it
at all, we are all entitled to choose our prefered methodologies.

What I will add by way of expressing my own preferences is that in the work
I do I would like to kill HTML stone dead. As a mark-up expression it is
now more hinderance than a help. This is evidenced by the fact that I now
only use two elements from HTML, predictably, DIV and SPAN, the rest have
little bearing to what I'm matking-up. I am by using DIVs and SPANs
efffectively creating my own FOs. I would prefer there to be a standard set
of FOs..... but this arguement is already well expressed by others
elsewhere.

Cheers
     Guy





xsl-list@xxxxxxxxxxxxxxxx on 02/10/99 10:21:47 PM

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




Hi Guy,
I'll tell you my biggest concerns:
a) That the final spec that includes formatting object won't be out before
next year.
b) There won't be any browser that includes XSL FOs until one or two years.
c) CSS is easier  to use for Formatting objects on the client side and
browsers are catching up CSS1 full implementation. So now imagine for CSS2.
d) A spec is nothing only implementations created by manufacturer is
something (a pragmatic point of view). So, Why get mad about manufacturers
who created real stuff? big manufacturers have interest that the spec isn't
fully completed until there ready. Small manufacturer don't. Status quo
favor big manufacturer and re-enforce actual status quo situation on the
market. So, the question is: all ISV happy that more and more the software
ecological system is more and more occupied by single specie? Status quo
encourage this by putting delays in the process.

But also I'll tell you what can re-assure me:
a) nothing speak more than action. If 90% of all XSL implementations
including the big guys implementation are XSL transformation then that's
it,
for most of the population XSL is transformation only. Manufacturer should
not refrain themselves from calling their implementation XSL even if it
only
contains the transformation part.
b) XSL will be more popular on the server than on the client. CSS will be
more popular on the client. XSL will be mostly used to transform XML into
HTML+CSS for very practical reasons.
c) The majority of the market on the server side is owned by apache and
therefore there is room for manufacturers others than Microsoft and AOL
(Hoops. sorry, Netscape) to provide XSL engines and that is good for ISVs.
As soon as XSL reach the big developers market, demand for new features
will
abound and these engines will move from ideal driven to market driven.
d) W3C won't necessarily favor small manufacturers (ex: look at W3C style
sheet page, only certain manufacturers links are present and do not reflect
all current implementations. There is a certain censure) W3C will favor
first its member and we shouldn't expect more it is not in W3C gene to do
so. If manufacturers do some form of sane coopetition they have more power
than they think they have.
e) XSL transformation already showed its utility and with some ingenuity
could do a lot more. Again, action talks, concrete example will provide
more
to potential users than concise specs.
So, we demonstrated that our group could be as divided and diverse as W3C
workgroup. This is a good thing, we don't suffer from group think. If this
group where under IETF hospices it would have already improved a lot the
specs. In one word, I am impressed by the quality of this group.
Now practical things:
I am experimenting on domain language translation using XSL, so far, I am
surprised by the potential this language has for this. If section 2.2
stays,
or if implementations keep that (because it is a good thing) we have
certainly some potential here.
I am using more and more HTML+CSS as a formatting language. I like the
voyager module segmentation that is re-using Hytime modele mechanism. So, I
can pick the proper formatting object from these modules. So, in my
practice, I got used with XSL for transformation and HTML+CSS for
rendering.
I don't care about XSL fOs they don't give more than what I have now with
HTML+CSS and I don't have again to learn new stuff but re-use my knowledge
of HTML+CSS (If we speak of knowledge management, knowledge re-use is also
very economical and I guess that a lot of Web developers will think the
same). Anyway, a browser understanding XSL FOs is not until 2 to 3 years
from now and a market having 90% browsers with XSL FOs not until... You got
the point?
I am also experimenting to create macros that implements Formatting objects
for other formats (tex, rtf, etc...) the idea is to use these macros within
templates to create the desired output. From the specs (actual, as written)
it should be feasible. I am trying this on different implementations, so
far, didn,t went far on this, most of them do not work well with macros.
(macros could be very demanding for XSL interpreters as I already
experimented with DSSSL macros that blown away Jade).
In one word, as long as already existing implementations (with source code
or binaries) support transformation, what I really use is the
transformation
part. So, for me, actually as it is for 90% or more of actual users of XSL,
XSL is de facto a transformation tool and CSS+HTML a formatting/rendering
tool.
I am also writing a paper that compare CSS, XSL and DSSSL. To write this
help me a lot to understand the strengths and weaknesses of each. And also
by keeping a eye on practical ends, put these into perspective like: using
DSSSL and HTML+CSS as formatting objects, same thing for XSL, The
difference
I have if I use HTML formatting object stand alone and the same objects
with
CSS (either with the style attribute or the class). The fact that actual
browsers formatting language is HTML+CSS put transformation language into a
different perspective, As soon as DOM 2 is implemented, a browser may be
used to render any language and that is interesting too because it opens
the
door to other formatting/rendering languages.
also on the work articles on: How to use browsers to create SGML electronic
books (like ATA 100, etc...), XML based e-books, How to use topics maps to
organise a collection of XML/SGML documents (also alternative formats like
PDF, EPS, etc..)
In all these activities I use XSL as a tranformation tool because I have
plenty of tools to experiment with. This is not the case with XSL
formatting
objects. Sincerely, Guy, did you do any stuff with XSL formatting objects?
I
doubt. So, XSL transformation has already a big momentum and that is not
the
case with XSL formatting objects and that is obviously for practical
reasons.
Lessons to remember: Actually if you look at most sites talking about dsssl
they also mention Jade as the implementation (also in other parts of the
world they have other Jade derived tools). Jade is often 99.5% of the time
presented as a DSSSL implementation even if it don't support the
tranformation part. So I don't think that manufacturers should be afraid to
call their implementations XSL. We already have jurisprudence that the
market give the name to real stuff not the piece of paper that inspired
this. So let's call the transformation part XSL and for most people,
formatting objects will be a version 2 and probably XSL will be more
popular
as a tranformation tool. W3C get a good occasion to show some common sense
but a chapter is not governed necessarily by that but also by political
pressure of its member and the limitations of the charter. Manufacturers
int
his story already showed that they have common sense. Of course, they have
a
market to serve.
Now let's go back to my lab, I repect your desire for status quo and I
still
support Paul's efforts to gets things moving and clarified. Always two
forces present in any group. My hope, the future of XSL is more in the
hands
of those implied in the action.
Regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com

 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.