Re: Cascading. ( Re: Recursive Template Application )

Subject: Re: Cascading. ( Re: Recursive Template Application )
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Tue, 20 Jun 2000 20:52:40 -0700
From: Matt Sergeant

> > >  What I was saying was that you shouldn't have to specify the
> > > stylesheets on any command line or in the querystring.
> >
> > Why?
> Same reason you should use DOM and not some other invented API.

*Very* suspicious point. There are many usecases when it is *much*
better not to use DOM, but to use embedded XSLT engine or one of
proprietary XML -> Java class mappers. DOM is just yet another API.
Democracy is always good. If following your logic,  perl should not be
developed, but it should be killed before it has been born,
sacrificed for the sake of some ANSI-cerfitied thing which existed
at that moment.

There are APIs which are good for some task and there are APIs
which are bad for some tasks. I can't belive that usage of API
not suited for some task is in any way smart, even the
API is labeled 'standard'.

> Note the english in use here: "shouldn't have to". Not at the exclusion of other
> options.

I'm not saying ( and I was not saying ) that "you should not use cascading".
I'm saying that "you are better not to use it, because hardcoded binding
is not scalable".

> Sure. Absolutely. You're free to do that. But you're missing the reason
> I'm doing server side XSLT: eventually I want to deliver direct to the
> browser. To do that you have to follow the spec.

Lets call this "Point 1".

I *have* to? I'm definately missing the reason, or there is again
something wrong with my English ( I apologize,  if English  is
the case. I also can apologize in anvance if anything else is
the case.)

I don't understand how client-side rendering benefits from
making server-side rendering 'cascading based'.

cat some.xml |  aggregate.xsl | expand_widgets.xsl  |  render2html.xsl

To me this eventual rendering on the client is just changing the
last component in the pipe ( the rest : layering, tuneability e t.c. )
remains the same.

> > > (Note that for anyone interested in AxKit put off by this because it
> > > doesn't scale well to 1000's of XML files, its all overrideable in various
> > > different ways that do scale better)
> >
> > What do you mean?

> I mean it doesn't have to work this way.

Oh! That means you are already providing non-standard way of cascading!
This is good ;-)  Because this slightly contradicts "Point 1" - could  you please
elaborate a bit more on this 'non-standard'  way? ( Something tells me that
there is a big chance that users of AxKit will use that  *alternative* method
of cascading, but not the 'standard way'.)

> People with experience in
> building large scale systems based on Cocoon 1 will be the first to tell
> you that adding <?xml-stylesheet?> PI's to every document is a pain in the
> ass.

They better to tell it to Cocoon team. I was never thinking or saying
that <?xml-stylesheet?> ( or any other PI/road-sign ) based method
of binding is the way to go.  I'm constantly saying  the opposite. ;-)

> So AxKit allows you to work however you want to work. It just happens
> to default to the <?xml-stylesheet?> way of working.

Not yet questioning why did you placed w3c cascading to be a default
( 100% correct step from marketing point of view ) -  I'm realy very
interested in alternative way used in  AxKit ( because,  as I said many
times, I very much respect your engeneering skills).  Mind to elaborate?

> > In AxKIt XSLT transformations  don't have access to parameters ?????
> They didn't until tonight. Just added that code. Remember that XSLT on
> perl is very young, and AxKit is younger still.

I'm sorry - I used a bad wording. My goal was to 'protect  XSLT',  rather
than blame AxKit. Because I'm constantly  using XSLT with parameters
it was just some emotional cry : "What??? I'm using this every day!!!"

It was similiar to my reaction when ANSI killed Borland's *extremely*
useful DDVT syntax extension

class Window {
    void MouseCallBack( Event e ) =  [ BASE_HERE + EVENT_ID_HERE  ];

... this  ANSII step kinda killed OWL - but that's another sad story.... I have
plenty of sad stories ... ;-)

> Please limit your flames. You're using very derogator terms there. I just
> said I added that facility. I said above it didn't do it "yet". It does
> now. Happy?

Yes, I am shameless and happy. With your change,  more people will try
to write parametrized XSLT stylesheets in AxKit. Then they will start
questioning why can't  they access persistant sessions from XSLT
stylesheet, then they'l start questioning some other things and
then they'l finaly download Ux. ;-) More  XSLT users who are writing
complex XSLT stylesheets are good for Ux. ;-)  Thank you, Matt! ;-)

> I'm snipping the continued silliness about how <?xml-stylesheet?> is
> broken. If you don't want to use that, then don't.

Sure. That's what I said ( in the reply to your first letter which
started this thread ) : "... or you can used Ux ... ".

Then you said that Ux is not standard, but standards are good
for us. Then I replied that maybe standards are good,  but they
hardly  work for semi-complex usecases.

