Lists Home |
Date Index |
Michael Brennan wrote:
> Reproducing XSLTs "default template" behavior is not always a good thing.
> I've always felt that I'd love to have something XSLT-like, but which I can
> exercise more explicit control over default behaviors. For instance, if you
> wanted to use an XSLT-like mechanism for implementing a web service (rather
> than a straight RPC binding), then you certainly don't want a default
> template behavior that just copies text nodes to output.
You probably are experiencing a real problem, but this isn't a good
example of it. To handle text nodes differently, you can just define a
rule for text(). The same goes for the "default rule" for elements,
attributes etc. All you need to do is take the built-in default rules:
And tweak them to what you want.
> I've been thinking for some time of doing something like this, but have
> never gotten around to it. I think my ideal solution, though, would be to
> use something that looks somewhat like XSLT, but which lets me specify
> lightweight "collectors" -- something like the "variables" in XSLT, but
> which collect data from the SAX stream when a pattern is matched. You could
> have templates like XSLT that specify a Pattern, then have variables that
> collect subordinate data (e.g. data that is along either the child,
> descendant, or attribute axes of the node matched by the pattern). When all
> of the variables associated with the pattern have collected all relevant
> data, fire off some action to do processing with the data.
I did something like this once but I don't quit understand how you
expect the rule to know when all of the variables are "fully collected".
In my model you had actions on the start event and end event. If you
didn't have enough data by the end event then you were kind of out of
luck. I'm curious about your model.
I think it would be great if someone standardized a streaming
declarative event handler.