You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Vidar Ramdal <vi...@idium.no> on 2009/02/13 18:22:26 UTC
Proposal: Extend o.a.s.j.c.i.r.XmlReader to support XSL
transformations
I have a couple of cases where I want to import initial content from a
bundle. In my cases, it makes most sense to store the data as XML
files, and let XmlReader install it.
However, the XML format supported by XmlReader is a bit too verbose to
be practical in many cases.
At [1] Felix Meschberger writes:
> (1) Initial Content Loading
> ...
> The format support is currently hardcoded and only
> extensible by extending the bundle itself. Yet, there
> have been discussions on making this support extensible.
One easy way to get extensible format support, at least when speaking
of XML formats, is to let XmlReader look for a reference to an XSL
stylesheet in the XML file (<?xml-stylesheet type="text/xsl"
href="stylesheet.xsl"?>). Alternatively, the XSL reference could be
specified in the Sling-Initial-Content manifest field.
stylesheet.xsl would then be responsible of translating the contents
of the XML file into the XML format supported by XmlReader.
XmlReader would then transform the XML file according to the XSL, and
process the resulting output as it would usually.
This would greatly simplify the task of working with initial-content,
as you could make up my own XML format that suits the content you're
writing, as long as you also write the XSL file.
So, what do you think? If you believe this is a good idea, I could
take a shot at implementing it.
[1] http://markmail.org/message/pedlbv6x6zyq5no6
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: Proposal: Extend o.a.s.j.c.i.r.XmlReader to support XSL
transformations
Posted by Vidar Ramdal <vi...@idium.no>.
On Tue, Feb 17, 2009 at 1:05 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Lets go with the ContentReader API change you propose. It is not
> exported from the bundle so we are free to adapt it as we need.
Patch awaiting approval at https://issues.apache.org/jira/browse/SLING-857
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: Proposal: Extend o.a.s.j.c.i.r.XmlReader to support XSL transformations
Posted by Felix Meschberger <fm...@gmail.com>.
Vidar Ramdal schrieb:
> On Fri, Feb 13, 2009 at 6:22 PM, Vidar Ramdal <vi...@idium.no> wrote:
>> One easy way to get extensible format support, at least when speaking
>> of XML formats, is to let XmlReader look for a reference to an XSL
>> stylesheet in the XML file (<?xml-stylesheet type="text/xsl"
>> href="stylesheet.xsl"?>).
>
> I've come really close to implementing this, but I have hit a wall
> when it comes to resolving the location of the XSL.
> In the example above, one would consider "stylesheet.xsl" to be a
> relative path to the XSL - relative from the XML file.
> However, I can't make XmlReader resolve the XSL file, as XmlReader
> only gets an InputStream of the XML, which contains no information on
> the XML's location.
>
> One option would be to change
> o.a.s.j.c.i.ContentReader#parse(InputStream, ContentCreator) to
> parse(URL, ContentCreator).
> This would mean making ContentReaders responsible for opening and
> closing the InputStream from the URL.
> It seems that every caller of ContentReader.parse knows the URL of the
> inputstream it is passing to the ContentReader, so that should not be
> too much work.
+1 to this change. It makes perfect sense.
>
> Another option would be to only support absolute URLs when refering to
> the XSL file. This works in my current implementation, as long as the
> XSL is not located in a bundle.
> But in many cases the XSL *would* be supplied in a bundle, I believe
> bundle resources can be addressed by bundle://bundle-id/etc, but I
> don't know the bundle ID before the bundle is installed, right?
>
> Any suggestions?
Lets go with the ContentReader API change you propose. It is not
exported from the bundle so we are free to adapt it as we need.
Regards
Felix
Re: Proposal: Extend o.a.s.j.c.i.r.XmlReader to support XSL
transformations
Posted by Vidar Ramdal <vi...@idium.no>.
On Fri, Feb 13, 2009 at 6:22 PM, Vidar Ramdal <vi...@idium.no> wrote:
> One easy way to get extensible format support, at least when speaking
> of XML formats, is to let XmlReader look for a reference to an XSL
> stylesheet in the XML file (<?xml-stylesheet type="text/xsl"
> href="stylesheet.xsl"?>).
I've come really close to implementing this, but I have hit a wall
when it comes to resolving the location of the XSL.
In the example above, one would consider "stylesheet.xsl" to be a
relative path to the XSL - relative from the XML file.
However, I can't make XmlReader resolve the XSL file, as XmlReader
only gets an InputStream of the XML, which contains no information on
the XML's location.
One option would be to change
o.a.s.j.c.i.ContentReader#parse(InputStream, ContentCreator) to
parse(URL, ContentCreator).
This would mean making ContentReaders responsible for opening and
closing the InputStream from the URL.
It seems that every caller of ContentReader.parse knows the URL of the
inputstream it is passing to the ContentReader, so that should not be
too much work.
Another option would be to only support absolute URLs when refering to
the XSL file. This works in my current implementation, as long as the
XSL is not located in a bundle.
But in many cases the XSL *would* be supplied in a bundle, I believe
bundle resources can be addressed by bundle://bundle-id/etc, but I
don't know the bundle ID before the bundle is installed, right?
Any suggestions?
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: Proposal: Extend o.a.s.j.c.i.r.XmlReader to support XSL transformations
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi,
>
> Sounds like an interesting idea, we could even provide some default
> transformations...
>
> The only fear I have is, that this might introduce a huge pile of
> dependencies ?
>
No I don't think so - everything we need for that is in the java 1.5.
And starting the transformation is just a few lines of code :) (Just
trying to set the barrier a little bit higher here)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Proposal: Extend o.a.s.j.c.i.r.XmlReader to support XSL transformations
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Vidar,
Vidar Ramdal schrieb:
> On Fri, Feb 13, 2009 at 7:30 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> Hi,
>>
>> Sounds like an interesting idea, we could even provide some default
>> transformations...
>>
>> The only fear I have is, that this might introduce a huge pile of
>> dependencies ?
>
> I think we should be fine by just depending on Xalan, which again
> depends on Xerces.
> I'll have a look at it over the weekend.
Sorry for the late reply. Incidentally, I just played around with XSLT
over the weekend and JAXP (javax.xml.transform) seems to have everything
in it, so it perfectly works without any more depdencies.
Regards
Felix
Re: Proposal: Extend o.a.s.j.c.i.r.XmlReader to support XSL
transformations
Posted by Vidar Ramdal <vi...@idium.no>.
On Fri, Feb 13, 2009 at 7:30 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Sounds like an interesting idea, we could even provide some default
> transformations...
>
> The only fear I have is, that this might introduce a huge pile of
> dependencies ?
I think we should be fine by just depending on Xalan, which again
depends on Xerces.
I'll have a look at it over the weekend.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: Proposal: Extend o.a.s.j.c.i.r.XmlReader to support XSL transformations
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Sounds like an interesting idea, we could even provide some default
transformations...
The only fear I have is, that this might introduce a huge pile of
dependencies ?
Regards
Felix
Vidar Ramdal schrieb:
> I have a couple of cases where I want to import initial content from a
> bundle. In my cases, it makes most sense to store the data as XML
> files, and let XmlReader install it.
> However, the XML format supported by XmlReader is a bit too verbose to
> be practical in many cases.
>
> At [1] Felix Meschberger writes:
>> (1) Initial Content Loading
>> ...
>> The format support is currently hardcoded and only
>> extensible by extending the bundle itself. Yet, there
>> have been discussions on making this support extensible.
>
> One easy way to get extensible format support, at least when speaking
> of XML formats, is to let XmlReader look for a reference to an XSL
> stylesheet in the XML file (<?xml-stylesheet type="text/xsl"
> href="stylesheet.xsl"?>). Alternatively, the XSL reference could be
> specified in the Sling-Initial-Content manifest field.
>
> stylesheet.xsl would then be responsible of translating the contents
> of the XML file into the XML format supported by XmlReader.
> XmlReader would then transform the XML file according to the XSL, and
> process the resulting output as it would usually.
>
> This would greatly simplify the task of working with initial-content,
> as you could make up my own XML format that suits the content you're
> writing, as long as you also write the XSL file.
>
> So, what do you think? If you believe this is a good idea, I could
> take a shot at implementing it.
>
> [1] http://markmail.org/message/pedlbv6x6zyq5no6