You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xalan.apache.org by Johan Zxcer <na...@zurahn.com> on 2009/02/28 18:34:22 UTC
Usage model - no source XML, just api calls
I am new to the world of XSL and Xalan, and I've been trying to understand
whether my usage model is possible, common, or advisable. I simply want to
use a stylesheet with no source document, instead using only calls into my
API to fetch data. I've created an XPath instance to generate some results,
but cannot figure out how to actually hook it to the transformer, so that it
is used exclusively as the data source. None of the samples, nor anything
I've found online seem to use XPath this way. What am I missing, and are
there any examples on this sort of usage model I could use as a reference?
Thanks in advance.
johan
PS. If it matters, the reason I'm trying to do this: I have a fairly
complex data model (stored in a db, but no matter) that is not strictly
hierarchical and could be accessed in many ways for different reasons. It
would not be easy to generate a source XML that would contain all the
possible iterations of data that may be needed by a particular style sheet.
Nor is it feasible to provide all the raw data to be operated on by XSL
operators and extension functions, due to both complexity and security of
non-aggregated data. Finally, the stylesheet is intended to be created by
external users of the system, so for security and simplicity a limited API
that presents the data in specific calculated fashion is really required.
--
View this message in context: http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22264025.html
Sent from the Xalan - J - Users mailing list archive at Nabble.com.
Re: Usage model - no source XML, just api calls
Posted by ke...@us.ibm.com.
Note that in most cases where you're concerned about security, you should
already be running user-provided code -- including stylesheets -- in a
Java "sandbox" environment, using Java's own security features to
constrain what classes can be loaded, what parts of the filesystem can be
accessed, and so on. If that can protect you from abusive Java, it
certainly should be able to protect you from abusive Xalan.
______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
-- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (
http://www.ovff.org/pegasus/songs/threes-rev-11.html)
Re: Usage model - no source XML, just api calls
Posted by ke...@us.ibm.com.
I don't know of anything built into Xalan for the purpose, though it's
certainly an interesting suggestion.
______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
-- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (
http://www.ovff.org/pegasus/songs/threes-rev-11.html)
"Dave Brosius" <db...@mebigfatguy.com>
03/01/2009 07:58 PM
To
"Johan Zxcer" <na...@zurahn.com>, <xa...@xml.apache.org>
cc
Subject
Re: Usage model - no source XML, just api calls
>> So is there any way of limiting which java classes
> can be accessed as extensions?
I doubt it.
I'm assuming you have a set of classes that provide all the secure
information, however. If a user altered the style sheet, added their own
extension functions, don't they still have to add some point then call
your
classes to get the secure information, and therefore, isn't that the point
were you
can enforce security. Perhaps, i'm still not grasping the entirety of your
problem.
----- Original Message -----
From: "Johan Zxcer" <na...@zurahn.com>
To: <xa...@xml.apache.org>
Sent: Sunday, March 01, 2009 4:39 PM
Subject: Re: Usage model - no source XML, just api calls
>
> Yes, extensions are where I started and provide exactly what I need -
> except
> that I couldn't find any mechanism for limiting the set of java classes
> that
> are available as Xalan extensions. Given that a style sheet is editable
> by
> a non-privileged user, it would be a glaring security hole that isn't
> mentioned in the xalan docs, the below link, or any other examples of
> extensions I've found. So is there any way of limiting which java
classes
> can be accessed as extensions?
>
> Thanks for your patience..
>
> johan
>
>
> Dave Brosius-2 wrote:
>>
>> Perhaps xalan extension functions are what you are after.
>>
>> http://www.ibm.com/developerworks/library/x-xalanextensions.html
>>
>
> --
> View this message in context:
>
http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22278384.html
> Sent from the Xalan - J - Users mailing list archive at Nabble.com.
>
Re: Usage model - no source XML, just api calls
Posted by Johan Zxcer <na...@zurahn.com>.
The set of classes to provide the info does implement the proper security,
but I can't see anything restricting the (non-privileged) author of the
style sheet from maliciously calling other classes' methods, for example sql
or File, in whatever way they want; this appears to be why the
FEATURE_SECURE_PROCESSING flag was created to turn off function extensions.
The server which would be processing the transformations has full access to
the information (not to mention file systems etc), but is firewalled and
securely presents information to web-based clients. XSL looks like a great
way to let clients build xhtml-formatted reports using a limited set of
functions I provide to access the information.
I suppose I could create a separate java "client" process specifically for
this purpose and sandbox it into a safe place, but I think the
effort/duplication/maintainence would be huge relative to what I'm trying to
accomplish..
Dave Brosius-2 wrote:
>
>>> So is there any way of limiting which java classes
>> can be accessed as extensions?
>
>
> I doubt it.
>
> I'm assuming you have a set of classes that provide all the secure
> information, however. If a user altered the style sheet, added their own
> extension functions, don't they still have to add some point then call
> your
> classes to get the secure information, and therefore, isn't that the point
> were you
> can enforce security. Perhaps, i'm still not grasping the entirety of your
> problem.
>
>
--
View this message in context: http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22280776.html
Sent from the Xalan - J - Users mailing list archive at Nabble.com.
Re: Usage model - no source XML, just api calls
Posted by Johan Zxcer <na...@zurahn.com>.
I think this would be a good way to go, and easy since this is already
supported internally - just not specifiable. I've now modified my Xalan to
pass my own SecurityManager and everything looks to be working the way I
need. I'll post this suggestion on the issue tracker. Thanks for the help!
bimargulies wrote:
>
> Xalan could play in the general Java Security Manager framework and
> allow you to bound the set of extension functions, if only by allowing
> you to specify the classloader.
>
> On Mon, Mar 2, 2009 at 12:57 PM, Johan Zxcer <na...@zurahn.com> wrote:
>> Back to practical reality though, it sounds like there is no such API
>> mechanism built in to Xalan. However looking at the
>> extension/ObjectFactory
>> class, I may be able to accomplish what I need by temporarily changing
>> the
>> current SecurityManager in place to set the limits I need, and Xalan will
>> respect that. Not exactly thread safe, I'll post how it works out
>> though..
>>
>>
>> bimargulies wrote:
>>>
>>> From: Benson Margulies <bi...@gmail.com>
>>> Date: Sun, Mar 1, 2009 at 8:46 PM
>>> Subject: Re: Usage model - no source XML, just api calls
>>> To: Dave Brosius <db...@mebigfatguy.com>
>>>
>>>
>>> This whole story doesn't make sense entirely from a security
>>> standpoint. Let's see if I've got this straight:
>>>
>>> people you don't trust to look at the data are allows to write and
>>> render stylesheets. The JVM is connected to a database full of data
>>> they aren't allowed to see in detail, only in summary. You are
>>> concerned that they will go fishing for functions that would allow
>>> them to grab what they cannot see.
>>>
>>> From a security standpoint, I'd say that you need some more
>>> architecture here. Like, put the sensitive data behind a web service,
>>> require authentication, and have the web service API be just the
>>> allowed aggregating functions. Then turn them loose on Xalan/xslt,
>>> secure in the knowledge that all they can do by being cute is shoot
>>> themselves in the feet.
>>>
>>>
>
Yeah, this is in essence what I'm doing, but within the context of a larger
app I needed a way to restrict what classes were available as extensions, to
avoid the obvious security hole!
Dennis van der Laan wrote:
>
> Hi,
>
> We built a (web) content management system using Xalan XSLT for
> transforming XML-documents into one HTML file...
>
--
View this message in context: http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22311143.html
Sent from the Xalan - J - Users mailing list archive at Nabble.com.
Re: Usage model - no source XML, just api calls
Posted by Benson Margulies <bi...@gmail.com>.
Xalan could play in the general Java Security Manager framework and
allow you to bound the set of extension functions, if only by allowing
you to specify the classloader.
On Mon, Mar 2, 2009 at 12:57 PM, Johan Zxcer <na...@zurahn.com> wrote:
>
> I disagree that Xalan by definition is doing something that should have to be
> treated specially versus all the other packages I must trust in order to
> build a service.
>
> Assume a web client-server app with the proper layers of security and
> authentication in place. Add to this an XSL processor with extensions
> disabled (and proper settings to avoid deep recursion etc); the style-sheet
> itself is anything from the client, but the static data source is strictly
> controlled by the server. No issue here, the processor is strictly bound by
> the data provided to it, no need for an extra layer of security.
>
> Now I want to expose a useful function - say sin(). If I could specify that
> just the Math class be exposed for use as extensible functions, have I
> changed my security vulnerabilities? No, I'm simply exposing a controlled
> set of functions; there's no reason to suddenly make everything more complex
> simply to isolate the processor. But if the only choice is to expose all
> classes available to a given process, I am forced to create a separate
> process to manage these, including the IPC needed to get to the information
> back and forth.
>
> Now I'm not at all against doing the work necessary to build a secure
> application, but this forces a particular architecture that adds a lot of
> complexity and maintenance, when a simple whitelist would be just as secure
> (and perhaps more secure in the grand scheme, how many Xalan users have
> built apps not realizing that by default all java classes are available to
> be run by a *style sheet*?)
>
> Back to practical reality though, it sounds like there is no such API
> mechanism built in to Xalan. However looking at the extension/ObjectFactory
> class, I may be able to accomplish what I need by temporarily changing the
> current SecurityManager in place to set the limits I need, and Xalan will
> respect that. Not exactly thread safe, I'll post how it works out though..
>
>
> bimargulies wrote:
>>
>> From: Benson Margulies <bi...@gmail.com>
>> Date: Sun, Mar 1, 2009 at 8:46 PM
>> Subject: Re: Usage model - no source XML, just api calls
>> To: Dave Brosius <db...@mebigfatguy.com>
>>
>>
>> This whole story doesn't make sense entirely from a security
>> standpoint. Let's see if I've got this straight:
>>
>> people you don't trust to look at the data are allows to write and
>> render stylesheets. The JVM is connected to a database full of data
>> they aren't allowed to see in detail, only in summary. You are
>> concerned that they will go fishing for functions that would allow
>> them to grab what they cannot see.
>>
>> From a security standpoint, I'd say that you need some more
>> architecture here. Like, put the sensitive data behind a web service,
>> require authentication, and have the web service API be just the
>> allowed aggregating functions. Then turn them loose on Xalan/xslt,
>> secure in the knowledge that all they can do by being cute is shoot
>> themselves in the feet.
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22293216.html
> Sent from the Xalan - J - Users mailing list archive at Nabble.com.
>
>
Re: Usage model - no source XML, just api calls
Posted by David Bertoni <db...@apache.org>.
Johan Zxcer wrote:
> I disagree that Xalan by definition is doing something that should have to be
> treated specially versus all the other packages I must trust in order to
> build a service.
How about just pre-parsing the stylesheet yourself and reporting an
error if the stylesheet contains any extension functions other than the
ones you allow?
If you really want to get fancy, you could extend Xalan-J's XPath
parsing code to do this. Otherwise, you can simply looking for
namespace bindings that shouldn't be there, since the only way to call
an extension function is through a namespace.
If you can use C++, instead of Java, you can use Xalan-C, which only
allows user-provided extension function, making it impossible for users
to call arbitrary code.
Dave
Re: Usage model - no source XML, just api calls
Posted by Dennis van der Laan <d....@rug.nl>.
Hi,
We built a (web) content management system using Xalan XSLT for
transforming XML-documents into one HTML file. We basically use your
described model: we start by running an XSL without a source document
(or actually an empty XML document). The XSL may then call Java methods
on a given context-object (a Java object which is given as a parameter
to the Transform). In our system, a call to the context object could
invoke another XSL transform on an XML-document, returning the result of
the transform for further processing. This may result in a complex tree
of transforms.
As a simple example:
<xsl:stylesheet xmlns:java="http://xml.apache.org/xslt/java"
exclude-result-prefixes="java">
<xsl:param name="context"/>
<xsl:template match="/">
<result>
<xsl:value-of select="concat('Hello,', java:getUserName($context))"/>
</result>
</xsl:template>
</xsl:stylesheet>
The 'context' object may be any Java object which has the method
'getUserName()'. You could create a different 'context' instance, based
on the authorization of the client. In fact, you could check the client
XSL's by processing them with your own XSL and check if only the
'context' parameter is used for Java-calls.
Dennis
Johan Zxcer wrote:
> I disagree that Xalan by definition is doing something that should have to be
> treated specially versus all the other packages I must trust in order to
> build a service.
>
> Assume a web client-server app with the proper layers of security and
> authentication in place. Add to this an XSL processor with extensions
> disabled (and proper settings to avoid deep recursion etc); the style-sheet
> itself is anything from the client, but the static data source is strictly
> controlled by the server. No issue here, the processor is strictly bound by
> the data provided to it, no need for an extra layer of security.
>
> Now I want to expose a useful function - say sin(). If I could specify that
> just the Math class be exposed for use as extensible functions, have I
> changed my security vulnerabilities? No, I'm simply exposing a controlled
> set of functions; there's no reason to suddenly make everything more complex
> simply to isolate the processor. But if the only choice is to expose all
> classes available to a given process, I am forced to create a separate
> process to manage these, including the IPC needed to get to the information
> back and forth.
>
> Now I'm not at all against doing the work necessary to build a secure
> application, but this forces a particular architecture that adds a lot of
> complexity and maintenance, when a simple whitelist would be just as secure
> (and perhaps more secure in the grand scheme, how many Xalan users have
> built apps not realizing that by default all java classes are available to
> be run by a *style sheet*?)
>
> Back to practical reality though, it sounds like there is no such API
> mechanism built in to Xalan. However looking at the extension/ObjectFactory
> class, I may be able to accomplish what I need by temporarily changing the
> current SecurityManager in place to set the limits I need, and Xalan will
> respect that. Not exactly thread safe, I'll post how it works out though..
>
>
> bimargulies wrote:
>
>> From: Benson Margulies <bi...@gmail.com>
>> Date: Sun, Mar 1, 2009 at 8:46 PM
>> Subject: Re: Usage model - no source XML, just api calls
>> To: Dave Brosius <db...@mebigfatguy.com>
>>
>>
>> This whole story doesn't make sense entirely from a security
>> standpoint. Let's see if I've got this straight:
>>
>> people you don't trust to look at the data are allows to write and
>> render stylesheets. The JVM is connected to a database full of data
>> they aren't allowed to see in detail, only in summary. You are
>> concerned that they will go fishing for functions that would allow
>> them to grab what they cannot see.
>>
>> From a security standpoint, I'd say that you need some more
>> architecture here. Like, put the sensitive data behind a web service,
>> require authentication, and have the web service API be just the
>> allowed aggregating functions. Then turn them loose on Xalan/xslt,
>> secure in the knowledge that all they can do by being cute is shoot
>> themselves in the feet.
>>
>>
>>
>
>
--
Dennis van der Laan
Re: Usage model - no source XML, just api calls
Posted by Johan Zxcer <na...@zurahn.com>.
I disagree that Xalan by definition is doing something that should have to be
treated specially versus all the other packages I must trust in order to
build a service.
Assume a web client-server app with the proper layers of security and
authentication in place. Add to this an XSL processor with extensions
disabled (and proper settings to avoid deep recursion etc); the style-sheet
itself is anything from the client, but the static data source is strictly
controlled by the server. No issue here, the processor is strictly bound by
the data provided to it, no need for an extra layer of security.
Now I want to expose a useful function - say sin(). If I could specify that
just the Math class be exposed for use as extensible functions, have I
changed my security vulnerabilities? No, I'm simply exposing a controlled
set of functions; there's no reason to suddenly make everything more complex
simply to isolate the processor. But if the only choice is to expose all
classes available to a given process, I am forced to create a separate
process to manage these, including the IPC needed to get to the information
back and forth.
Now I'm not at all against doing the work necessary to build a secure
application, but this forces a particular architecture that adds a lot of
complexity and maintenance, when a simple whitelist would be just as secure
(and perhaps more secure in the grand scheme, how many Xalan users have
built apps not realizing that by default all java classes are available to
be run by a *style sheet*?)
Back to practical reality though, it sounds like there is no such API
mechanism built in to Xalan. However looking at the extension/ObjectFactory
class, I may be able to accomplish what I need by temporarily changing the
current SecurityManager in place to set the limits I need, and Xalan will
respect that. Not exactly thread safe, I'll post how it works out though..
bimargulies wrote:
>
> From: Benson Margulies <bi...@gmail.com>
> Date: Sun, Mar 1, 2009 at 8:46 PM
> Subject: Re: Usage model - no source XML, just api calls
> To: Dave Brosius <db...@mebigfatguy.com>
>
>
> This whole story doesn't make sense entirely from a security
> standpoint. Let's see if I've got this straight:
>
> people you don't trust to look at the data are allows to write and
> render stylesheets. The JVM is connected to a database full of data
> they aren't allowed to see in detail, only in summary. You are
> concerned that they will go fishing for functions that would allow
> them to grab what they cannot see.
>
> From a security standpoint, I'd say that you need some more
> architecture here. Like, put the sensitive data behind a web service,
> require authentication, and have the web service API be just the
> allowed aggregating functions. Then turn them loose on Xalan/xslt,
> secure in the knowledge that all they can do by being cute is shoot
> themselves in the feet.
>
>
--
View this message in context: http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22293216.html
Sent from the Xalan - J - Users mailing list archive at Nabble.com.
Fwd: Usage model - no source XML, just api calls
Posted by Benson Margulies <bi...@gmail.com>.
---------- Forwarded message ----------
From: Benson Margulies <bi...@gmail.com>
Date: Sun, Mar 1, 2009 at 8:46 PM
Subject: Re: Usage model - no source XML, just api calls
To: Dave Brosius <db...@mebigfatguy.com>
This whole story doesn't make sense entirely from a security
standpoint. Let's see if I've got this straight:
people you don't trust to look at the data are allows to write and
render stylesheets. The JVM is connected to a database full of data
they aren't allowed to see in detail, only in summary. You are
concerned that they will go fishing for functions that would allow
them to grab what they cannot see.
>From a security standpoint, I'd say that you need some more
architecture here. Like, put the sensitive data behind a web service,
require authentication, and have the web service API be just the
allowed aggregating functions. Then turn them loose on Xalan/xslt,
secure in the knowledge that all they can do by being cute is shoot
themselves in the feet.
On Sun, Mar 1, 2009 at 7:58 PM, Dave Brosius <db...@mebigfatguy.com> wrote:
>>> So is there any way of limiting which java classes
>>
>> can be accessed as extensions?
>
>
> I doubt it.
>
> I'm assuming you have a set of classes that provide all the secure
> information, however. If a user altered the style sheet, added their own
> extension functions, don't they still have to add some point then call your
> classes to get the secure information, and therefore, isn't that the point
> were you
> can enforce security. Perhaps, i'm still not grasping the entirety of your
> problem.
>
> ----- Original Message ----- From: "Johan Zxcer" <na...@zurahn.com>
> To: <xa...@xml.apache.org>
> Sent: Sunday, March 01, 2009 4:39 PM
> Subject: Re: Usage model - no source XML, just api calls
>
>
>>
>> Yes, extensions are where I started and provide exactly what I need -
>> except
>> that I couldn't find any mechanism for limiting the set of java classes
>> that
>> are available as Xalan extensions. Given that a style sheet is editable
>> by
>> a non-privileged user, it would be a glaring security hole that isn't
>> mentioned in the xalan docs, the below link, or any other examples of
>> extensions I've found. So is there any way of limiting which java classes
>> can be accessed as extensions?
>>
>> Thanks for your patience..
>>
>> johan
>>
>>
>> Dave Brosius-2 wrote:
>>>
>>> Perhaps xalan extension functions are what you are after.
>>>
>>> http://www.ibm.com/developerworks/library/x-xalanextensions.html
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22278384.html
>> Sent from the Xalan - J - Users mailing list archive at Nabble.com.
>>
>
>
Re: Usage model - no source XML, just api calls
Posted by Dave Brosius <db...@mebigfatguy.com>.
>> So is there any way of limiting which java classes
> can be accessed as extensions?
I doubt it.
I'm assuming you have a set of classes that provide all the secure
information, however. If a user altered the style sheet, added their own
extension functions, don't they still have to add some point then call your
classes to get the secure information, and therefore, isn't that the point
were you
can enforce security. Perhaps, i'm still not grasping the entirety of your
problem.
----- Original Message -----
From: "Johan Zxcer" <na...@zurahn.com>
To: <xa...@xml.apache.org>
Sent: Sunday, March 01, 2009 4:39 PM
Subject: Re: Usage model - no source XML, just api calls
>
> Yes, extensions are where I started and provide exactly what I need -
> except
> that I couldn't find any mechanism for limiting the set of java classes
> that
> are available as Xalan extensions. Given that a style sheet is editable
> by
> a non-privileged user, it would be a glaring security hole that isn't
> mentioned in the xalan docs, the below link, or any other examples of
> extensions I've found. So is there any way of limiting which java classes
> can be accessed as extensions?
>
> Thanks for your patience..
>
> johan
>
>
> Dave Brosius-2 wrote:
>>
>> Perhaps xalan extension functions are what you are after.
>>
>> http://www.ibm.com/developerworks/library/x-xalanextensions.html
>>
>
> --
> View this message in context:
> http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22278384.html
> Sent from the Xalan - J - Users mailing list archive at Nabble.com.
>
Re: Usage model - no source XML, just api calls
Posted by Johan Zxcer <na...@zurahn.com>.
Yes, extensions are where I started and provide exactly what I need - except
that I couldn't find any mechanism for limiting the set of java classes that
are available as Xalan extensions. Given that a style sheet is editable by
a non-privileged user, it would be a glaring security hole that isn't
mentioned in the xalan docs, the below link, or any other examples of
extensions I've found. So is there any way of limiting which java classes
can be accessed as extensions?
Thanks for your patience..
johan
Dave Brosius-2 wrote:
>
> Perhaps xalan extension functions are what you are after.
>
> http://www.ibm.com/developerworks/library/x-xalanextensions.html
>
--
View this message in context: http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22278384.html
Sent from the Xalan - J - Users mailing list archive at Nabble.com.
Re: Usage model - no source XML, just api calls
Posted by Dave Brosius <db...@mebigfatguy.com>.
Perhaps xalan extension functions are what you are after.
http://www.ibm.com/developerworks/library/x-xalanextensions.html
----- Original Message -----
From: "Johan Zxcer" <na...@zurahn.com>
To: <xa...@xml.apache.org>
Sent: Sunday, March 01, 2009 12:10 PM
Subject: Re: Usage model - no source XML, just api calls
>
> I looked through this and it does exactly what Tatu suggested, but it
> doesn't
> seem to address what I'm looking for, dynamically fetching data based on
> what is in the xsl stylesheet. This simply skips the generation and
> parsing
> of an XML source, instead emitting SAX elements directly, but still
> statically with respect to what a given stylesheet requires.
>
> Here's a scenario, a data set consisting of enormous amounts of financial
> transactions, tied to personal data. For both security and size reasons,
> the data cannot be exposed as a data source to be manipulated by xslt
> transformations. But a set of aggregator functions can be used to
> generate
> statistics, for instance "get the distribution of transactions relative to
> income over the past 3 months". This derived data set can then be
> further
> manipulated by xslt. But there is no way to predict what derived data a
> given style-sheet will request, so it needs to be fetched dynamically.
> DOM
> and SAX aren't designed to do this, but the XPath API *appears* to be - I
> just can't for the life of me figure out how to make it work as a source.
>
>
> Dave Brosius-2 wrote:
>>
>> as an example,
>>
>> http://sf.net/projects/beansource
>> http://beansource.sf.net
>>
>> shows how to pass a simple java bean as input to a Xslt transformation.
>>
>
> --
> View this message in context:
> http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22275164.html
> Sent from the Xalan - J - Users mailing list archive at Nabble.com.
>
Re: Usage model - no source XML, just api calls
Posted by Johan Zxcer <na...@zurahn.com>.
I looked through this and it does exactly what Tatu suggested, but it doesn't
seem to address what I'm looking for, dynamically fetching data based on
what is in the xsl stylesheet. This simply skips the generation and parsing
of an XML source, instead emitting SAX elements directly, but still
statically with respect to what a given stylesheet requires.
Here's a scenario, a data set consisting of enormous amounts of financial
transactions, tied to personal data. For both security and size reasons,
the data cannot be exposed as a data source to be manipulated by xslt
transformations. But a set of aggregator functions can be used to generate
statistics, for instance "get the distribution of transactions relative to
income over the past 3 months". This derived data set can then be further
manipulated by xslt. But there is no way to predict what derived data a
given style-sheet will request, so it needs to be fetched dynamically. DOM
and SAX aren't designed to do this, but the XPath API *appears* to be - I
just can't for the life of me figure out how to make it work as a source.
Dave Brosius-2 wrote:
>
> as an example,
>
> http://sf.net/projects/beansource
> http://beansource.sf.net
>
> shows how to pass a simple java bean as input to a Xslt transformation.
>
--
View this message in context: http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22275164.html
Sent from the Xalan - J - Users mailing list archive at Nabble.com.
Re: Usage model - no source XML, just api calls
Posted by Dave Brosius <db...@mebigfatguy.com>.
as an example,
http://sf.net/projects/beansource
http://beansource.sf.net
shows how to pass a simple java bean as input to a Xslt transformation.
----- Original Message -----
From: "Johan Zxcer" <na...@zurahn.com>
To: <xa...@xml.apache.org>
Sent: Sunday, March 01, 2009 1:02 AM
Subject: Re: Usage model - no source XML, just api calls
>
> Thanks for the response! I thought about that sort of approach, but
> wasn't
> sure it'd be much different from simply generating an xml, i.e. I'd still
> have to provide nodes for every conceivable permutation of data that might
> be requested. DOM, and especially SAX have no random-request interface
> whereby a requester (here, the style sheet) can ask for element X, and
> have
> it dynamically generated at that time. However it appears to me that this
> is exactly what XPath is designed to allow, I just can't seem to figure
> out
> how to use this mechanism to completely replace an actual source XML.
>
> johan
>
>
> Tatu Saloranta wrote:
>>
>>
>> As far as I know, most xslt processors expect input to be accessed as an
>> xml tree, dom (not necessarily "the" DOM, but something similar enough).
>> This is generally built using a streaming interface like SAX.
>> So perhaps you could just implement standard DOM API?
>>
>> Or alternatively, if it's easier, SAX interface using which processors
>> build internal trees.
>>
>> -+ Tatu +-
>>
>
> --
> View this message in context:
> http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22270237.html
> Sent from the Xalan - J - Users mailing list archive at Nabble.com.
>
Re: Usage model - no source XML, just api calls
Posted by Johan Zxcer <na...@zurahn.com>.
Thanks for the response! I thought about that sort of approach, but wasn't
sure it'd be much different from simply generating an xml, i.e. I'd still
have to provide nodes for every conceivable permutation of data that might
be requested. DOM, and especially SAX have no random-request interface
whereby a requester (here, the style sheet) can ask for element X, and have
it dynamically generated at that time. However it appears to me that this
is exactly what XPath is designed to allow, I just can't seem to figure out
how to use this mechanism to completely replace an actual source XML.
johan
Tatu Saloranta wrote:
>
>
> As far as I know, most xslt processors expect input to be accessed as an
> xml tree, dom (not necessarily "the" DOM, but something similar enough).
> This is generally built using a streaming interface like SAX.
> So perhaps you could just implement standard DOM API?
>
> Or alternatively, if it's easier, SAX interface using which processors
> build internal trees.
>
> -+ Tatu +-
>
--
View this message in context: http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22270237.html
Sent from the Xalan - J - Users mailing list archive at Nabble.com.
Re: Usage model - no source XML, just api calls
Posted by Tatu Saloranta <co...@yahoo.com>.
As far as I know, most xslt processors expect input to be accessed as an xml tree, dom (not necessarily "the" DOM, but something similar enough). This is generally built using a streaming interface like SAX.
So perhaps you could just implement standard DOM API?
Or alternatively, if it's easier, SAX interface using which processors build internal trees.
-+ Tatu +-
--- On Sat, 2/28/09, Johan Zxcer <na...@zurahn.com> wrote:
> From: Johan Zxcer <na...@zurahn.com>
> Subject: Usage model - no source XML, just api calls
> To: xalan-j-users@xml.apache.org
> Date: Saturday, February 28, 2009, 10:34 AM
> I am new to the world of XSL and Xalan, and I've been
> trying to understand
> whether my usage model is possible, common, or advisable.
> I simply want to
> use a stylesheet with no source document, instead using
> only calls into my
> API to fetch data. I've created an XPath instance to
> generate some results,
> but cannot figure out how to actually hook it to the
> transformer, so that it
> is used exclusively as the data source. None of the
> samples, nor anything
> I've found online seem to use XPath this way. What am
> I missing, and are
> there any examples on this sort of usage model I could use
> as a reference?
> Thanks in advance.
>
> johan
>
> PS. If it matters, the reason I'm trying to do this: I
> have a fairly
> complex data model (stored in a db, but no matter) that is
> not strictly
> hierarchical and could be accessed in many ways for
> different reasons. It
> would not be easy to generate a source XML that would
> contain all the
> possible iterations of data that may be needed by a
> particular style sheet.
> Nor is it feasible to provide all the raw data to be
> operated on by XSL
> operators and extension functions, due to both complexity
> and security of
> non-aggregated data. Finally, the stylesheet is intended
> to be created by
> external users of the system, so for security and
> simplicity a limited API
> that presents the data in specific calculated fashion is
> really required.
>
> --
> View this message in context:
> http://www.nabble.com/Usage-model---no-source-XML%2C-just-api-calls-tp22264025p22264025.html
> Sent from the Xalan - J - Users mailing list archive at
> Nabble.com.