inline XSLT for processor input

Hi there,

at this time again a big THANK YOU guys for the great work you do.
We all know how much work it is to keep up a project like this and
I think you should hear about our appreciation from time to time :-)

And here my question / feature request.
using orbeon, I noticed that a lot of times you need a transformation
to feed the config parameter of some processor. Since that is a lot of
code "just" to create a simple <config> document, it would be great
to get rid of it, by allowing an xslt on the <input> tag of a processor.
I think about a transform attribute, that if it is set to "true" allows xsl
code inside the input data. That could be used just like in the example
of the xslt processor in http://www.orbeon.com/ops/doc/processors-xslt
(4.4 or 4.6). The root document for the transform would be the actual
input defined by the href attribute (if set). To help processor developers, that
implicit transform could be implemented in the SimpleProcessor, so
that it would require no extra work.
I know that there is the aggregate / xpointer extension to the href, but for
me there were a lot of occasions, when I couldn't get to what I wanted
with that. Am I the only one with that experience?
I hope I didn't miss any other orbeon feature that makes my request
obsolete.

What do you think?

:oliver

-- 
-----------------------
oliver charlet
software development

11-041 Olsztyn, Poland

[hidden email]
-----------------------

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi,

Le vendredi 25 novembre 2005 à 11:02 +0100, Oliver Charlet a écrit : I have been thinking of that kind of thing too and I am wondering if we
couldn't define something slightly more verbose but still more generic.

If we take a typical example such as:

    <!--  url generator config  -->
    <p:processor name="oxf:xslt">
        <p:input name="data" href="#instance"/>
        <p:input name="config">
            <config xsl:version="1.0">
                <url>
                    <xsl:value-of select="escape-uri(/form/path, false())"/>
                </url>
                <content-type>application/octet-stream</content-type>
            </config>
        </p:input>
        <p:output name="data" id="url-generator-config" debug="url-generator-config"/>
    </p:processor>
    <!-- url generator : read the document -->
    <p:processor name="oxf:url-generator">
        <p:input name="config" href="#url-generator-config"/>
        <p:output name="data" id="document"/>
    </p:processor>


Maybe we could just allow to write that as:

    <p:processor name="oxf:url-generator">
        <p:input name="config">
            <p:processor name="oxf:xslt">
                <p:input name="data" href="#instance"/>
                <p:input name="config">
                    <config xsl:version="1.0">
                        <url>
                            <xsl:value-of select="escape-uri(/form/path, false())"/>
                        </url>
                        <content-type>application/octet-stream</content-type>
                    </config>
                </p:input>
                <p:output name="data" ref="config" debug="url-generator-config"/>
            </p:processor>
        </p:input>
        <p:output name="data" id="document"/>
    </p:processor>


The trick would be to consider that when the child element of a p:input
is a p:processor, this input is connected to the output of the embedded
processor.

That would allow a "Russian doll" style that is easier to read when it
is used with moderation...

There would be of course some details to specify such as the scope of
imputs and outputs I think that this could make sense.

What do you think?

Eric

--
Don't you think all these XML schema languages should work together?
                                                         http://dsdl.org
------------------------------------------------------------------------
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
------------------------------------------------------------------------




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hello Oliver,

I could not agree more with both of your points.
regards,
Balazs



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Olivier,

You a raising a good use case, and in fact if you look at
PipelineProcessor.java version 1.16, line 304, you will see some
disabled code that is exactly trying to do this! You even find a
comment saying "maybe a flag specifying that we are using a template
should be explicitly specified on the input?"

For some reason (maybe because we did not want to make the syntax of
XPL more complex), we decided not to do more work on this at the time,
but it's good that you are raising this again.

-Erik

Oliver Charlet wrote:
 > Hi there,
 >
 > at this time again a big THANK YOU guys for the great work you do.
 > We all know how much work it is to keep up a project like this and
 > I think you should hear about our appreciation from time to time :-)
 >
 > And here my question / feature request.
 > using orbeon, I noticed that a lot of times you need a transformation
 > to feed the config parameter of some processor. Since that is a lot of
 > code "just" to create a simple <config> document, it would be great
 > to get rid of it, by allowing an xslt on the <input> tag of a processor.
 > I think about a transform attribute, that if it is set to "true"
allows xsl
 > code inside the input data. That could be used just like in the example
 > of the xslt processor in http://www.orbeon.com/ops/doc/processors-xslt
 > (4.4 or 4.6). The root document for the transform would be the actual
 > input defined by the href attribute (if set). To help processor
 > developers, that
 > implicit transform could be implemented in the SimpleProcessor, so
 > that it would require no extra work.
 > I know that there is the aggregate / xpointer extension to the href,
