[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Application Design

• From: "Al B. Snell" <alaric@a...>
• To: Leigh Dodds <ldodds@i...>
• Date: Tue, 14 Aug 2001 09:48:39 +0100 (BST)

On Mon, 13 Aug 2001, Leigh Dodds wrote:

> However my main point is that there's nothing implicit in the use
> of XSLT that requires the a push (i.e. we must know the exact
> input document configuration in advance) versus a pull (i.e. let
> the designer request what they need) architecture. These are
> separate issues.

I've not yet looked at XSP, but the thing in XPath that seems to imply a
push architecture to me is that it's a transformation from an input
document to an output document. The only escape from that is to use the
document() function lots, firing of HTTP requests to a backend server, but
for lots of small bits of data (fine grained control) the overhead of all
those HTTPs rises and rises. If it had something like document() that
invokes (in-process) a handler function written into the same address
space, maybe from a dynamically loaded Java class... indeed, if there was
a standard way of adding user functions to an XPath runtime, then I'd be
much happier.

But I'd still prefer to leave XSLT's complexities for the task of
converting DocBook to HTML or FO, seeing as it *is* after all designed as
a pretty direct port of DSSSL to XML, and use a much simpler subset
desiged for HTML developers for producing Web pages on the fly from
dynamic data. The subset invoked when the top level element is not in the
XSL namespace, for example :-)

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software

• Follow-Ups:
  • RE: Application Design
    • From: Leigh Dodds <ldodds@i...>

• References:
  • RE: Application Design
    • From: Leigh Dodds <ldodds@i...>

• Prev by Date: RE: Yuri would flip.
• Next by Date: RE: Application Design
• Previous by thread: RE: Application Design
• Next by thread: RE: Application Design
• Index(es):
  • Date
  • Thread