Nic Ferrier wrote:
> I'm wih Jon most of the way here... to be honest I can't see much
> difference between:
>
> $substitution
>
> or
>
> <substitution/>
>
> except that mr/mrs/ms balck-polo-neck has a 2 more characters to deal
> with in the latter.
Hmmm, that's like saying "use short variable names so that users have
less chance of mispelling them"... this argument simply doesn't hold.
XML has a precise syntax, just like any other thing in computer science.
(even PERL has one!)
> In practical terms that means that you will get black-polo-neck
> coming to you at least 3 times a day saying:
> "hey nic/stefano/kevin/jon why doesn't my page do what I told it?"
>
> and you looking at the code and saying:
> "well, mrs/mrs/ms black-polo-neck - you've forgotten the <|/|>"
> [note use the OR operator there as approopriate]
> and black-polo-neck replying:
> "oh yeah... sorry - did I ask you that question before?"
I'm working right now on a secret project that will help reducing this
risk.
> The point is really not about this - it's about which is going to be
> easier for a tool to deal with.
>
> I absolutely disagree with (was it Kevin or Stefano?) who said that a
> tool will not be built for WebMacro. Why not?
I didn't say that. But such a tool is _much_ easier to write for XML
than for WebMacro.
> Anybody could get the source for any of the innumerable HTML editors
> out there right now and add some code to support WebMacro. No problem.
No problem? I wish you luck matching what we can do with XML and schemas
:)
> That is after all the power of free software.
???
> Of course such a tool might not take over the world, but who cares
> about that if it stops the gaggle of black-polo-necks from constantly
> clucking round your desk and means they can get the pages out
> quicker.
True.
> Of course XML is the future but I have to say that people have been
> saying that for a while now. It will happen but there's real impedance
> there.
Sure, people that are scared to death about it and try to learn it the
hard way (from the spec) instead of the easy way (install Cocoon and
play around).
And I _know_ what I'm talking about here. I wrote Cocoon exactly because
I could not understand the spec :)
> Right now XML has the following problems:
>
> 1. it isn't native in the browser which means you've got to convert
> to HTML (means extra latency or a seperate compilation stage in the
> build of an app)
>
> 2. it's still being developed - by cool and talented people like you
> guys
>
> 3. it is not supported by enough black-polo-neck facing tools (see
> 1)
>
> When these 3 are fixed or irrelevant Jon and I will both be using XML
> (I'm sure). Until then we'll probably carry on hacking together stuff
> with lots of different tools in lots of different ways.
And, honest, I'm _totally_ happy with it.
This is my personal vision:
1) XML will _NOT_ replace HTML. It's like saying that UNICODE will
replace HTTP... it's a semantic nonsense.
2) HTML is perfect for its job: simply-structured hyperlinked
information. It will probably migrate to XHTML to create more solid
parsing (to avoid the side-scripting security holes of things like
<b<script ....>> that IE parse with no problems! yuch!) but the language
will remain the same and people won't have troubles to figure it out.
3) global XML adoption will happen gradually and will move on from the
server side (unlike the w3c first assumed)
4) XML adoption for medium-high complexity web-based information systems
will happen _instantly_ as soon as industrial-strenght tools happen to
exist. (Cocoon2 beta is scheduled for June) The want to invest money in
this because it's a dream-come-true for many managers/CTOs.
5) In five years, writing a web site that spits HTML alone with no
content syndacation will be laughted at just like we do today for web
applications written in C. The easiest way to do content syndacation is
with XML and XSLT tranformations. (using SGML and DSSSL is simply not
affordable... this is why never took off other than paper publishing)
Does this mean that what Turbine is doing is wrong? NOT AT ALL! Does
this implies that WebMacro is obsolete? NO WAY!
Like Jon said, the "view" part of Turbine should be decoupled and he's
using WebMacro for this (if I understood correctly), or he could use
Cocoon. Great, no problems, you loose many other Cocoon potentials but
it's ok.
My point is: Cocoon lacks a model for XML web applications, Turbine has
one, 1+1=2 (more or less). Servlet 2.3 is going to push more in this
web-app direction and I'm seriously concerned about XML support in this
(but you already know this), because otherwise, Cocoon would have to
reinvent the wheel (as we did for generators, XSP, sitemap and a bunch
of other things).
Like I said many times, at this moment, it's way too early to tell.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
--
----------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
