more on XML style scripting elements (was Re: cvs ... JspUtil.java Parser.java)

[Danno Ferrin <sh...@earthlink.net>]

What would constitute "fully cooked?" In light of this I think it may be
good to nix the existing XML tags in the current implementation.  The spec
points in one direction, but the full implementaiton of those suggesstions
is lacking right now and seems rather arbitrary.  In fact it  says it is a
standard mapping that is not visible to JSP1.1 containers.  In that sense it
would imply that we shouldn't use it on one level.  On another level I would
rather see an optional feature either not there or "fully cooked" in a
release.

Things I see as needing more cooking:
* Empty tag handling for some of the Scripting elements (such as
<jsp:scriptlet/>)
* Whitespace in non-empty scripting tags (<jsp:scriptlet   >
* Not freaking out when a properly namespaced attribute is used in a
standard or taglib action
* Handling of request time attributes within a jsp:root element.  BTW, it is
"%= ... %" or "%= ... '%" (is the internal single quote an editing artifact
or meant to be there?  the line break makes it confusing but I think the
answer would be yes it is an artifact.)

--Danno

----- Original Message -----
From: "Hans Bergsten" <ha...@gefionsoftware.com>
To: <to...@jakarta.apache.org>
Sent: Tuesday, December 21, 1999 8:21 PM
Subject: Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler
JspUtil.java Parser.java


> Danno Ferrin wrote:
> >
> > -1, it breaks the snoop example.
> >
> > But I'll +1 it if the snoop example is fixed (real easy..... patch
follows)
>
> I suggest fixing the snoop example to use <%= %> instead, since the XML
> equivalents are not fully cooked yet and should not be used in the
examples.
> I'll fix this later tonight or tomorrow if no one beats me to it.
>
> Hans
> --
> Hans Bergsten hans@gefionsoftware.com
> Gefion Software http://www.gefionsoftware.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>

Re: more on XML style scripting elements

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

Danno Ferrin wrote:
> 
> ----- Original Message -----
> [snip]
> >
> > How much effort would it take to make the parser "fully cooked"?  If it's
> not
> > exhorbitant (and we had volunteers willing to do it :-), I'd rather see
> that
> > happen.  Otherwise, I'm +1 on removing the current "half baked"
> > implementation.
> >
> > >
> > > Hans
> >
> > Craig
> >
> 
> +1 on removal
> 
> The biggest problem I see is that the spec seems to encourage a total
> seperation of XML representation and of the normal JSP representation of the
> scripting elements.  Most telling is the line that mentions that segments
> that do not correspond to scripting elements should be enclosed in CDATA
> blocks.  Whereas in previous specifications intermingling non-significant
> elements with significant elements was tacitly permitted as long as the
> document was well formed (even though it would be impossible to validate it
> with a JSP DTD).
> 
> But in order to implement the XML stuff with intermingling of tags a
> non-exhaustive list of needed additions are:
> * Handling Empty Elements
> * Handling XML style request values in action elements (foo='%= %' vs
> foo='<%= %>')
> * Some whitespace handling exists, but it needs to be tested
> * in theory namesaced attributes should be acceptable to all of the XML
> tags, especailly when it comes to the jsp:root element
> 
> To me it seems that the easiest way to accompilish this would be to remove
> the handling that explicitly exists in the parser for these XML tags and
> make some sort of a internal TagLibraryInfoImpl that would add the proper
> generators and tell the TagBeginGenerator that represents it to no-op in the
> generation.  This would solve the empty elements problem and the whitespace
> problem.  The handler for JspRoot could interact with the parser to switch
> it to a mode where the XML-style request attributes will be accepted, and
> since we would no-op the TagBeginGenerator then we could trap out the
> namespaced attributes passed to jsp:root and handle them as taglib
> directives.
> 
> At the risk of getting into another "what the spec says" squabble, my
> reading indicates to me that the XML and the "jsp page" forms are two
> representations of the same data, and that they are not, under the current
> revision, ment to intermingle but to remain explicitly spereate.  If tomcat
> needs support for the XML stuff I feel that using SAX to fire off the
> ParseEventListener with the appropriate data would be in order.

<applause>clap, clap, clap</applause>

Danno, thank you for introducing this. This will show Sun people, I'm
not the only fool that thinks that the XML syntax for JSP is a _total_
mistake.

It was my very first comment to Eduardo about the JSP spec: XML support
is fake. Totally. The idea is to "place XML stuff to show we care" so
that PR people have something to say when the "what are you doing about
XML" question comes up from the press.

True, Eduardo _is_ concerned about this and Sun _is_ concerned about
their XML support in the Java platform. This is why Duncan got promoted
on the XML side of things. He's the man for these things, he's Mr. Wolf:
solves problems. :)

On the other hand, we have XML which is portable data (content), java
which is portable code (logic) and no way to connect them!!!!

