cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott_B...@lotus.com
Subject Re: Content view separation... are we making a mess? ;-)
Date Mon, 25 Sep 2000 22:35:53 GMT

> #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)

I would very much like to see some examples of what you're thinking.  Can
you create a small example transform specification with this logic in it?
I'm still not sure what should be in the syntax in this regard.  Are you
thinking of something like the HTML meta command that can tell how often
the update should be done?

> 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.

I'm not sure what to do about this.  Names are important.  If we could only
agree on what they mean...

If this is such a factor, why not create XLT, that is a superset of XSLT,
does not allow xsl:stylesheet, and adds a few things like the cache control
you're talking about?  It would be a lot better than total redundancy.

> 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.

A general solution needs to address that generality carefully.  I agree, if
you can not accept this and the limitations that come with it, then you
probably don't want this solution.  There are a lot of decisions made by
the WG that I don't agree with, and I wouldn't mind making changes in the
process.  I still like XSLT.  And XML probably wouldn't be what it is (for
better and worse) without the W3C.  Where you find fault, you should also
give some credit.  I've seen a whole lot of folks say that XSLT should do
this or do that.... it's the working group's job, as a group of people who
are very familiar with all the ugly and intricate details, to try and find
the right balance.  It's actually a pretty thankless job... (to quote James
Clark directly).

It sounds like you are firm on XSP, which I don't mind, I would just prefer
focus on XSLT, if that were the right thing.  So be it, I just wanted to
give my perspective.  Thanks for listening.

-scott




                                                                                         
                         
                    Stefano                                                              
                         
                    Mazzocchi            To:     cocoon-dev@xml.apache.org               
                         
                    <stefano@apac        cc:     Ricardo Rocha <ricardo@apache.org>,
Steve Muench                  
                    he.org>              <smuench@us.oracle.com>, (bcc: Scott Boag/CAM/Lotus)
                     
                                         Subject:     Re: Content view separation... are we
making a mess? ;-)     
                    09/20/00                                                             
                         
                    07:16 PM                                                             
                         
                    Please                                                               
                         
                    respond to                                                           
                         
                    cocoon-dev                                                           
                         
                                                                                         
                         
                                                                                         
                         



Scott_Boag@lotus.com 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
moment.

> > 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
something.

> 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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------







Mime
View raw message