[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Paul T" <pault12@pacbell.net>
>
> ---- Original Message -----
> From: "Nicolas LEHUEN" <nicolas.lehuen@ubicco.com>
>
> > We debated about the opportunity to patent the technology in my company.
> We
> > gave up the idea, because we felt that it would be way too costly for
our
> > little structure (yep !), and that there was a potential overlap with
> > Cocoon's XSP.
>
> Interesting - just a couple of hours ago I've seen some
> home-grown XSP implementation, because people
> who've implemented it, have not spent too much
> time learning Cocoon ( and also they implemented
> it long time ago when Cocoon had less visibility than
> it has now ). XSP is pretty common pattern. In my
> oppinion XPathScript (AxKit) is also in that problem
> domain.
Seems history is repeating... We, too, started the development of EXOGEN
(which is a trademark, by the way) before hearing about XSP, because XSP was
at its beginning then. Anyway, there are enough differences between XSP and
EXOGEN to justify the work we've done.
> By the way, XSP, PHP, JSP and alikes look
> in some sense orthogonal to XSLT, because
> XSP, PHP, JSP and alikes usually consider multiple
> sources ( and multiple *states* ) to be not an exception,
> but a rule. This is not actually the case for XSLT
> ( which has no idea sbout 'states' because
> printed document has *no* states ).
Exactly. To go further, EXOGEN does not make the assumption that there is a
single output document. EXOGEN has been built to develop programs running in
our homegrown XML application server, which has a model of stateless or
statefull, synchronous or asynchronous "ports" (point of exchange of XML
documents). Therefore, a single EXOGEN document can receive documents from
various input ports, do some processing, and send new documents to various
output ports.
That is the main difference with XSP : XSP has been developed with the
Cocoon framework in mind, to build producers. EXOGEN has been developed to
be sufficiently generic to operate in different contexts within our
application server.
The output of the EXOGEN compiler is a java.lang.Class instance (dynamically
loaded) which does not need to implement any specific interface. That means
that you can use EXOGEN to implement anything you want, even if it's not
related to XML. In fact, as we have added the support for Perl regular
expression to the language, we use it for trivial, non XML related tasks.
Note that the compiler precompiles all XPath expressions and regexp used in
an EXOGEN document, when they are fully defined at compile-time, so we do
not trade performance for readability.
> XSLT-based frameworks are struggling when it comes to
> web applications. Perhaps what Mr. Leventhal said long
> time ago is true. ( For web applications, what we really need
> is a good DOM, that we can update / query / modify e t.c )
>
> > I think I'm going to reschedule a meeting on the subject, to decide
> whether
> > it would be possible for us to at least donate the specs of the language
> to
> > the open-source community, so that anybody could scavenge good ideas out
> of
> > it. Maybe the best thing would be to work with the XSP people at Cocoon.
> The
> > biggest problem is to find time to write down those specs in English, as
> > everything was done in French here :), and/or to collaborate with the
XSP
> > people...
>
> I'd gladly participate in any open group that would try
> building a practical language-neutral templatish language.
> There are some things in XSLScript that I like, but there
> are some things that I don't like.
>
> Yet another Text::Template is what we need ;-)
>
> However, it should be language and platform neutral.
> And I belive that { makes better separator than <%.
Platform neutrality is a reachable goal. Language neutrality seems
difficult, because what we would build is, well, a language, so that a
grammar and formalism should be defined.
In EXOGEN, we have special operators using {}, a bit like the {} in
attribute values in XSLT. For example, to insert the result of an XPath
expression in an output document or in a Java expression, we use
{#document1:/foo/bar/text()}, where 'document1' is the identifier of an
input document. Yeah, I told you the syntax was not of the highest elegance
:). But being able to use such an operator saved us LOTS of time.
> ;-)
>
> OK, OK, really nice thing should allow both, because
> some people need to edit it in a GUI HTML editor,
> but some people are editing templates in vi / notepad
> And I think that there is no possible markup that
> would be good for *both* cases.
>
> Rgds.Paul.
Regards,
Nicolas
|
