Eric van der Vlist wrote:
> Is there a document describing this semantic (maybe using a formal
> description)? If not, such a document would be very helpful for
> people who have passed their first learning steps :) !
The specification for XPL 1.0 is in the works and a draft will be
available real soon now. You'll be the first to review it, if you want
to! I am answering to your email right away because I am in the spec
up to my neck at the moment ;-)
> The points I find the most touchy are the behaviour of processors
> without outputs and the difference between a processor with an
> unconnected output and a processor without output.
You are right in saying that this is the most difficult part. We had
some discussions about this a long time ago, see for example:
http://mail.orbeon.com/pipermail/oxf-users/2003-July/000317.html
> I think that we could consider a pipe with processors without output
> like a make (or Ant) file and that this would be nice if we could be
> able to specify when we call this pipe which "targets" are to be
> executed.
If I understand well, what you are trying to do is avoid the automatic
execution of processors that do not have any outputs. With this
mechanism, the execution of a processor is always explicit, in that
either one of its outputs at least is read, or it is declared as a
target. In the other cases, it is not executed at all.
Now could those targets be specified internally, within the pipeline,
or would they have to be provided from outside?
> Let's say I have the same document that I want to serialise using
> different processors (maybe a HTML processor, an XML one and a PDF
> one).
>
> Right now, I need to write n+1 different pipelines : one for
> creating a XML representation of the document and one for each
> serialisation.
>
> Instead of that, if I could specify the "target", I could write only
> one pipe and provide a target for each serialisation.
You can do this with a single pipeline by providing a configuration
input that specifies which "target" you want to execute, and then use
p:choose to execute the serializer you want. But I am not sure if this
solution is to your liking.
By the way the notion of target is present in the 2002 W3C Note about
pipelines, and we did not like it, because it looked like it added a
concept that was unnecessary to the language. Better keep the language
simple, right? Now if by trying to keep it simple we create an
execution model that is arcane, we have a problem.
Clearly to me:
1. We need a way to execute processor without outputs ("serializer",
although I don't like this term much because often serializers do
not actually "serialize").
2. We should try not to add unnecessary features to the core of the
language. This is a difficult balance to look for between features
and simplicity. It would be great if we could make the processing
model a tad more intuitive while not introducing the notion of
target.
A little more on this: if you look at processors and pipelines, they
really look very similar, to the point where the pipeline engine is in
fact implemented as a processor, and this mechanism is used to call
sub-pipelines. If you add the concept of target to the pipeline, you
may have to add it to the processors as well for consistency. It would
be so nice to be able to just keep the idea that you can execute a
pipeline / processor, and maybe read outputs from them.
Now this is explained better in the spec, but the processing model
makes a distinction, when executing a processor, between:
1. An initialization phase
2. One or more read phases
For a processor without any output, you only have the initialization
phase. This initialization phase occurs in document order when a
sequence of statements (typically, the pipeline itself, but it can
also be the content of a p:for-each) is executed.
For a processor with outputs, you may have an initialization phase,
followed by one or more read phases, depending on what outputs are
read.
Currently, for the second category of processors, the initialization
phase occurs ONLY if at least one output is read, and it occurs just
before the first output is read.
Maybe this could be changed to performing the initialization phase on
all the processors, like suggested in the post linked above. This
could make the processing model a little easier to understand, because
then even a processor with an unconnected output has an opportunity to
do something on an equal footing with processors that do not have
outputs. If it wants to perform some actions during its initialization
phase, it may do so; if it wants to use the lazy approach and do its
work only when its output(s) is/are read, it may do so as well.
Or, maybe all is needed is a real spec, and this distinction made
between initialization and read phases is good enough to make things
clear?
> Now, it could also be interesting to define an optional output for
> this pipe. This optional output could be used to provide the XML
> document when needed outside of the cases implemented as targets,
> for instance if I need to include a snippet of that XML document in
> another one.
>
> The fact that this optional output is defined shouldn't modify the
> behaviour of the pipe when it isn't used, but just be considered as
> another option or target.
Whether the behavior remains the same or not depends on how you write
the pipeline, but it is likely to remain the same. Clearly, reading
the output may cause other tasks to be performed (i.e. other
processors to be executed related to producing that output). In theory
it could even cause the order of execution of processors to be
different, but in your particular examples with serializers only, the
execution order would remain the same, because all processors without
outputs are guaranteed to be executed first.
> Am I totally or only partially wrong :) ?
This is a difficult discussion! Suggesting a change to the processing
model and/or adding concepts / features to the language cannot be
considered lightly. This is BTW exactly the kind of feedback and
discussion that we were hoping the XPL specification would
produce. You are anticipating and it is great.
Working on the spec has already highlighted some sub-optimal syntactic
constructs. If it highlights sub-optimal semantic as well, and if we
can fix those, XPL 1.0 will look pretty good!
-Erik
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
orbeon-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/orbeon-user
