Content view separation... are we making a mess? ;-)

[Nicola Ken Barozzi <ni...@supereva.it>]

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.

comments, anyone? :-)

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)

Re: Content view separation... are we making a mess? ;-)

[Stefano Mazzocchi <st...@apache.org>]

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