Jeremy Quinn wrote: <snip/> > Maybe I do not recognise the differences yet, but the examples > you provided > for how "pipe-aware selection" would work, are all possible without such a > selector, please see the 'editor.xmap' in <slash-edit/>. IIUC, you put a lot of control structure in XSLT. I have also used that kind of constructions in a couple of applications. Yes you can do everything that you can do with a pipe-aware selector that way, but IMHO it obscures the control structure of your application, to understand the data flow and the control structure of the application, one have to look booth in the sitemap and in some xslt stylesheets. I believe that it is a better SoC to let the sitemap handle control structure and data flow and let the transformers transform single documents.
> Furthermore, is there REALLY a difference between these two pipelines: > > - pipeline1 - > / \ > request -> A -> X - pipeline2 - X -> C -> response > \ / > - pipelineN - > > > request -> A -> P1 -> P2 -> P3 -> C -> response > > (where Pn are a group of Transformations/Actions etc.) > > Apart from how you would arrange them differently in the Sitemap, what is > the real need to have parallel processes? I assume that the above example uses a "multiplexer" that can choose sub streams from the input stream. You can achieve the same functionality with booth methods, but in the second example P1, P2 and P3 must "know" about each other. Consider an input document like: <input> <a> ... </a> <b> ... </b> <c> ... </c> </input> with the multiplexer you can write general "a"-handling, "b"-handling and so on, sub pipelines that can be reused in other contexts. For the second construction, the transformer P1 must know about the root node "input" and that "b" and "c" are supposed to be copied to the output, and similarly for P2 and P3. To summarize: booth pipe-aware selection and multiplexers can be implemented in terms of xslt, but it distributes the control structure to booth the sitemap and the stylesheets, and it implies that the stylesheets must know about their contexts, which makes them harder to reuse. /Daniel Fagerstrom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
