cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Content view separation... are we making a mess? ;-)
Date Wed, 20 Sep 2000 23:16:49 GMT wrote:

> > The similarities are big and evident, but either XSLT 1.1 looks at the
> > server side with a wider look or we'll keep cloning XSLT functionality
> > in XSP and continue on our own,
> I think Steve and I would be happy to work with your requirements for this,
> and take them back to the XSL WG.

Ok, this is something I want to do.

> > also continuing the work on SiLLy
> > (Simple Logicsheet Language) to make it easier to create taglibs (which
> > are our response to unportable XSLT extention, so XSLT 1.1 might change
> > this picture)
> Can you point me to information about this.  I would be really interested,
> esp. since I'm part of the W3C effort to make a portable extension
> specification.

Ricardo was working on it.... but I believe he's not responsive at the
> > Comment appreciated (I also copied Steve and Scott that might want to
> > talk about what the XSL WG is doing about this and plan to do in the
> > future)
> I'm not sure I've distilled your message into requirements that we can take
> back to the WG.  That said, there has always been a tension between the
> server-side and the client-side in the WG.  At Microsoft, it looks like
> ASP++ has won out over XSLT, which I think is too bad.  I maintain that a
> language that covers both the client side and the server side gives major
> flexibility for application architectures.  Something that starts out on
> the server, may migrate down the line to the client.

Not if 90% of the client market is owned by microsoft :/
> If you have a hammer, yes, everything looks like a nail.  But, in this
> case, the XSP hammer and the XSLT hammer look to be pretty close to
> identical, and getting more so.

I agree about it, but there are still things that XSLT lacks that we
cannot accept:

 1) no portable extentions
 2) no caching semantics
 3) overall naming
 4) no political shit to go thru if you need to change something

I understand you are working on 1) so we will remove it when it's gone.

#2 means that you need a way for server side caches to call specific
logic to estimate if the cache must be reprocessed or not. XSLT has no
notion of this (even if I believe it can be added with no big changes)

For #3, tell me, how can I honestly go to users and say that they have
to use something that is called "extensible stylesheet language for
transformations" to create compiled server pages that do not transform
anything nor happen to have anything to do with style?

Believe it or not, naming IS an issue and a pretty big one.

Which leads us to #4: I cannot advocate the use of a technology I cannot
influence directly. So the WG must either give us *good* reasons for not
accepting our proposals (even name change and WG plitting!!!) or we keep
doing our stuff which we are perfectly happy with.

> I think we could accomplish more if we
> combined resources to make a single shiny hammer capable of hitting both
> nails at the same time.

I agree with this, but I still *have* to see something moving from the
WG side.... from now, in the meanwhile, no user has requested this
merging, only people coming from the XSLT world... this tells me

> Sorry, I know from past conversations that you don't agree with me.  But
> that's my two cents based on my perspective.

I agree that the capabilities of XSLT are overlapping 90% with XSP and
this is going to be increased in the future.

I also agree that would make perfect sense to unify efforts.

But the way you guys write specs is not compatible with the way we like
talking about specs, and none of us has the time/energy/will to go thru
W3C shit because of this... 

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message