but for
 > me there were a lot of occasions, when I couldn't get to what I wanted
 > with that. Am I the only one with that experience?
 > I hope I didn't miss any other orbeon feature that makes my request
 > obsolete.
 >
 > What do you think?
 >
 > :oliver




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Eric van der Vlist wrote:

> I have been thinking of that kind of thing too and I am wondering if we
> couldn't define something slightly more verbose but still more generic.
I think this would make sense. It is a more generic solution than the
one we had in mind at the time, and the one just suggested by Olivier.
However, it is harder to implement than the specifi
"transformation-only" solution.

Scoping rules would be fairly simple: the only difference is that the
input name is in scope and can be src'ed, as you showed. Other outputs
would be strictly local, like in an p:when or p:for-each.

Maybe this suggestion could also help rationalize the names of elements
in the XPL 1.0 proposal:

http://www.w3.org/Submission/2005/SUBM-xpl-20050411/

-Erik



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Erik Bruchez schrieb:

Eric van der Vlist wrote:

I have been thinking of that kind of thing too and I am wondering if we
couldn't define something slightly more verbose but still more generic.

Maybe we could just allow to write that as:

    <p:processor name="oxf:url-generator">
        <p:input name="config">
            <p:processor name="oxf:xslt">
                <p:input name="data" href="#instance"/>
                <p:input name="config">
                    <config xsl:version="1.0">
                        <url>
                            <xsl:value-of select="escape-uri(/form/path, false())"/>
                        </url>
                        <content-type>application/octet-stream</content-type>
                    </config>
                </p:input>
                <p:output name="data" ref="config" debug="url-generator-config"/>
            </p:processor>
        </p:input>
        <p:output name="data" id="document"/>
    </p:processor>


The trick would be to consider that when the child element of a p:input
is a p:processor, this input is connected to the output of the embedded
processor.

That would allow a "Russian doll" style that is easier to read when it
is used with moderation...

There would be of course some details to specify such as the scope of
imputs and outputs I think that this could make sense.
What do you think?

I think this would make sense. It is a more generic solution than the one we had in mind at the time, and the one just suggested by Olivier.

sure, but I think the basic idea about this is to reduce code inside a pipeline. The hierarchical structure IMO is even harder to read and understand than a sequence of processor calls. I see a real advantage in this:

instead of this:

    <!-- create the URL to the project's requirements -->
    <p:processor name="oxf:xslt-2.0">
        <p:input name="data" href="#request"/>
        <p:input name="config">
             <config xsl:version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
                <url><xsl:value-of select="concat('oxf:/main/projects/', doc('#request')/request/query-string, '/requirements.xml')"/></url>
             </config>
        </p:input>
        <p:output name="data" id="url-config"/>
    </p:processor>
   
    <!-- load the project's requirements -->
    <p:processor name="oxf:url-generator">
        <p:input name="config" href="#url-config"/>
        <p:output name="data" id="requirements"/>
    </p:processor>

i'd like this:

    <!-- load the project's requirements -->
    <p:processor name="oxf:url-generator">
        <p:input name="request" href="#request">
        <p:input name="config" href="#url-config" transformer="oxf:xslt">
             <config xsl:version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
                <url><xsl:value-of select="concat('oxf:/main/projects/', doc('#request')/request/query-string, '/requirements.xml')"/></url>
             </config>
        </p:input>
        <p:output name="data" id="requirements"/>
    </p:processor>

if you'd cascade processor calls, you'd still have to configure the processor tag and its input and output parameters.
sure my version is not as generic, but than I see only very limited use cases in cascading arbitrary processors, as a lot
of combinations probably make no sense.

However, it is harder to implement than the specifi "transformation-only" solution.

Scoping rules would be fairly simple: the only difference is that the input name is in scope and can be src'ed, as you showed. Other outputs would be strictly local, like in an p:when or p:for-each.

Maybe this suggestion could also help rationalize the names of elements in the XPL 1.0 proposal:

http://www.w3.org/Submission/2005/SUBM-xpl-20050411/

-Erik

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: [hidden email]
For general help: [hidden email]
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
  

-- 
-----------------------
oliver charlet
software development

11-041 Olsztyn, Poland

[hidden email]
-----------------------

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hello,

I would also vote for any less verbose solution. XPL - especially when the beasts get large including some non trivial logic - already feels to me like not something that is meant for direct editing.

regards,
Balazs



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Oliver Charlet wrote:

