Berin Loritsch wrote:
> I think this has much to do with terminology. Web administrators
> and designers do not think in terms of finite state machines. If
> they have any concept of programatic logic, it is expressed in terms
> of XSLT or CFML, or something similar. Really simple. One way of
> restating the above example in XML is:
>
> <functions>
> <function name="addNumbers">
> <send-response page="first-page.xml" pipeline="my-pipeline"/>
> <call-action name="getFirst"/>
> <send-response page="second-page.xml" pipeline="my-pipeline">
> <parameter name="first" value="{first}"/>
> </send-response>
> <call-action name="getSecondResult"/>
> <send-response page="third-page.xml" pipeline="my-pipeline">
> <parameter name="result" value="{result}"/>
> </send-response>
> </function>
> </functions>
>
> Note the same feel as the other text, but we are using actions as
> they are meant to be used, as will as passing variables in the
> sitemap centric way.
>
> Notice though in this case all the <send-response> tags use the
> same pipeline?
>
> This is typical of the majority of the cases, therefore it can
> be simplified even more:
>
> <functions>
> <function name="addNumbers" pipeline="my-pipeline">
> <send-response page="first-page.xml"/>
> <call-action name="getFirst"/>
> <send-response page="second-page.xml">
> <parameter name="first" value="{first}"/>
> </send-response>
> <call-action name="getSecondResult"/>
> <send-response page="third-page.xml">
> <parameter name="result" value="{result}"/>
> </send-response>
> </function>
> </functions>
>
> That way, if any particular <send-response> wanted to override
> the default, they would include a "pipeline" attribute on that
> instance.
My personal experience has been than the intrinsic generality of the XML
syntax has forced me to think about the underlying semantics, while the
intrinsic solidity of the Java syntax has formed to to think about the
underlying flow.
This is why I like this syntax so much: it is so verbose that it forces
me to think of ways to optimize it (and I see Berin doing the very
same!) or to improve it.
This is what I did when designing the sitemap and I think I wouldn't be
able to do it if I had to use a javascript syntax for it.
At the same time lisp dialects are much closer to this XML behavior, so
I perfectly understand why Ovidiu and others might 'think better' using
this syntax.
Anyway, I think that bringing both sides on the table helps because it
projects the same concepts onto two different syntax hyperplanes, where
different semantical optimizations could be observed.
> However, this does bring up a valid point about the
> pipelines as they stand:
>
> It would be great to have valid pipelines that do not specify
> the source document in the generator. In other words, the valid
> pipeline would say use a "FileGenerator" through an "XSLTTransformer"
> with stylesheet X through an "HTMLSerializer".
>
> Notice that the "FileGenerator" does not have a source property.
>
> In the concept outlined here, we specify the source or page in
> the <send-response/> tag. This is an important distinction so that
> we can have re-usable pipelines.
I do like this concept of having 'reusable pipelines' and I think it
could also be made back-compatible with the existing sitemap.
How were you thinking of adding this sematic to the sitemap?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
