Lists Home |
Date Index |
From: "Michael Kay" <email@example.com>
> It's often been proposed that there should be a "streaming subset" of XSLT
> (in fact, the idea appears in conjectural form in the published XSLT 2.0
> requirements). I personally don't think it's viable. If you want to
> transform a document in a single pass, then you need to remember things as
> you read them for use later. The transformer therefore needs working
> storage, it can't be purely functional as XSLT is.
OmniMark's approach here was very practical: its paths were only
upwards and backwards looking, but it let you emit "referents" into
output streams. A referent is an object whose value is filled in later.
I think an output stream waits when it receives a referent until the
referent value is filled. Very efficient.
For transformations that required future knowlege, it usually only
means that two passes are needed, which perhaps is not
so bad because it can let the logic be more explicit.