> sure, but I think the basic idea about this is to reduce code inside a
> pipeline. The hierarchical structure IMO is even harder to read and
> understand than a sequence of processor calls. I see a real advantage in
> this:

> if you'd cascade processor calls, you'd still have to configure the
> processor tag and its input and output parameters.
> sure my version is not as generic, but than I see only very limited use
> cases in cascading arbitrary processors, as a lot
> of combinations probably make no sense.

I think this makes sense :-)

Eric, do you have a use case where the cascaded processors would solve
more than identifier space "pollution"?

-Erik



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Erik,

Le mardi 29 novembre 2005 à 01:06 +0100, Erik Bruchez a écrit : No, that's pure syntactical sugar...

A couple of comments on that:

     1. I have already mentioned the way RELAX NG has introduced a
        normative simplification phase in its specification to simplify
        both the formal description of the language and implementations.
        I think that this could be an option for introducing features in
        XPL that are just syntactical without over complicating the
        implementation (which already looks complex enough when you peek
        into the code)...
     2. I am often wondering if using something as complex as XSLT for
        performing simple operations (such as text replacement in a
        config input) isn't impacting the performances. Would it be
        worth to write a simple "XPath processor" that would replace
        XPath expressions in curly brackets by the evaluation of these
        expressions? That would be a kind of replacement of the XSLT
        "{}" syntax available in attributes and that would easily be
        implementable as a SAX filter.

Instead of writing;

    <p:processor name="oxf:xslt">
        <p:input name="data" href="#instance"/>
        <p:input name="config">
            <config xsl:version="1.0">
                <url>
                    <xsl:value-of select="escape-uri(/form/path, false())"/>
                </url>
                <content-type>application/octet-stream</content-type>
            </config>
        </p:input>
        <p:output name="data" id="url-generator-config"/>
    </p:processor>

