There are XSLT processors written in languages other than Java, so you
can't assume JAXP is available. From the code snippet provided, I'm
guessing he's trying to implement the abstract base classes for Xalan-C's
source tree.
I believe the correct answer is that there is no reason to "interpret" any
elements in the source document in any special way, just because they
happen to be in the XSLT namespace. For example, transforming a
stylesheet, or a document with fragments of a stylesheet, or an embedded
stylesheet, would not work if you did.
If this is really a question about Xalan-C, one of Xalan's mailing lists
would probably be a better place to ask a question like this. See:
http://xml.apache.org/mail.html
Dave
"Michael Kay"
<michael(_dot_)h(_dot_)kay(_at_)ntlworld(_dot_)co
To: <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
m> cc:
<Michael(_dot_)Kay(_at_)softwareag(_dot_)com>, (bcc: David N
Bertoni/Cambridge/IBM)
Sent by: Subject: RE: RE: [xsl]
Expected behavior for parsed source containing xsl?
owner-xsl-list(_at_)lists(_dot_)mulbe
rrytech.com
10/09/2002 03:32 AM
Please respond to xsl-list
You seem to be re-inventing the JAXP 1.1 API. What are you doing that
JAXP doesn't do?
Michael Kay
Software AG
home: Michael(_dot_)H(_dot_)Kay(_at_)ntlworld(_dot_)com
work: Michael(_dot_)Kay(_at_)softwareag(_dot_)com
-----Original Message-----
From: owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
[mailto:owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com] On Behalf Of
John Mostrom
Sent: 08 October 2002 23:36
To: XSL-List(_at_)lists(_dot_)mulberrytech(_dot_)com
Cc: Michael(_dot_)Kay(_at_)softwareag(_dot_)com
Subject: Fwd: RE: [xsl] Expected behavior for parsed source
containing xsl?
Date: Tue, 8 Oct 2002 09:59:36 +0100
From: "Michael Kay" <michael(_dot_)h(_dot_)kay(_at_)ntlworld(_dot_)com>
Subject: RE: [xsl] Expected behavior for parsed source containing xsl?
We have been working on implementing parsed source in an
xslt engine
I'm sorry, I haven't the faintest idea what this means. Could
you explain more carefully what you are trying to do?
Michael Kay
Software AG
home: Michael(_dot_)H(_dot_)Kay(_at_)ntlworld(_dot_)com
work: Michael(_dot_)Kay(_at_)softwareag(_dot_)com
Michael,
I'm planning on providing an interface on an xsl transformation
engine for reusing an xml source by that engine. Here is a mockup of
the calls a user might make:
parsedSource ps = transformEngine.getParsedSource(
xmlInputStream ); ... transformEngine.transform( ps,
xslInputStream1, resultOutputStream1 ); ...
transformEngine.transform( ps, xslInputStream2,
resultOutputStream2 ); ... transformEngine.transform( ps,
xslInputStream2, resultOutputStream3 );
This is a pretty arbitrary example but what I'm trying to illustrate
is that a user of our tranformation engine may want to do the xml
parsing up front and then reuse that parsed source multiple times.
Thus my dilema: when the transform engine parses the orginal
xmlInputStream, should it process any xsl commands "contained" in the
xmlInputStream or not?
Thanks in advance for your feedback.
John
and have run into a question about what to do when parsing an xml
source that contains xsl instructions.
(By 'contains' I'm including both embedded xsl and PI referenced
xsl.)
Is it expected that the resulting parsed source tree
contains the xsl
as a subtree or should the resulting parsed source tree be the
transformed result of the contained xsl?
I can see arguments for both sides but I'm leaning toward
the tree
containing an xsl subtree at this point. Is there any
discussion or
documentation on this issue anywhere on the web?
Thanks,
John Mostrom
p.s. I'm subscribed to the digest so if you could cc: me on the
discussion, it would be great!
XSL-List info and archive:
http://www.mulberrytech.com/xsl/xsl-list
XSL-List info
and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list