>> That could be and it's partly why I've started this discussion. This >> morning in a responses to Ovidiu I pointed out that perhaps what I >> really want is just to be able to use XSLT as the flow language? I'm >> not quite sure how that would work, but that's essentially what I'm >> looking for... > > Ok, so instead of sitemap+flowscript you want XSLT+sitemap. > > Ok, I'm starting to get it.
Great, you may have to explain it to me at some point.... >> I hope no changes should be needed other than those that are currently >> be worked on to support flow and blocks. Part of my reason for >> pursuing this is to see if it will be possible to use flow and/or >> blocks to support what I want to do. > > Hmmmm, I'm not currently in favor of a pluggable sitemap engine... but > you do have a point here, so let's keep the door open for a possibility. > > NOTE: the way cocoon is already architected makes it very easy to > connect a new sitemap engine (we already have two: interpreted and > compiled) and its also completely detached from the request environment > (as for CLI abstraction). It would be pretty straightforward to plug in > a different sitemap engine that didn't use the current sitemap semantics > but something else entirely. > > But I consider this a last resource, something that gets *too* close to > FS and over-componentization. Yes, I suspect so. Also, what I'm proposing would use all of existing sitemap capabilities so I don't want to reinvent that... [snip] >> Yes, I agree; I kept out of the blocks "language" discussion for the >> most part because I don't have enough experience with trying to plug >> new things into C2 yet. It looks like that discussion has come to >> some consensus but I'm not quite sure what it is? It seems to me that >> however it shakes out will be sufficient for my needs... > > Hmmm, so far there has been *no* discussion whatsoever in allowing > blocks to extend or overwrite the internal core functionalities of > cocoon. And that was on purpose. > > This is the first time it emerges but it's good to see if it makes sense > or it's just FS. I'm not sure that this would hit the core? It looks to me more like a resource that wants to call other resources. I plug this new thing into the sitemap, it take over for a transformer at some point, then it calls other resources as defined in the sitemap. <snip> >> After working through this discussion it seems that this primary >> concern is probably: sitemap+flowxslt instead of sitemap+flowscript. >> The problem now is that, (like you ?), I can't quite see how the two >> concepts could be pluggable replacements for each other? > > Yes, I definately can't see why anybody would want to use XSLT for the > flow description.... but that might well be my personal limitation > kicking in and I fully want to understand your point so that I might > learn something that I failed to see before. Hmm, I meant that I couldn't easily see how to replace a script engine with a functional engine not that that I couldn't see how to use XSLT to drive other transformations. > > Still, XSLT was *NOT* designed for those type of things and my gut > feeling is that by twisting its model too much you might end up having > something that uses the same XSLT syntax but is not XSLT anymore... so > it might simply confuse people and appear as a 'golden-hammer' anti-pattern. I'd have to disagree. I think XSLT was designed precisely for this purpose: sort through some data and determine what data should be created as a result. >> I'd rather avoid using XSLT extensions, so I guess that means having >> some kind of DOM model where the input is a bunch of data and the XSLT >> reduced it to a single node that the flow controller then somehow >> interprets as the next "step" instruction? >> >>>What you are presenting above is a very complex way to transform your >>>data. >> >> Gee, couldn't the same be said of all of Cocoon? :-) > > No, that can be said for Xalan. Cocoon is much more than a way to > transform your data. Such as? Ultimately all of computer science is just about data transformation... >>>I don't see what you can['t] manage flow with XSLT. >> >> Well, as you pointed out earlier, all Turing complete languages are >> isomorphic to each other... > > In case you didn't realize, XSLT is definately *not* a turing-complete > language :) [you need internal scripting or extensions to turn it into one] No, there are several proofs of XSLT Turing completeness. See http://www.unidex.com/turing/utm.htm for starters... <snip of example 1/> > Ah, we are coming back to the XPathSelector!!! > > <map:select type="xpath"> > <map:when test="count(data/*) = 0"> > <map:transform src="error.xsl"/> > </map:when> > ... > </map:select> > > This was proposed a while ago but was voted down since the sitemap > routing components shouldn't have a way to access the content of the > pipeline. But sitemap components already have ways to access the content of the pipeline, it's just that currently you have to expose those contents as parameters... <snip of example 2/> > Yeah, I think that all you want might be achieved with the XPathSelector. Well, these are somewhat trivial examples, I'd think that you can see that much more would be possible inside of a real XSLT... > The use of XSLT is *clearly* overkill. What you are describing is *NOT* > XSLT: even if it uses the same syntax, the semantics are totally > different (in fact, you are mixing XSLT semantics with the sitemap > semantics... this cannot possibly be easier to learn/use/maintain than > just the sitemap semantics) That doesn't make sense: in that case you'd have to consider the production of HTML from XML via XSLT a mixing of HTML semantics with XSLT semantics? >> Just for the heck of it let me contrast what I want with the >> flowscript approach to see if this helps: >> >> Flowscript: >> >> I've got a bunch of data, some represented as nodes, some as >> parameters and some as a FOM model in JavaScript. I process this >> mixed representation of the data and send some of it off to the end >> user. I get some data back, do some conversion of the data between >> the various representations, do some more processing and send >> something to the user once more. Etc, etc. >> >> New thingy: >> >> I've got a bunch of data represented as a bunch of nodes. I process >> these nodes and I send them off to the end user. I get some nodes >> back from the user, I do some more processing on these nodes, etc. >> etc. >> >> I see what I'm looking for as a conceptually much cleaner way of >> attacking the whole problem without having to work with my data being >> managed in several different ways. One language, one data model start >> to finish.... > > Yes. This has been the argument about the XPathSelector as well. > > But my architectural vision says that the pipeline should contain data > while all metadata should remain outside the pipeline. So if someone needs to make a pipeline decision based on metadata they are out of luck? Really, our entire model is metadata driven, there is no hard data at any point outside of metadata selector patterns... > This, instead of mixing stuff in the pipeline, enforces separation and > clean design. I'm still keeping the processing of the metadata separate from the pipeline. You have to call the new thing to access the metadata and the metadata is not exposed in the pipeline (as it would be with XPathSelector). > Your bunch of data is always represented as nodes (since it's XML and > must be processed that way). Your bunch of metadata is always > represented as objects (since it's not XML and should not be processed > that way). But all my metadata is XML and I have good reasons for processing it that way... > The use of XPathSelection in the sitemap stops us from being allowed to > separate flow from resource production. Exactly because you merge two > different datasets (pipeline data and pipeline metadata). > > To me it's definately not cleaner model but it's aggregation of concerns. Well that's why I see this new thing as being a separate component. The selection of resource via this new thing isn't any different than an action spitting out a parameter and the sitemap acting on that. Whether the action looked at data, metadata or the phase of the moon to spit out the parameter is not relevant to the pipeline. Similarly, how this new component arrives at it's determination isn't relevant to the pipeline... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