you'd write :

    <p:processor name="oxf:xpath">
        <p:input name="data" href="#instance"/>
        <p:input name="config">
            <config xsl:version="1.0">
                <url>{escape-uri(/form/path, false())"}</url>
                <content-type>application/octet-stream</content-type>
            </config>
        </p:input>
        <p:output name="data" id="url-generator-config"/>
    </p:processor>

Note; this suggestion is for performance optimization and it's
orthogonal to the fact of allowing Russian doll syntaxes and/or "Russian
doll shortcuts" that could take the form of:

    <p:processor name="oxf:url-generator">
        <p:input name="request" href="#request">
        <p:input name="config" href="#instance">
            <config>
                <url>{escape-uri(/form/path, false())"}</url>
                <content-type>application/octet-stream</content-type>
            </config>
        </p:input>
        <p:output name="data" id="document"/>
    </p:processor>

I have mixed feelings about reusing the href attribute in the input to
define the instance document against which the XPath expressions will be
evaluated...

Eric

--
Have you ever thought about unit testing XSLT templates?
                                                     http://xsltunit.org
------------------------------------------------------------------------
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
------------------------------------------------------------------------




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Eric van der Vlist wrote:

 > No, that's pure syntactical sugar...
 >
 > A couple of comments on that:
 >
 >      1. I have already mentioned the way RELAX NG has introduced a
 >         normative simplification phase in its specification to simplify
 >         both the formal description of the language and implementations.
 >         I think that this could be an option for introducing features in
 >         XPL that are just syntactical without over complicating the
 >         implementation (which already looks complex enough when you peek
 >         into the code)...

Uh, really? ;-)

Are you referring here to a full-fledged simplified syntax, or just to
a transformation phase, independently from the syntax?

 >      2. I am often wondering if using something as complex as XSLT for
 >         performing simple operations (such as text replacement in a
 >         config input) isn't impacting the performances. Would it be
 >         worth to write a simple "XPath processor" that would replace
 >         XPath expressions in curly brackets by the evaluation of these
 >         expressions? That would be a kind of replacement of the XSLT
 >         "{}" syntax available in attributes and that would easily be
 >         implementable as a SAX filter.

I see your point, and it is in fact 100% valid. It appears that every
platform out there is implementing its own XML-based template language
(JSP, Velocity, JXTemplate and XSP for Cocoon, FreeMarker, etc.). This
is a trap we would like to avoid, and it looks like we can:

1. We could define a subset of XSLT which could be interpreted more
    efficiently. You could analyze statically the transformation to
    determine if you feed it to your custom, efficient subset-of-XSLT
    transformer, or to a full-fledged XSLT transformer.

2. Your "XPath processor" example in fact runs valid XQuery! And that
    in the same way a subset of XSLT can be defined, your XPath
    processor can be seen as interpreting a subset of XQuery (more or
    less a few minor quirks of XPath 1.0 vs. XQuery 1.0 compatibility)?

Either way (and you can have both), that's one or two less proprietary
languages to learn for the user.

 > Note; this suggestion is for performance optimization and it's
 > orthogonal to the fact of allowing Russian doll syntaxes and/or "Russian
 > doll shortcuts" that could take the form of:
 >
 >     <p:processor name="oxf:url-generator">
 >         <p:input name="request" href="#request">
 >         <p:input name="config" href="#instance">
 >             <config>
 >                 <url>{escape-uri(/form/path, false())"}</url>
 >                 <content-type>application/octet-stream</content-type>
 >             </config>
 >         </p:input>
 >         <p:output name="data" id="document"/>
 >     </p:processor>
 >
 > I have mixed feelings about reusing the href attribute in the input
 > to define the instance document against which the XPath expressions
 > will be evaluated...

Yes, that could be a little confusing, but not that much. I would
certainly add an explicit "transform" attribute on p:input in that
case, which could yield:

   <p:input name="config" href="#instance" transform="oxf:xslt">
     ...

   <p:input name="config" href="#instance" transform="oxf:xquery">
     ...

With this, it's clear that something special happens on the
input. Also, it is necessary to be explicit, so that when you are
actually inlining inputs of an XSLT processor, you don't have two
transformations executed! Finally, it's extensible, and you can decide
what transformer / template language you use, exactly as done in the
PFC.

I think it would be very easy to implement the above, since some code
is already in. The question is whether we should go forward. I guess
experimentally we could.

At any rate anybody is welcome to implement this "XPath template
processor" ;-)

-Erik



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Le mercredi 30 novembre 2005 à 17:23 +0100, Erik Bruchez a écrit : I meant a full-fledged simplified syntax, but "a transformation phase,
independently from the syntax" could be a first step.
Yes, I had though of that too and this would be a good option.

> 2. Your "XPath processor" example in fact runs valid XQuery! And that
>     in the same way a subset of XSLT can be defined, your XPath
>     processor can be seen as interpreting a subset of XQuery (more or
>     less a few minor quirks of XPath 1.0 vs. XQuery 1.0 compatibility)?

I hadn't seen it that way :-) ...
Yes, you could use any processor with config and data inputs and a data
output.

> I think it would be very easy to implement the above, since some code
> is already in. The question is whether we should go forward. I guess
> experimentally we could.
>
> At any rate anybody is welcome to implement this "XPath template
> processor" ;-)

Sure, I'll grant a RAND licence on the idea :-) ...

Eric
>
> -Erik
>
> pièce jointe document plein texte (message-footer.txt)
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
--
Freelance consulting and training.
                                            http://dyomedea.com/english/
------------------------------------------------------------------------
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
------------------------------------------------------------------------




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Le mercredi 30 novembre 2005 à 17:23 +0100, Erik Bruchez a écrit :

>
> At any rate anybody is welcome to implement this "XPath template
> processor" ;-)

This can probably be improved (for instance, I am not sure that the
cache management is OK), but the class attached seems to be doing the
job.

I have taken the same conventions than <xsl:value-of/> and the XPath
expression is replaced by the string value of the first node that is
returned.

There is already an XPathProcessor, internally used by the identity
processor to do aggregations (you'll find statements shemessly copied
from this processor) and I have preferred to name mine
"XpathTransformer" to avoid any confusion.

Hope that helps.

Eric
--
Don't you think all these XML schema languages should work together?
                                                         http://dsdl.org
------------------------------------------------------------------------
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
------------------------------------------------------------------------


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Eric van der Vlist wrote: Thanks, except at Orbeon we have to close our eyes because it's a GPL
license!

-Erik



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

>
> Thanks, except at Orbeon we have to close our eyes because it's a GPL
> license!

That's just the default header I have set up in Eclipse and of course, I
have no problem to change that to a LGPL if you want to integrate it in
OPS...

Eric

--
Did you know it? Python has now a Relax NG (partial) implementation.
                                          http://advogato.org/proj/xvif/
------------------------------------------------------------------------
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
------------------------------------------------------------------------




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Eric van der Vlist wrote:
>>Thanks, except at Orbeon we have to close our eyes because it's a GPL
>>license!
>
>
> That's just the default header I have set up in Eclipse and of course, I
> have no problem to change that to a LGPL if you want to integrate it in
> OPS...

Thanks! Now we can open our eyes again ;-) Of course we can't promise
that we look at this just right now.

-Erik



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws