On Wed, 21 Aug 2002, Mike Brown wrote:

> Some might say it is an advantage to have the fixed processing algorithm that
> a declarative, functional language imposes. The XSLT processing model is not

absolutely
>
> And working within these confines still allows one great flexibility, as long
> as one is doing what XSLT was designed to do: 'XML transformation', or, more
> accurately, 'new XML document construction based on the content of 1 or more
> other XML documents'.
>
> However, I do think I see your point in that XSLT is relatively isolated from
> other languages, all being done in a black box, so to speak. I can see how
> some programmers, especially those entrenched in Java and C++, could feel more
> effective if they could do XSLT-like processing piecemeal, rather than having
> to give much thought to what business logic belongs where.

i wasn't suggesting an XSLT replacement as much as a Java/C++ replacement,
ie do the parts of the business logic that is best modelled by
object-oriented tools with an XML oo programming language. then the result
or output can be presented by means of an XSL transform.

>
> Have you investigated OmniMark? I haven't really, and judging by their website
> I'd say some marketing types have recently been rebranding their development
> tools as a content management system/'solution', but my impression has been
> that it was the PL/SQL of XSLT...

PL/SQL has it's (dis)advantages, i don't personally see it as the most
powerful or fit-for-purpose development model out there.

/m


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list