Hi Julian --
According to Joe Kesselman
(http://marc.theaimsgroup.com/?l=xalan-dev&m=97024906624126&w=2), the
W3C has ruled that all namespace names should be absolute. While RFC
2396 does allow the scheme to define the absolute and relative URI
syntax of the scheme-specific-part within that scheme, the "generic URI"
syntax begins with "//" so we did the same to further emphasize visually
that this is an absolute URI. At this stage, we're still kind of
experimenting with the xalan: scheme so nothing is set in stone.
As far as registering xalan:, we're still experimenting with this and
awaiting XSLT 2.0 so I think that might be premature.
Anyway, that was my thinking and if you have suggestions, please feel
free.
To eliminate the execution of extension functions in your application,
please bear in mind that xalan:// syntax, while recommended, is not
currently enforced and extension functions can be called even with a
relative URI syntax (ie without the scheme).
All extension function calls go through
org.apache.xalan.extensions.ExtensionsTable.extFunction(...). This is a
public method. You could subclass ExtensionsTable and override this
method to prohibit extension function calls while in your code. Then,
call org.apache.xpath.XPathContext.setExtensionsTable(..) to substitute
your ExtensionsTable subclass for the actual ExtensionsTable class.
You can get the current XPathContext from the current TransformerImpl by
calling the getXPathContext() method of that TransformerImpl. So, you
might try something like:
myTransformer.getXPathContext().setExtensionsTable(myExtensionsTable);
before you start your transform. Obviously, if you're not using the
Transformer but creating your own XPathContext, you already have access
to it!
If you decide to take this path, I just noticed that the
setExtensionsTable() method seems to have default (package) access
instead of public. Why not try to change this to public and see if this
method works for you, if it is appropriate. If so, please submit a
bugzilla item and I will change the access on the setExtensionsTable()
method to public.
Thanks and HTH,
Gary
Julian Reschke wrote:
>
> Basically the client can submit an XPath expression as part of an XML based
> query syntax. As the document that's queried can use "arbitrary" namespaces,
> the client needs to be able to bind prefixes to namespaces, for instance
>
> <query xmlns:foo="bar">
> <select>...</select>
> <where match="foo:property=12345" />
> </query>
>
> The server uses all namespace declarations in scope of the "where" element
> to bind the prefixes for XPath.
>
> However, this allows the caller to basically invoke "any" Java method by
> using Xalan's hardwired URIs for Java extensions (such as "xalan://...").
> Obviously I don't want the caller to be able to do that.
>
> By the way, quoting from <http://xml.apache.org/xalan-j/extensions.html>:
>
> "Although the namespace declarations for the class and package formats are
> shown with the xalan:// prefix, the current implementation for those formats
> will simply use the string to the right of the rightmost forward slash as
> the Java class name. This format is shown in order to comply with W3C
> recommendations for namespace declarations."
>
> This statement is completely misleading. The XML namespace spec says that
> the namespace name should be a URI ref. If you choose to "invent" a URI
> scheme as "xalan:", you have complete control of scheme-specific-part, there
> is no explicit requirement for the leading "//". Besides, if "xalan:" is
> going to be supported in the future (instead of the XSLT 1.1 draft method),
> at least the URI scheme should be officially registered...
>
> > -----Original Message-----
> > From: Gary L Peskin [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, May 27, 2001 4:13 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: javax.xml.transform: prohibiting Java extensions
> >
> >
> > Julian --
> >
> > Can you post an example of what you're talking about?
> >
> > Gary
> >
> > Julian Reschke wrote:
> > >
> > > Hi,
> > >
> > > I am considering to use XPath as a query language within a WebDAV DASL
> > > grammar. This means client software can submit a query where
> > the condition
> > > is expressed as XPath expression applied to the WebDAV properties of the
> > > resource(s).
> > >
> > > As WebDAV properties can be in "any" namespace, I need to allow
> > binding of
> > > namespace names to prefixes, so that the prefixes can be used
> > in the XPath
> > > expression.
> > >
> > > However, most Java-based XSLT engines allow to create Java
> > objects (and call
> > > their methods) by specifying a special namespace, which currently is
> > > proprietary. This means that blindly executing the query after
> > binding the
> > > namespace prefixes, a client can get access to all objects in
> > the system.
> > >
> > > Obviously, one needs a way to prohibit execution of extension
> > functions...
> > > Is there a portable way to to it? If not, how could I achieve this with
> > > Xalan?
> > >
> > > Julian
> >
