On Fri, 14 Dec 2001, Stefano Mazzocchi wrote:
> Gosh, I love this thread...
I do as well (even if I can't spend so much time writing big RT thoughts
about it).
>
> > > Yes, I had the taste of the power of continuations when I dived more
> > > into the paper you presented (and implemented myself a few scheme
> > > examples to get the feeling of it).
> >
> > I do like the concept of continuation as well. It gives you a better way
> > of writing interactive apps. It's like in the early days of programming
> > where you had stuff like this:
> >
> > write "prompt >"
> > read answer
> > if answer is correct
> > do it
> > else
> > redo
>
> I think we all agree then: continuations are the way to go.
>
> I think we all need to thank Ovidiu for bringing this on the table. :)
>
> [snip]
>
> > > In fact, for flow-driving semantics, I'd far prefer a ECMAScript-like
> > > syntax because it would be
> > >
> > > a) less verbose than XML
> >
> > Verbosity isn't always bad (even in the programming concern).
>
> Agreed.
>
> > If you can
> > force some verbosity it can make things look much clearer. I remember
> > reading books from famous people like Niklaus Wirth where variables in
> > his samples where single letter names :(. XML elements and attribute can
> > force you to use verbose names which is a huge win IMO.
>
> well, nothing *forces* you to do this, even for XML. as you could write
> obfuscated java code as
>
> public class A extends B implementcs X,Y,Z {
> public void a(String b) {
> return b;
> }
> }
>
> you could write obfuscated XML schemas such as
>
> <a>
> <b>
> <c d="..."/>
> <d><e>blahblah</e></d>
> </b>
> </a>
>
> To tell you the truth, having XSLT, it's much easier to obfuscate XML
> than Java :)
>
> So, I agree that "good" verbosity it's a good thing since improves
> redability, but I disagree that the XML syntax helps you on this.
>
> The only thing that imposes is the context in the closing brackets.
> Something that neiter C/C++/C#/Java/ECMAScript nor Scheme nor Python nor
> Perl do. (it's only suggested as good programming practice, but since
> the compiler doesn't care, neither developers do.
Well, I have not made myself clear enough. In XML you can control
verbosity by DTD/XSchemas/aggreed syntax. The ones controlling the
Schemas define the verbosity. In programming language nothing
prevents you choosing non-verbose names but in XML we control by
Schema the names of elements and attributes.
> > > b) generally more readable (consider escaping <,>,& or using CDATA)
> >
> > To be honest, IMO this isn't a big issue. You can always choose
> > alternatives as many popular languages are using like lt, gt, and, etc.
> > (which makes them even more readable).
>
> Good point, but the problem is 'mindset fit', not *general readability*.
> If you had to present something to non programmers, probably
>
> <select>
> <when test="$(value) grater than ${limit}">
> ...
> </when>
> <otherwise>
> ...
> </otherwise>
> </select>
>
> could still be written as
>
> if $(value) is greater than $(limit)
> ...
> else
> ...
>
> but then, since this is targetted to programmers, they question would
> be: why in hell they had to invent this stupid syntax? I would have
> written it as (modulo coding conventions)
>
> if (value > limit) {
> ...
> } else {
> ...
> } // (value > limit)
>
> which is much clearer for programmers and gives closing context (even
> XML, in this case, doesn't give closing context since the context is an
> attribute and you don't have to declare the closing of attributes).
:) you're exaggerating. I've never thought of bringing COBOL syntax into
play so change "is greater than" with simply "gt" like bash/perl/REXX is
using. Please don't confuse people here with things that where never
said and bring in super verbose syntax ;)
> XSLT shows pretty evidently that mixing programming constructs with
> markup it's too hard for HTML designers. It doesn't fit in their
> mindsets. (I think many of you have come to know this the very hard way)
>
> > > c) easier to learn/use/understand for C/C++/C#/Java/JavaScript people
> > > (a very big percentage of the web tech population nowadays)
> >
> > The "web tech population nowadays" understand HTML as well so this can't
> > be an issue.
>
> Oh, I wish you were right on this: resonating with a syntax is a
> necessary step for anyone to come close enough to something to learn it
> (reason why I tried several times to learn Perl but failed every single
> time: there must be some elegance someplace, but the orrible syntax
> hides it to me).
Yes, resonating a syntax is important and that's why I personally don't
like the Scheme syntax because is seems to me too exotic (no personal
objetcions to any Scheme/LISP programmers). To make my point clear we
are here in a Java/XML world and brining another syntax into play tends
to confure people instead of helping them.
> But then you journey just began.
<snipped interesting XSLT stuff but IMO out of context to this thread
and misleading people following it as we *never* thought about XSLT as
an alternative />
> I can tell you for sure, that both couldn't have used DSSSL because the
> unknown syntax would have been too much of a gap for them.
Hey, buddy. Why are you trying to convice me that XSLT isn't the right
way to express program logic? I nor anybody else here ever stated to
stick with XSLT. I don't understand your digression here. I've simply
said that, using your words, that the "web tech population nowadays"
understand HTML so there isn't a big step to understand XML and have a
syntax that is "procedural" to express logic for flowmaps and I meant
that Scheme isn't popular in the "web tech population nowadays" sdo I'm
-1 using Scheme syntax. Point.
> So, results:
>
> 1) the syntax should be tuned for the cognitive needs of those who work
> on it: since there are two kind of people working on XSLT (those who
> write the skeleton and those who write the included content) the XML
> syntax works because the first group can adapt better than the second.
>
> [This has lead me to believe that even XSLT has the same problem of XSP
> regarding concern overlap since the xsl: namespace could be seen as
> 'logic' and the rest as 'content'. Maybe, the concept of taglibs could
> be inverted for XSLT as well.... something for the future]
>
> 2) the syntax is only the first step: just like nice-looking web sites
> are likely to attract more people than poor-looking ones, it's the
> functionality that will bring them back.
>
> In this context, syntax must be friendly enough not to scare people away
> (unlike Perl, for example) but it's the semantics that should be
> rewarding and makes somebody like a language (just like Perl: oh, how
> much I wish I could jump over that huge entry gap that is its syntax for
> my eyes!)
>
> > > At the same time, for global site-mapping semantics, the XML syntax is
> > > still the way to go.
> >
> > This is a big +1 for me. After seeing the way how Ovidiu's proposals in
> > the scatchpad area defines pipelines in a Scheme/Lisp syntax I strongly
> > propose to stay with what we have in the sitemap today. The introduction
> > of map:call elements into the sitemap and the proposals from Berin
> > to separate pipeline definitions from mapping show
> > IMO a clear way where to go.
>
> I tend to agree here: the use of XML for the sitemap seems to be a more
> friendly look for the underlying semantics.
>
> > > > --
> > > >
> > > > I think with the new model, there's no need for actions, redirects and
> > > > other things that the sitemap currently has.
> > >
> > > Yes, I've always expressed my feeling that Actions were hacks.
> >
> > :) They aren't hacks, the are only in the wrong context because of lack
> > of alternative places to place them.
>
> Ok, granted :)
>
> > Redirection was introduced to reduce frition to visitors when web
> > masters had to reorganize their sites. Nowadays web programmers use it
> > as a natural *feature* for web programming (which is as Stefano
> > mentioned somewhere similar to GOTO programming).
> >
> > BTW this concept isn't new since servlets. I remember old days where one
> > wrote programs for the IMS/DC Online Transaction Monitor which had the
> > exact same approach (including mechanisms like servlet chaining but not
> > redirect as this isn't a feature character terminals had unlike
> > browsers)
> >
>
> [snip]
>
> > > Giacomo knows that I never really liked this approach, but I didn't stop
> > > the effort because I wasn't able to provide a more elegant solution.
> >
> > I have to make this clear, I've choosen the scratchpad concept than and
> > was forced to move it to the main trunk by the community because of lack
> > of alternatives.
>
> Granted as well. Please, understand that I don't have anything against
> actions: they are powerful and users like them. But I think we can come
> up with a more elegant solution than this and this is what I think we
> should aim to reach.
I don't wanted to say you are against it. I have only wanted to make it
clear. It was "throwing stoned into the sea to see what happens".
> > > Interesting enough, what you described in your above example is exactly
> > > the kind of 'flowmap' that I've been looking for in order to move away
> > > actions from the sitemap.
> >
> > I have no objections to this :)
>
> All right. Then we have a clear direction to follow, which is a great
> thing indeed! :)
>
> > > I knew that the intrinsic 'wait for request' behavior of the site forces
> > > the sitemap to follow a declarative approach, as much as the 'drive the
> > > flow' behavior of a web application would force the flowmap to follow a
> > > more procedural approach.
> >
> > Agreed.
> >
> > > Even more: since the sitemap might be written by people used to publish
> > > information and documents, the XML syntax is more suited for their
> > > skillset. At the same time, since the flowmap is written by people used
> > > to write programming languages, a java-like syntax is better suited for
> > > their skillset.
> >
> > Still not sure about that. XML can be easier parsed and validated and
> > thus forced to what ever we like it to be (concerning verbosity).
>
> Hold on a sec: no problem if you aren't sure about which syntax would be
> best for a flowmap (I still have doubts myself and want to see working
> examples before deciding where to go), but your arguments don't count
> that much on this concern.
>
> Java is parsed by a compiler, syntax well-formeness is checked, then
> validation is performed on all the external class mappings. But still
> NPE are the biggest problem to java debugging (at least, poorly written
> code).
Would you consider using native Java as syntax for the flowmap? How do
you restrict the semantics than? Would you write a Java parser?
> Interpreted languages, lack the compile-time validation phase (granted!)
> and are likely to introduce more run-time problems, but they reduce the
> try/fail/recode/retry cycle time and increase 'what if' kind of
> programming.
Granted.
> Many people complained about the high latency of sitemap changes that
> reduces the try/fail/retry production cycles and validating the sitemap
> might remove issues with tag mispelling, but will not remove problems
> such as class-not-found or more internal errors.
I'm still not sure this would be better in an interpreted sitemap way
(but I'm open to be proven wrong).
> So, I believe the argument about XML validativity is a very weak point
> for flowmap syntaxes.
I'm still not conviced.
> > > In this vision, Berin's proposal to make pipelines reusable by adding
> > > variable substitution might allow both sitemap and flowmap to use sort
> > > these pipeline definitions (pipemaps?) and reduce overall verbosity.
> >
> > Big +1.
> >
> > > Anyway, I think that by trying to prove the Flowmap concept wrong,
> > > Ovidiu gave us the best example of a flowmap in terms of syntax
> > > (code-based instead of XML-based) and functionality (continuations-based
> > > instead of FSM-based).
> >
> > code-based: +0
> > continuation-based: +1
>
> ok.
>
> > > > If you need to describe logic, you do it using the language. This
> > > > describes which pages are sent in what order. When you want to
> > > > generate a result, you call send-page() with the source document, a
> > > > pipeline definition that should process your document, and additional
> > > > data to be used in generating the source page dynamically.
> > > >
> > > > To generate the source document, it's better if we use a markup
> > > > language that prevents users from doing computations in the page. The
> > > > page should be generated only from data passed to the pipeline by
> > > > send-page(). I haven't used it before, but Velocity seems to be a good
> > > > fit for this, as it doesn't allow any embedded processing in the page.
> > >
> > > Since Cocoon content will always be XML-ized, I see two possible
> > > solutions here:
> > >
> > > 1) use XML-orthogonal solutions (Velocity)
> > >
> > > <p>Today is ${date}</p>
> >
> > -0 it mixes too much IMO.
> >
> > > 2) use XML-namespaced solutions
> >
> > +1 this is what XSP wanted to force.
> >
> > > <p>Today is <dxml:date/></p>
>
> I have mixed feelings about this myself. Again, we'll propose the two
> different solutions and let the community decide what to do.
>
> > > Again, the semantics are exactly the same, but the first approach if
> > > more friendly to code writers, the second to HTML writers. We could even
> > > have both and let the user decide which one he/she like the best.
> >
> > FS
>
> might be, I know, but I'm not sure at this point.
>
> > > > With this model we have the clear separation of concerns. Each layer
> > > > does only the things it's supposed to do, in a clean way.
> > >
> > > Absolutely:
> > >
> > > sitemap -> handles the stateless needs
> > > flowmap -> handles the statefull needs
> >
> > pipemap -> handles the resources needed
>
> Good. Should we start from describing pipemap semantics, then?
Ok.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
