This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: object-oriented XSL


martin@hack.org wrote:
> the idea is based on the concept of using XML as a programming language,
> pretty much like XSL, but instead of a declarative, transform-focused
> language it would be procedural, even object-oriented.
> [...]
> why not write the business logic, the bits that generate or process the
> xml, in a programming language that gives you the same advantages as xslt?

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 
very difficult to summarize:

  - there's this input node tree representing the meat of an XML document, 

  - instructions in the best matching XSLT template for that tree's root node 
    are instantiated,

  - various instructions result in the selection and processing of more
    nodes, the observation of different parts of the input tree, and the 
    creation of a new output node tree,

  - the new tree may be serialized in XML or HTML or plain text syntax
    according to another fixed algorithm, guided by hints one provides
    in the attributes of xsl:output and xsl:stylesheet elements.

Although the nuances of XPath and XSLT require a complex machinery to
implement this perfectly, an implementation can be fairly efficient since it
can optimize without knowing very much about the stylesheet.

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.

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...

Anyway, I'm just rambling.

   - Mike
____________________________________________________________________________
  mike j. brown                   |  xml/xslt: http://skew.org/xml/
  denver/boulder, colorado, usa   |  resume: http://skew.org/~mike/resume/

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]