cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@supereva.it>
Subject Re: Content view separation... are we making a mess? ;-)
Date Tue, 19 Sep 2000 20:32:44 GMT
From: <Scott_Boag@lotus.com>
> 
> > 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

Correct, but IMO in Cocoon, transformation is intended as XML2XML
transformation.
Basically ANY2XML is call Generator, and XML2ANY is called Serializer.
Of course all transform something :-)
 
> 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.

XSLT can do all that XSP can do, maybe more.
But assembler can do exactly what C++ does.
There are other matters:

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

Ok, Stefano will respond on this. :-)

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

Ok, Stefano will respond on this too. :-)
 
> > 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?

Ok, so there are no differences, you can use XSLT extensions to do what XSP
does. But it's much more difficult, both for amount of work and for conceptual 
abstraction. XSP is more "natural" for generation.
If you haven't used them yet, please do it, and all will be clearer. :-)
Surely Stefano can be more clear then me.
Anyway, the main difference is that code in XSPs is embedded like Javascipt
in XSLT extensions (don't have to pre-compile first).

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

Not really.
It's horizontal IMHO:

ANY->XML----->XML->->->XML------>XML->ANY

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

It's not a style problem.
Take a sample XSP page and do the same with XSLT and extensions,
then see the difference in time and conceptual clarity and maintainability.
XSLT is difficult because it was made to react to parsing events coming in,
XSP doesn't need that, it's more page generation oriented.

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

IMHO the best thing is to come up with something working, _real_, that can
give us the idea of what is really needed.
If this goes to the XSL WG... even better!

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

Were all interested in SiLLy, where the heck is it?!? :-)
Ok, Stefano will respond on this too. :-)

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

Maybe the time to combine the two is not ripe yet, but it is quite possible
that in the near future they will combine.

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

My reasoning is not based on what can be done or what is more elegant
but on what is needed and how well and easily it works.
XSLT with extensions is _much_ harder to use for the generic user than
XSP.

Comments continue:

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

Possible, hope so.

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

Basically what scott also said. See that you two agree? ;-)

> 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

I'm not so sure...
I used to see it in terms of users: "content writer" and "stylers".
The first use generation, the others transformation.
Of course doing one <content> generation, x <content> transformations, and 
x <style> transformations is much cleaner, but this doesn't change things as
far as contracts are concerned: in both cases the content writer has no
explicit dependancies in his pages to style and viceversa.
A third IMHO correct possibility is having 1 Generation and 1 complex
Transformation.But here the pipeline goes head over feet.
Why do we need it (the pipeline)? Well there are not only Generators, 
Transformers and Serializers in the pipeline. 
We (will) have Actions, Matchers, ecc, that have
to be placed between them.
So more we shorten the pipeline, less flexibility we have.
In this view then, the best thing is to have what Stefano said, I totally agree. 
The sitemap becomes a sort of XML workflow app descriptor.

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

As I repeat, I kindly invite all that are in the discussion, to gain first-hand
knowledge of XSP, using them, and trying _on_code_ differences between
XSP and XSLT approaches. Let's not get too academic ;-)

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

I hope I can finish my first prototype of XTP soon! :-)
I prefer it when there are concrete issues to discuss on.

nicola_ken

Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)



Mime
View raw message