XML Data binding. Yes, for stuff like the Ant build file it works like a
breeze, but try a real complex DTD and you give up thinking about it in
a second.

Also, the whole Servlet platform is _not_ ready to stand the XML
challenges: how do I XSL-transform the output of my servlet? with
servlet chaining? having to serialize and reparse the XML stuff every
time? no way.

People, do you know what Cocoon is? is a solution to current Servlet/JSP
problems. It's another architecture where the servlet is a pipeline of
"a producer, one or more processors and a serializer", where the server
pages syntax (XSP) was born on the XML realm, where the taglib idea is a
mix of namespaces and "logicsheets", where there is _real_ support for
language abstraction (no java hooks in the syntax like "extends" or
"import"), where XML APIs (DOM and SAX) are used to pass content from
one block to the next.

Servlet 2.2 + JSP 1.0 don't work for XML. Cocoon outlines the problems
and proposes solutions.

Is this forking? no. Not at all. I'm already invited to partecipate to
the JCP process of developing Servlet 3.0 and JSP-NG where I'll propose
Cocoon ideas and solutions for integration with standards. There's no
point on going on our own, we know that.

On the other hand, there is a big point where Sun folks and I disagree
strongly: the need to extend JSP rather than create a new language.

For me, the best thing would be to propose something like XSP to the W3C
for standardization. In fact, XSP is an XML syntax, such as XSLT or SVG.
A language that allows data and logic to meet. A language that should
allow the logic to be written in PERL, PHP, Java, ECMAScript, WebL...
you name it.

Sun should design and implement APIs, not XML languages.

What do you guys think about this? I'm sure that if we unite for this,
we can be _very_ effective in changing some people's minds.

Let them hear you!

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

Re: more on XML style scripting elements

[Danno Ferrin <sh...@earthlink.net>]

----- Original Message -----
[snip]
>
> How much effort would it take to make the parser "fully cooked"?  If it's
not
> exhorbitant (and we had volunteers willing to do it :-), I'd rather see
that
> happen.  Otherwise, I'm +1 on removing the current "half baked"
> implementation.
>
> >
> > Hans
>
> Craig
>

+1 on removal

The biggest problem I see is that the spec seems to encourage a total
seperation of XML representation and of the normal JSP representation of the
scripting elements.  Most telling is the line that mentions that segments
that do not correspond to scripting elements should be enclosed in CDATA
blocks.  Whereas in previous specifications intermingling non-significant
elements with significant elements was tacitly permitted as long as the
document was well formed (even though it would be impossible to validate it
with a JSP DTD).


But in order to implement the XML stuff with intermingling of tags a
non-exhaustive list of needed additions are:
* Handling Empty Elements
* Handling XML style request values in action elements (foo='%= %' vs
foo='<%= %>')
* Some whitespace handling exists, but it needs to be tested
* in theory namesaced attributes should be acceptable to all of the XML
tags, especailly when it comes to the jsp:root element

To me it seems that the easiest way to accompilish this would be to remove
the handling that explicitly exists in the parser for these XML tags and
make some sort of a internal TagLibraryInfoImpl that would add the proper
generators and tell the TagBeginGenerator that represents it to no-op in the
generation.  This would solve the empty elements problem and the whitespace
problem.  The handler for JspRoot could interact with the parser to switch
it to a mode where the XML-style request attributes will be accepted, and
since we would no-op the TagBeginGenerator then we could trap out the
namespaced attributes passed to jsp:root and handle them as taglib
directives.

At the risk of getting into another "what the spec says" squabble, my
reading indicates to me that the XML and the "jsp page" forms are two
representations of the same data, and that they are not, under the current
revision, ment to intermingle but to remain explicitly spereate.  If tomcat
needs support for the XML stuff I feel that using SAX to fire off the
ParseEventListener with the appropriate data would be in order.

--Danno

Re: more on XML style scripting elements (was Re: cvs ... JspUtil.javaParser.java)

[Anil V <an...@pacbell.net>]

"Craig R. McClanahan" wrote:

> Hans Bergsten wrote:
>
> > Danno Ferrin wrote:
> > >
> > > What would constitute "fully cooked?"
> >
> > My comment about not fully cooked is based on comments made to this list
> > by some of the people who have implemented the JSP parser, plus the
> > description of the XML equivalents in the JSP spec. To use the equivalents
> > it not enough to replace <%= %> with <jsp:expression> </jsp:expression>.
> > The body of the element must also be encoded one way or another to avoid
> > special characters like < to confuse a real XML parser. As far as I know,
> > the parser doesn't deal at all with these types of encodings.
> >
> > > In light of this I think it may be
> > > good to nix the existing XML tags in the current implementation.
> >
> > I tend to agree, but it's a change I feel requires a vote before it's
> > done.
> >
>
> How much effort would it take to make the parser "fully cooked"?  If it's not
> exhorbitant (and we had volunteers willing to do it :-), I'd rather see that
> happen.  Otherwise, I'm +1 on removing the current "half baked"
> implementation.