> I suggest not trying to  invent a new syntax though - write a
> NOTE for the W3C -

...ghm... I'm ...patient ....  ... patient .... OK.

> we as developers need standards , not thousands
> of different techniques for applying XSLT
> styles to XML files.

Maybe  "you as developers" need standards. "We as developers"
need good tools which allow "us" to write some stuff  that  works
and to do it fast, but supporttable.  If the software which allows
us to write some stuff fast  becomes also standard - that's
realy cool. Unfortunately that  rarely happens. Why that
rarely happens -  that's the question I can not answer,
because I don't know why.

> Its getting stupid now with all the different methods
> available.

It is getting stupid how stupid are the methods... sometimes ...
If some universal method could be explained in 1 paragraph -
that's not a  big deal to read one paragraph, I think.

> > Sounds interesting. But if Salbotron is not SAXParser  you may
> > find that chaining  is not as flexible as you would like, ( for
> > example, there could be no way to do:
> >
> > document("axkit:perl-bean1 | transformation.xsl")
> So make your call to document() a http: request, and have it processed
> directly with AxKit. Problem solved.

Let us  see what happens here.

1. http request -> one more fork of http daemon, network connection
e t.c. - but that's not a big deal, and because there is a word 'directly'
in your solution, maybe you mean some black magic  which saves
this overhead.

2. document("htp://localhost:/cgi-bin/processor.cgi")  - right?

processor.cgi  should write out the *valid* XML.

Any estimate on the overhead here? ( some very much non-optimized  )
code below:

 protected void emitAttrValue(String value) throws SAXException {
     int valueLength = value.length();
     for (int i = 0; i < valueLength; i++) {
    char c = value.charAt(i);
    switch (c) {
      case '\n':   emit("&#10;"); break;
     case '&':    emit("&amp;"); break;
       case '<':    emit("&lt;"); break;
     case '"':    emit("&quot;"); break;
       case '\r':   emit("&#13;"); break;
     case '\t':   emit("&#9;"); break;
     default:    emit(String.valueOf(c));

The similiar thing is with every char  in every chunk
of  *text* in the generated document.

      case '&':    emit("&amp;"); break;
       case '<':    emit("&lt;"); break;
       case '>':    emit("&gt;"); break;

3.  Now document ( "htp://localhost:/cgi-bin/processor.cgi" )
should re-parse XML file back.

I think one could estimate the overhead of XML parsing.
XML parsing is not 'nothing'. It takes some time and... I wish
everyone has becnhmarked  XML parsers ? Especialy when
creating DOM in result of parsing ?

After I did that,  I implemented  clone() method for SQL
templates ( XML files of 20-30 lines lenght ). The time savings
I got  processing one template were comparable to time
saving I got not re-opening the JDBC connection and
in total with xsl.clone() I got the same code running
at least twice as fast. Without re-writes to C.

SAX-based Ux approach has no overhead described above.
When you use 5-7 pipes to  draw some dynamic page,
this becomes important.   Not yet talking about caching -
but that's another story.

> Again - lets not invent a new
> syntax. Lets hear it for standards.

There is some interesting twist with "/! hack".

It looks this way because it is probably the *only*
possible way to get it working with almost any
XSLT processor,  not changing too much code
of that processor. ( It works  with XT not
changing a byte in XT code).

Passing "some_new:" schema down the road will
require changes to / around  core Java libraries.

<note to="W3C">

Dear w3c.

It is me again, the strange hacker who occasionaly turns
XSLT into powerful aggregation / scripting framework.

I know that you are very busy,  developing  some
serious things which most of us can not understand
and use.

I heard that at the moment you allowed XSLT
implementations to support whatever URIs
XSLT implementators want to support.

No surprize, most ( if not all ) XSLT
implementators are assuming that
document( ) will get either URL, or "".

I'm wondering, what if some day you may invent
some standard URI  to invoke pipes of components
with document() ?

( I wish you'l not even get to this level, like you
ignored the extensions/binding  issue, but who
knows ... ).

If that happens, could you please not place any
restrictions on that field before resolving the binding
issues in general ?

document() and namespace-based java binding
are the only hooks to  XLST. Anyway binding
is processor-specifc ( and will be for a while ) -
could you please not restrict the URI in the near

Thank you, dear W3C, you realy did  well with XSLT !
No kidding.


Even w3c will produce yet another URI
recommendation ( it will take years, I think ;-)
and all the XSLT vendors will slowly  switch to
that recommendation - it will take years again
as well.

At that point of time my framework will be *much*
more than it is now and more likely it will not
be based on XT anymore. ;-)

But maybe not. Who knows?


 XSL-List info and archive:

Current Thread