Hi Erik, Le jeudi 27 janvier 2005 � 14:43 +0100, Erik Bruchez a �crit : > 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 ;-)
Nice! > > 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. The fact that we can define targets doesn't mean that the execution of a processor is always explicit. Look for instance at make. When you give no target, the first one in the Makefile is chosen. A rule that won't break current applications could be that when you specify no target, all the processors without output are executed. > Now could those targets be specified internally, within the pipeline, > or would they have to be provided from outside? It would make sense IMO to be able to define the "default target" in the pipeline and to be able to overwrite it in the pipeline invocation (like a xsl:param). > > 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. Yes, that's a possibility. Targets could be considered as a possibility to define that declaratively. > 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"). You refer to one of them as a "black hole" :-) ... We could call then "actions" but that could be confusing with PFC actions as they can have outputs... > 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. Yes, why not. Targets just looked to me as an easy way to do so. They would be similar to XSLT modes or Schematron phases... > 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. Yes, I really like that point. > 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. Hmmm... I hadn't realised that! > 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. Yes, at first thought, I think that this would be better... > 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? What would also be most useful is to document for each processor, what is done during the each initialisation and read phase. It could also be nice to provide a kind of visualisation (graphical or not) of the flows of actions that can be expected from a pipe. Do you think a XSLT transformation could do that (take a XPL document and generate a XHTML (or SVG) representation of what can be expected) or would that be too complex? > > 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. Hmmm... In that case, I wouldn't want the serialisers to be called when there is an output... The following pipe should be valid: <p:config> <p:param name="data" type="input"> <p:param name="target" type="input"> <p:param name="data" type="output"> <p:choose href="#target"> <p:when test="target='xml'"> xml serializer </p:when> <p:when test="target='html'"> html serializer </p:when> </p:choose> <p:processor name="oxf:identity"> <p:input name="data" href="#data"/> <p:output name="data" ref="data"/> </p:processor> </p:config> and given what you've said when a target is specified and the output isn't used, only the init phase of one of the serialisers would be called while when a target isn't specified and the output is used only the identity processor would be called. If I understand correctly, the pipe itself would then be considered as having an output and wouldn't be called at all (from another pipe) if this output isn't connected and one would have to use the null serializer to force its execution... That makes sense, but I feel a little bit uneasy by the way all that is working. But I can't even explain why! Maybe that's just the fact that actual actions (such as sending a HTTP response) is done in a method called "init" which hurts me... > > 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. The fact that it seems possible to emulate targets with a simple choose would tend to show that the current balance between simplicity and features is good! > Working on the spec has already highlighted some sub-optimal syntactic > constructs. What about a compact syntax (ala RELAX NG)? > If it highlights sub-optimal semantic as well, and if we > can fix those, XPL 1.0 will look pretty good! Sure. Thanks, Eric > -- Read me on XML.com. http://www.xml.com/pub/au/74 ------------------------------------------------------------------------ Eric van der Vlist http://xmlfr.org http://dyomedea.com (ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax (W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema ------------------------------------------------------------------------ ------------------------------------------------------- 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