Actually, I'm inclined to say that the parser is just doing what the spec sez.
The notion of a fully XML-compliant JSP page needs to be refined in the spec. We
need to say how the body of a scriptlets will be encoded by a JSP author (and
thereby how it will be transformed to code by a JSP engine). Chapter 4 of the
spec pretty much says that you need to out.print(...) template data (which BTW
itself could be HTML == not XML compliant) and you need to
out.print(<expression>) etc.

Re: implementability, once the rules of how things are going to be encoded in
scripting elements are laid out, it should be pretty straightforward either
implementing them as builtin actions or as a special custom tag mechanism which
gets to be invoked at compile time and gets to write things into the servlet
.java file.

As I see it this is a very important enhancement we should all work towards for
the next JSP specification.

At some point we have also talked about transforming a JSP page into an
XML-compliant page. If such a transformation is defined then we could just use
the existing JSP parser to do that transformation and then plug the code
generator as a SAX backend. So the data flow would look like:

JSP page --> JSP2XML transform --> XML-parser --> JSP Listener -- generates
--> servlet.

or

XML-compliant JSP page --> XML-parser --> JSP Listener -- generates --> servlet

Anyway, this is a big vacation for me and I need to stay off this stuff. Lots of
time to think about all this in 2K, if the disaster doesn't happen :-)

Happy christmas and new year to y'all.


Anil

Re: more on XML style scripting elements (was Re: cvs ... JspUtil.java Parser.java)

[Hans Bergsten <ha...@gefionsoftware.com>]

"Craig R. McClanahan" wrote:
> 
> Hans Bergsten wrote:
> 
> > Danno Ferrin wrote:
> > >
> > > What would constitute "fully cooked?"
> >
> > My comment about not fully cooked is based on comments made to this list
> > by some of the people who have implemented the JSP parser, plus the
> > description of the XML equivalents in the JSP spec. To use the equivalents
> > it not enough to replace <%= %> with <jsp:expression> </jsp:expression>.
> > The body of the element must also be encoded one way or another to avoid
> > special characters like < to confuse a real XML parser. As far as I know,
> > the parser doesn't deal at all with these types of encodings.
> >
> > > In light of this I think it may be
> > > good to nix the existing XML tags in the current implementation.
> >
> > I tend to agree, but it's a change I feel requires a vote before it's
> > done.
> >
> 
> How much effort would it take to make the parser "fully cooked"?  If it's not
> exhorbitant (and we had volunteers willing to do it :-), I'd rather see that
> happen.  Otherwise, I'm +1 on removing the current "half baked"
> implementation.

A agree that it would be better, but I haven't studied the parser in detail
and don't know enough about the type of encodings needed to dare guess about 
the effort. Someone from the original development team, Anil or Mandar maybe,
should be able to tell.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Re: more on XML style scripting elements (was Re: cvs ... JspUtil.java Parser.java)

["Craig R. McClanahan" <cm...@mytownnet.com>]

Hans Bergsten wrote:

> Danno Ferrin wrote:
> >
> > What would constitute "fully cooked?"
>
> My comment about not fully cooked is based on comments made to this list
> by some of the people who have implemented the JSP parser, plus the
> description of the XML equivalents in the JSP spec. To use the equivalents
> it not enough to replace <%= %> with <jsp:expression> </jsp:expression>.
> The body of the element must also be encoded one way or another to avoid
> special characters like < to confuse a real XML parser. As far as I know,
> the parser doesn't deal at all with these types of encodings.
>
> > In light of this I think it may be
> > good to nix the existing XML tags in the current implementation.
>
> I tend to agree, but it's a change I feel requires a vote before it's
> done.
>

How much effort would it take to make the parser "fully cooked"?  If it's not
exhorbitant (and we had volunteers willing to do it :-), I'd rather see that
happen.  Otherwise, I'm +1 on removing the current "half baked"
implementation.

>
> Hans

Craig

Re: more on XML style scripting elements (was Re: cvs ... JspUtil.java Parser.java)

[Hans Bergsten <ha...@gefionsoftware.com>]

Danno Ferrin wrote:
> 
> What would constitute "fully cooked?" 

My comment about not fully cooked is based on comments made to this list
by some of the people who have implemented the JSP parser, plus the
description of the XML equivalents in the JSP spec. To use the equivalents
it not enough to replace <%= %> with <jsp:expression> </jsp:expression>.
The body of the element must also be encoded one way or another to avoid
special characters like < to confuse a real XML parser. As far as I know,
the parser doesn't deal at all with these types of encodings.

> In light of this I think it may be
> good to nix the existing XML tags in the current implementation.  

I tend to agree, but it's a change I feel requires a vote before it's
done.

Hans 
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com