ones for bugs and
enhancements.
[1]
http://svn.apache.org/repos/asf/incubator/sling/trunk/contrib/scripting/xproc
> Pipeline support
>
>
> Key: SLING-893
> URL: https://issues.apache.org/jira/browse/SLING-893
>
[
https://issues.apache.org/jira/browse/SLING-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SLING-893:
--
Component/s: (was: Extensions)
Xproc
> Pipeline supp
Pipeline support
Key: SLING-893
URL: https://issues.apache.org/jira/browse/SLING-893
Project: Sling
Issue Type: Improvement
Components: Extensions
Affects Versions: 3
Reporter: Juan Jose Vazquez
On Tue, Mar 10, 2009 at 10:43 AM, Juan José Vázquez Delgado
wrote:
>>> ...1. A XML pipeline is expressed as a W3C XProc [2] file with "xpl"
>>> extension
>>
>> Is this "xpl" extension standard?
>> If you're choosing your own I'd prefer not having an L at the end as
>> it's too easy to confuse
> This has been extracted from the XProc candidate recomendation [1].
Sorry, I forgot the link:
[1] http://www.w3.org/TR/xproc/
>> ...1. A XML pipeline is expressed as a W3C XProc [2] file with "xpl"
>> extension
>
> Is this "xpl" extension standard?
> If you're choosing your own I'd prefer not having an L at the end as
> it's too easy to confuse with a I.
> Maybe "xpr" or even "xproc", clearer?
This has been extracte
Hi Juanjo,
On Tue, Mar 10, 2009 at 9:47 AM, Juan José Vázquez Delgado
wrote:
> ...After some work, the pipeline support prototype [1] has ended up as
> follows:...
Cool stuff! Still haven't tested it, shame on me...but your
description looks great.
Just two quick comments for now.
Hi all,
After some work, the pipeline support prototype [1] has ended up as follows:
1. A XML pipeline is expressed as a W3C XProc [2] file with "xpl" extension.
For instance:
http://www.w3.org/ns/xproc";>
2.
On Fri, Feb 20, 2009 at 5:10 AM, paksegu wrote:
> Though I am late to this discussion, taken an excerpt form previous discussion
>
> "I could imagine a XML generator that simply does an xml document view of the
> node in question." [ An excerpt from previous discussion]
>
> then using *something
with_E4X
https://developer.mozilla.org/En/E4X
Ransford Segu-Baffoe
paks...@yahoo.com
http://www.noqmx.com/
https://serenade.dev.java.net/
--- On Tue, 2/10/09, Carsten Ziegeler wrote:
From: Carsten Ziegeler
Subject: Re: Pipeline support
To: sling-dev@incubator.apache.org
Date: Tuesday, February 10
qmx.com/
https://serenade.dev.java.net/
--- On Tue, 2/10/09, Carsten Ziegeler wrote:
From: Carsten Ziegeler
Subject: Re: Pipeline support
To: sling-dev@incubator.apache.org
Date: Tuesday, February 10, 2009, 8:46 AM
Alexander Klimetschek wrote:
> On Tue, Feb 10, 2009 at 12:13 PM, Felix Meschberge
Hi guys,
Last days, i have been working on a new prototype about a certain kind
of XML pipelines support in Sling [1]. The prototype is making these
main assumptions:
1. A XML pipeline is expressed as a W3C XProc [2] file with "xpl"
extension. For instance:
http://www.w3.org/ns/xproc";>
Hi Felix,
> Yes. I think there are multiple options for the input
>
> * apply standard Sling processing as in
> RequestDispatcher.include(resource, resourceTypeOverWrite)
I´m not sure what you mean with this case. I understand, the pipeline
source would be the XML expressed result of r
Hi,
Juan José Vázquez Delgado schrieb:
>>> On the other hand, IMHO the datasources would be into the "content
>>> resource" as properties (/a/b/data in your proposal).
>> I fear, I do not understand this sentence.
>
> Sorry, I mean, I don´t know if all data you need in order to compose
> the firs
>> On the other hand, IMHO the datasources would be into the "content
>> resource" as properties (/a/b/data in your proposal).
>
> I fear, I do not understand this sentence.
Sorry, I mean, I don´t know if all data you need in order to compose
the first XML (pipeline generator) would be resource´s
Hi Juanjo,
Juan José Vázquez Delgado schrieb:
> Thanks for your smart response.
.. and thanks for the flowers ;-)
> [snip]
>> There is yet another alternative, which also sounds intriguing: We
>> define a ScriptEngineFactory for the ".pipeline" extension. Files with
>> the extension .pipeline
> However whereas this is one important use case I see another use case
> where I simply want to "run" a pipeline on generated output of some
> script like for doing link checking or doing other general purpuse stuff.
Until now, I have just been thinking about XSL based transformers
acting over ge
Thanks for your smart response.
> I think your approach is very lightweight (which is good) and
> straightforward.
That´s right. My goal was having a sample as much as simple as possible.
> The problem I see, is that you actually need two
> resources (you don't need a Node if you do resource.ada
On Tue, Feb 10, 2009 at 2:52 PM, Felix Meschberger wrote:
>> However whereas this is one important use case I see another use case
>> where I simply want to "run" a pipeline on generated output of some
>> script like for doing link checking or doing other general purpuse stuff.
>>
>> In this case
Hi,
Carsten Ziegeler schrieb:
> Alexander Klimetschek wrote:
>> On Tue, Feb 10, 2009 at 12:13 PM, Felix Meschberger
>> wrote:
>>> There is yet another alternative, which also sounds intriguing: We
>>> define a ScriptEngineFactory for the ".pipeline" extension. Files with
>>> the extension .pipe
Alexander Klimetschek wrote:
> On Tue, Feb 10, 2009 at 12:13 PM, Felix Meschberger
> wrote:
>> There is yet another alternative, which also sounds intriguing: We
>> define a ScriptEngineFactory for the ".pipeline" extension. Files with
>> the extension .pipeline would be pipeline configurations,
On Tue, Feb 10, 2009 at 12:13 PM, Felix Meschberger wrote:
> There is yet another alternative, which also sounds intriguing: We
> define a ScriptEngineFactory for the ".pipeline" extension. Files with
> the extension .pipeline would be pipeline configurations, which would be
> interpreted by the
Hi Juanjo,
Juan José Vázquez Delgado schrieb:
> In response to this thread [1] in the Apache Cocoon Dev list, I have
> been working in a minimal sample [2] concerning about resolution of
> pipelines and Apache Sling. IMHO, having pipeline support in Sling is
> an important feature
> There are two possibilities:
>
> Either make a pipeline a script, or let a script (jsp, groovy etc.)
> generate xml and use a pipeline for postprocessing.
In fact, my sample is in line with your second option. The XSL
templates are retrieved from resources, too.
Juanjo.
Hi,
Juan José Vázquez Delgado wrote:
> Hi,
>
> In response to this thread [1] in the Apache Cocoon Dev list, I have
> been working in a minimal sample [2] concerning about resolution of
> pipelines and Apache Sling. IMHO, having pipeline support in Sling is
> an important f
Hi,
In response to this thread [1] in the Apache Cocoon Dev list, I have
been working in a minimal sample [2] concerning about resolution of
pipelines and Apache Sling. IMHO, having pipeline support in Sling is
an important feature in terms of separation of concerns.
On the other hand, because
26 matches
Mail list logo
