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 Tue, 19 Sep 2000 15:53:35 GMT

> Generation is the act of producting XML content without XML input

Generation is part of transformation.  XSP also "transforms" in the sense
that it is often consuming some data.  The only difference is that the
input data is not constrained to be tree-shaped.

> Transformation is the act of "consuming" XML content to "produce" XML
> content

Transformation, as defined in XSLT, is the act of consuming one or more
source trees.  That source tree could be directly produced from a database,
or could be simply an empty root node.

> 1) XSLT 1.0 has no notion of compiled stylesheets

This is simply wrong.  XSLT is a language, not an implementation.  Compiled
stylesheet fit perfectly into the XSLT processor model.  BTW, Joe should be
checking in the first shot at unrolling the loops in XSLT to produce Java
source code that is then compiled into a "compiled" stylesheet, sometime
this week.

> 2) XSLT 1.0 has no notion of caching (being mainly client-side focused),
XSP 1.1 will.

Can you explain more what language features are in XSP 1.1 to support
caching?

> 3) XSLT uses XPath while XSP 1.1 will use taglibs names.

I'm not sure of the difference of XSLT element extensions and taglibs.
They look like basically the same thing to me.  Can someone point me to the
proper description of a taglib?

> 4) The XSLT language starts with <stylesheet> or <transformation> which
> is semantically wrong to adopt at a "generation" position: semantically
> wrong automatically translates as "hack" in people's mind.

In my mind:

generation
       |
       ------ transformation
                             |
                            ------- parsing

Each a specialization of the other.  In XSLT, if you are *only* doing
generation, you don't have to use xsl:transformation at all, you can just
do the Literal Result Element as a Stylesheet (though there are limitations
to what you can do to this).

Is this just a matter of having a xsl:generate???

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

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

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

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 think we could accomplish more if we
combined resources to make a single shiny hammer capable of hitting both
nails at the same time.

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

-scott




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



Nicola Ken Barozzi wrote:
>
> This issue came to mind after writing this to Jeremy:
> <before>
> IMHO, or we have a _standard_ and _safe_ way of passing data from
> taglib to taglim ("interface") or none at all.
> As I explained to phone to Stefano, let's say you want to draw a chart
> from data gotten from sql. You have SGL tags inside CHART tags.
> The most linear, logical and Cocoon-like way of doing this is by
> writing a Transformer for the chart!
> It also gives you the possibility to change chart parameters in the
sitemap if you
> wish without changing the xml.
> Charting is not data production, it's data transformation.
> On the other hand, Transformers are more difficult and less speed some
say...
> Well for difficulty I wrote a Transformer that can simplify things, and
are planning
> to make taglibs suitable for transformation (don't hope too much for it
guys ;-) ).
> As for speed... well to pass data around you need an interface and the
SAX
> on is concise enough I think... are you sure it's slower? We should test
IMO.
> And remember: taglibs bloat method size, and for now there's still the
64K limit.
> </before>
>
> Think now of how Transformers and XSPGenerators work:
> XSPGenerators: They get tags from an XML file, elaborate them and
>    send them down the pipeline.
> Transformers: They get tags from the SAX stream, which comes from a
Generator
>    that got them from an XML file, elaborate them and  send them down the
pipeline.
> If we want to separate content and view, we must IMHO have them in two
separate
> files, as per XSL!
> How separate are two tag namespaces in the same file?
> Content writers and stylers have to create and update the same file!
> What use is a Transformer if a taglib with intra-taglib parameter
handling can do
> the same, maybe faster?
> Many Transformers are there only for coding easiness, not for C-S needs.
> IMO this implies that:
> - _all_ content should come from Generators, so we should define a
standard
>   way of taglib result passing.
> - all Transformers must get parameters and proper uri tags from other
files or sitemap.
> - there must be an XSP like way of making transformers and using taglibs
in
> them.

I honestly see truth in what Ken says.

Let me explain a little bit further: in programming there are two
possible ways of doing things: compilation and interpretation.

Everybody knows this.

The problem is determining which is which: would a hardware VM make Java
compiled? does a code morpher(tm) make C utimately interpreted?

You get my point.

Now, let's move this to server side: there are technologies that are
interpreted, other are compiled, other are compiled then interpreted,
other are interpreted by an interpreter that is interpreted (think about
JSSI, where a java program interprets something while being
interpreted).

Ok, the old tune goes: is it faster compilation or interpretation? there
is no answer to this since, to be honest, there is no such thing as
"compilation" since, at some point, something will interpret (execute)
your code (machine code, that is in most cases).

But it's even worse: do you consider a Pentium a JIT because it does
jump prediction? or the PPro because performs register renaming? or
Merced performs on-fly RISC-ification of the IA64 instructions?

But I divagate...

Let's get back to the main issue: generation vs. transformation.

Ken points out that separation of concerns ("SoC" from now on) is
"cleanly" enforced by the use of transformations while nested taglibs
require "blurry" contracts between the taglib writers.

He is totally right.

We must "rethink" our dynamic content generation strategy in terms of:

1) SoC between writers programmers: here taglibs still rule.. we just
have to define CLEAR contracts for taglib creation. I believe the SiLLy
language will make this possible (Ricardo, do you have any update for
this?).

2) SoC between programming concerns: how do I create a graph out of SQL
tables? do I nest taglibs or do I write a transformer?

The key point is: what is generation?

Generation is the act of producting XML content without XML input
(careful here: an XML file on disk is NOT XML input before it is
parsed!!!)

Transformation is the act of "consuming" XML content to "produce" XML
content (so a parser is not a transformer because it doesn't consume XML
content, but streams of bytes)

[XML content is technically a stream of SAX events]

So, is taglib nesting wrong? It depends, but as a general rule

 "Taglib nesting is *wrong by design* when and only when the
  outer taglib touches the XML content of the inner taglib"

So, while a page like this

 <graph:chart type="pie"
background-color="{session:param[@name='background']}">
  <sql:query>select value, years from revenues</query>
 </graph:chart>

is WRONG (should be done with generator + transformer) a page like this

 <sql:query>
  <xsp:variable name="user">
   <session:param name="user"/>
  </xsp:variable>
  <xsp:variable name="certificate">
   <jsse:certificate name="{user}"/>
  </xsp:variable>
  <jini:resove
    space="db"
    user="{user}"
    certificate="{certificate}"
    name="query"/>
 </query>

is not and consider we have 4 levels of nesting

 sql -> jini -> jsse -> session

Ok, the above clarify very well the scope of generators compared to
tranformers in the Cocoon architecture... but a question remains: XSP is
getting dangerously close to XSLT in terms of capabilities and syntax.

We cannot ignore this.

But at the same time, XSP has an augmented syntax (xsp:caching,
xsp:include) that concentrate on the "generation" of XML content and on
page compilation rather than "transformation" of XML content.

The main differences are:

1) XSLT 1.0 has no notion of compiled stylesheets, XSP does (the
xsp:structure and included tags help the programming-language-abstracted
compilation phase). I admit further versions of XSLT with portable
extentions might remove this difference.

2) XSLT 1.0 has no notion of caching (being mainly client-side focused),
XSP 1.1 will.

3) XSLT uses XPath while XSP 1.1 will use taglibs names.

4) The XSLT language starts with <stylesheet> or <transformation> which
is semantically wrong to adopt at a "generation" position: semantically
wrong automatically translates as "hack" in people's mind.

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

Hope this explains my thoughts well on these issues because we have to
get going.

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)

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