Re: Xalan and file path of xsl?

[Hans Gill <ha...@rhinosystemsinc.com>]

you need to put it in as a uri. Try the following

file:///c:/tomcat/webapps/SupportCentral

This worked for me.

Eric Advincula wrote:

> I put my xsl file in the following path:
>
> c:\tomcat\webapps\SupportCentral
>
> so I have a string that returns this:
>
> _strPath = "c:\\tomcat\\webapps\\SupportCentral\\Admin.xsl";
>
> also
>
> _strPath = "c://tomcat//webapps//SupportCentral//Admin.xsl";
>
> by xalan cant seem to find it.
>
> But it does find it in c:\Tomcat\bin by default without having set the path.
> I just add the "Admin.xsl" without the path.
>
> Any ideas what I need to do so xalan finds the file in the directory where I
> want it to find it?
>
> Thanks
> ----- Original Message -----
> From: <Sc...@lotus.com>
> To: <xa...@xml.apache.org>
> Sent: Tuesday, August 01, 2000 12:12 PM
> Subject: Re: XSLT without DOM tree
>
> >
> > > If you use a DTM, you certainly don't want to use NodeIterator!
> >
> > Well, if java didn't suck, this wouldn't be such a problem.  In C# or C++,
> > for instance, you could define a struct that represents the DTM slot,
> > without allocating a DTMProxy, like the DTM currrently has to do.
> >
> > > A better alternative is to make nextNode and previousNode return boolean
> > > instead of Node, and add node access operations to NodeIterator.  For
> > example
> > > NodeIterator could have a getNodeNode() method that returns the name of
> > > the current node.
> >
> > Yeah, I thought about this.  I don't think this will work, because, once a
> > node is retrieved, it has to be used in multiple statements, while the
> > state of the iterator changes.
> >
> > > An alternative idea is to replace a node object by a pair: a Document
> > > object plus an int index.
> >
> > Yep.  Again, this wouldn't be a problem accessing this via a DOM interface
> > if Java would let you.
> >
> > > http://www.bothner.com/~per/doc-nodes/
> >
> > Cool.  What is the context for this?
> >
> > -scott
> >
> >
> >
> >
> >
> >                     Per Bothner
> >                     <per@bothner.        To:     xalan-dev@xml.apache.org
> >                     com>                 cc:     (bcc: Scott
> Boag/CAM/Lotus)
> >                     Sent by:             Subject:     Re: XSLT without DOM
> tree
> >                     bothner@bothn
> >                     er.com
> >
> >
> >                     08/01/2000
> >                     02:50 PM
> >                     Please
> >                     respond to
> >                     xalan-dev
> >
> >
> >
> >
> >
> > "Scott Boag/CAM/Lotus" <Sc...@lotus.com> writes:
> >
> > > > So if you don't have an
> > > > actual DOM, you have to allocate a new Node instance for each
> > > > nextNode result, which kills efficiency.
> > >
> > > True indeed.  But if the objects are cheap to build, and can be garbage
> > > collected, this doesn't necessarily kill efficiency.
> >
> > Well, object allocation/de-allocation tends to be one of more expensive
> > operations, so efficiency argues strongly for minimzing object creation.
> >
> > > > This makes NodeIterator useless as a standard API for efficient
> > > > tree traversal, except in applications which build a complete DOM.
> > >
> > > I'm not sure it is useless.  It's hard to see how to build any sort of
> > > XPath/XSLT processor without some concept of a node object.
> >
> > First, I said *except* in applications which build a complete DOM.
> > The context of the discussion was avoiding a (classic) DOM.  If you
> > have a full DOM, then NodeIterator is quite reasonable.
> >
> > But there are many xml applications that don't need a DOM, including
> > many where a SAX-like approach would work.  Admittedly, most of those
> > wouldn't need a bi-directional NodeIterator either.
> >
> > However, consider alterative data representations.  I thought the whole
> > point of the Document Table Model was to avoid allocating an object for
> > each node.  If you use a DTM, you certainly don't want to use
> NodeIterator!
> >
> > A better alternative is to make nextNode and previousNode return boolean
> > instead of Node, and add node access operations to NodeIterator.  For
> > example
> > NodeIterator could have a getNodeNode() method that returns the name of
> > the current node.
> >
> > An alternative idea is to replace a node object by a pair: a Document
> > object plus an int index.  I explore this and related ideas in
> >         http://www.bothner.com/~per/doc-nodes/
> > (While there is some working code, it isn't releasable yet.)
> > --
> >            --Per Bothner
> > per@bothner.com   http://www.bothner.com/~per/
> >
> >
> >
> >
> >