>> Let me be clear that I'm not looking for dynamic pipeline generation.
>
> Cool.
>
>> The
>> mapping of URI to generator is well defined for everything that what
>> we want to do. The selection of transformer is a little less so; for
>> example, the 1 result vs. multiple results example we talked about
>> earlier. That's still a static sitemap, but the transformer is chosen
>> at run time; so the understanding of dynamic vs. static sitemap should
>> be clear: dynamic sitemap would mean building the sitemap every time
>> it's run. I can't imagine anyone that would want that?
>
> The ability to attach new components to pipelines at runtime has been
> asked for in the past and I've always been against this (and I still am).
Darn semantics... I'm not trying to attach anything new to the sitemap at
run time, just choose between predefined components at run time, the same
way the sitemap currently works. It's just that the language I want to use
to choose between components is XSLT instead of JavaScript.
<big snip on background info/>
>> In-other-words, for us, the decision on what action to take at any
>> given point is dynamically evaluated (like most action handlers), but
>> the decisions are just based on one heck of a lot of complex
>> processing (and not just simple form field evaluation), this
>> processing falls into the general CS pattern of expert systems
>> processing and more specifically rules based expert systems (among
>> other things). As a result, in our particular case, functional
programming meets our
>> needs better than most other solutions.
>
> Cool, I trust your reasoning on this and I'm starting to understand why
> you want special XSLT templating where rules are stored into databases.
>
> But I think that what you are looking for is a special transformer. It
> doesn't require changes to what cocoon pipelines are. At least, I don't
> see why it should.
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...
<big snip/>
>>
>> The rules don't go into the database, the rule selectors go into the
>> database. I don't think any extensions should be needed; the context
>> data will be created using standard generators and possibly
>> aggregation, though as we proceed we're finding that our generators
>> inherit from each other and aggregation isn't needed; each generator
>> picks up what is needed automatically. Likely, for the other cases
>> we'll end up using composition in the generators and eliminate
>> aggregation in the sitemap.
>
> So, why don't you so something like
>
> <map:transform type="xslt" src="cocoon://..."/>
>
> where is a cocoon pipeline that generates the stylesheet you need?
I've considered this in the past and it now occurs to me that this is
probably a better solution than the dynamically created cinclude/xinclude
solution that was also discussed in this thread. I'll have to do some
analysis on how much work it would be to code this up, but I think it would
be pretty straight forward. Again the issue of caching comes up, but we
already know this thing is going to take some pretty hefty hardware in any
case...
>>>how that is goint to be any better than a sitemap+flowmap is *very*
>>>hard to see from where I stand.
>>
>> Better is a relative thing.
>
> Oh, totally.
>
>> As we've sort of concluded, in some cases your
>> development requirements get messy no matter what way you go. When
>> you're building systems for research it's often a case of picking the
>> less of two evils...
>
> Wise sentence. Still here you are pointing out that cocoon might require
> changes to its internal model while I really don't see this as it seems
> that your concerns happen to reside on a higher application level than
> the sitemap+flowscript (if I understood correctly, of course)
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. If I use the dynamic XSLT approach then even these changes
might not be needed, but ultimately I suspect I could get better performance
using an approach that didn't need dynamic XSLT.
>>
>> <small snip/>
>>
>>>>However, I could also see
>>>>how there might be situations where the serialization decision might
>>>>be part of the new thingy, and thus the blocks discussion and how to
>>>>hand off service calls becomes relevant.
>>>
>>>It is *NOT* a transformer decision to drive the serialization process.
>>>It's against both SoC and IoC! There is nothing planned for Cocoon
>>>Blocks that will allow this to happen and as soon as I have to vote
>>>around here, you'll get my -1 on anything that makes possible for one
>>>pipeline component to modify dynamically the pipeline execution,
>>>including choosing a serializer.
>>
>> I'm not asking for the transformer to drive the serialization
>> decision; we definitely want to separate those decisions! What I was
>> saying is that if you have a generalized way of extending the sitemap
>> then the decision on where to plug in the serialization becomes an
>> issue.
>
> I would be against a generalized way of extending the sitemap. I want
> people to build consensus on this list not route around it with
> pluggable extensions.
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...
> This is more a community-thing that a technical issue, but look at the
> mess that Avalon became after allowing people to diverge without
> creating consensus :/
Not familiar with the issues, but I'll trust you on that and stay away from
getting involved if you don't mind ;-)
>> It's the resources
>> discussion: a resource might do generation and transformation, or it
>> might do transformation and serialization, or whatever. In my case,
>> the question of whether blocks will allow this doesn't matter a whole
>> lot, since for the most part I think we can behave mostly as a pure
>> transformer. However, I could possibly see a case where I want our
>> new thingy to behave more like a generic resource and take over more
>> of the otherwise standard sitemap processing.
>
>> SOC shouldn't mean that the only place you can separate the
>> transformation and serialization decisions is in the master sitemap,
>> some other component/block might also have a good way of separating
>> these decisions and handling them...
>
> Great, but let's try not to mix concerns: you started saying that you
> have a 'different approach' to resource production than
> sitemap+flowscript using XSLT.
>
> I still fail to see how.
There are definitely two issues here. I'm not very concerned about this last
one, more about how easy it would be to plug something new in to manage
flow. 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?
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? :-)
> 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...
> Don't get me wrong, I'm not criticizing, I'm trying to understand if
> your functional requirements are something that the S+F
> (sitemap+flowscript) cannot cope with.
>
> And even the most complex XSLT-based transformation stage is something
> that S+F are perfectly capable of doing (or, at least, I failed to see a
> reason why not)
>
> Anyway, I really don't see how you are going to do flow description with
> XSLT, do you have a code snippet to show your point? that would be
helpful.
Well we're still in an architecture mode and I haven't yet started on a
prototype, but off the top of my head I could see an XSLT that looked
something like the following. (Bear with me for a moment, this isn't right,
but I think it introduces the concept better than jumping directly to what I
want):
<xslt:template match="count(data/*) = 0">
<map:transform src="error.xsl">
<map:parameter name="parms" value="/request:parms/*"/>
</map:transform>
</xslt:template>
<xslt:template match="count(data/*) = 1">
<map:transform src="detail.xsl">
<map:parameter name="data" value="data/*"/>
</map:transform>
</xslt:template>
<xslt:template match="count(data/*) > 1">
<map:transform src="list.xsl">
<map:parameter name="data" value="."/>
</map:transform>
</xslt:template>
This being for the data results selection case we discussed earlier.
Obviously this trivial example could just be a <xsl:choose> but the point is
that there may be other things going on for each match (in particular the
apply-templates invoking the templates might be complex and the parameter
building would be more complex.)
The problem with this as I've sketched it out so far is that it appears that
the XSLT is spitting out components on the fly (so to speak) when what you
really want to do is choose between existing components. As such, the
output should probably be a new statement. Also, what I'd really like is not
to use parameters to pass the nodes on, but to specify that a particular set
of nodes is directly the input to the transform. Finally, maybe the name
space should be Cocoon: instead of map: since that might make it clearer
where the output is going (and it matches up with the Cocoon pseudo
protocol)? Thus, the example of geographic vs. temporal search might look
something like:
<xsl:template match="searchType">
<xsl:variable name="curType" select="text()"/>
<xsl:choose>
<xsl:when test="/consent='All' or
/consent=protocol">
<Cocoon:select name="search" src="."/>
</xsl:when>
<xsl:when test="not(/history/searchType/text() !=
$curType >
<!-- the above probably doesn't work... -->
<Cocoon:select name="search" src="."/>
</xsl:when>
<xsl:otherwise>
<Cocoon:select name="error.xsl" src="."/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
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....
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
