Hi Simon,
Sorry for the long delay in following up on this. I agree that the
fact that Xalan-J is trying to assume responsibility for the meaning of
the fragment is probably a bug. I think you should open a bug in Bugzilla
for this.
I was just wondering whether plugging in a class that implements the
javax.xml.transform.URIResolver interface and returns a SAXSource object
might be a way of working around the problem.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro Xalan development
IBM SWS Toronto Lab Tie Line 969-6044; Phone (905) 413-6044
mailto:[EMAIL PROTECTED]
Simon Del Fabbro <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
02/06/2003 11:47 AM
Please respond to xalan-dev
To: [EMAIL PROTECTED]
cc:
Subject: Re: Xalan Java2: XPath fragment with href in include element
Hello Henry,
Thanks for the reply.
Yes, I am trying to index an element which is child to "some-tag" using
the
notation in accordance to http://www.w3.org/TR/xptr-xpointer/. My
collegue
who implemented the URL handler misinterpreted the specification or it
got
confused(!) with [1] and [2]. You are correct in that the URI should
look
something like:
cqr:////<some name to the content which contains the
XSL>#xpointer(some-tag/* %5B
namespace-uri()='http://www.w3.org/1999/XSL/Transform' and
local-name()='stylesheet' %5D)"
Our protocol handler takes (should take) this URI and handle the XPath
stuff
and return the correct element as required by the XPath. So if we had
the document
<some-tag>
<xsl:stylesheet>
...
</xsl:stylesheet>
</some-tag>
then the above URI should result in a stream containing
<xsl:stylesheet>
....
</xsl:stylesheet>
Although the current version of Xalan-J doesn't support this type of
addressing,
the check for the hash in the method pushBaseIndentifier in
org.apache.xalan.processor.StyleSheetHandler stops any further
processing
with *any* URI which contains a hash. For example, consider the
following stylesheets:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
<xsl:include href="file:///tmp/library.xsl#here"/>
<xsl:template match="/">
<message><xsl:call-template name="sayHelloWorld"/></message>
</xsl:template>
</xsl:stylesheet>
where /tmp/library.xsl is
<doc xmlns:xsl="http://www.w3.org/1999/XSL/Transform";><xsl:stylesheet
id="here" version="1.0">
<xsl:template name="sayHelloWorld">Hello World</xsl:template>
</xsl:stylesheet>
</doc>
Nothing is produced and also when /tmp/library.xsl is
<xsl:stylesheet id="here" version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
<xsl:template name="sayHelloWorld">Hello World</xsl:template>
</xsl:stylesheet>
It should produce:
<?xml version="1.0" encoding="UTF-8"?>
<message>Hello World</message>
Is this correct?
I am using Xalan Java 2.4.1
Regards,
Simon.
> If I understand that code correctly, the URI fragment is being
handled
> in accordance with the interpretation of the XPointer Framework Proposed
> Recommendation - sections 3 [1] and 3.2 [2] of that document - or with
some
> predecessor version of that document. Paraphrasing XPointer, the
fragment
> would be interpreted as referring to the first element in document order
> with an attribute or child whose schema-type is type ID or with an
> attribute whose DTD type is ID, where the normalized value or schema
> normalized value of said attribute or child is the same as the fragment
> identifier.
>
> To use a more concrete example, the URI <file:///abc.xsl#HERE>
would
> refer to the xsl:stylesheet fragment in the following document named
> abc.xsl:
>
> <!DOCTYPE doc [
> <!ELEMENT doc ANY>
> <!ATTLIST doc xmlns:xsl CDATA #IMPLIED
> xmlns:blah CDATA #IMPLIED>
> <!ELEMENT xsl:stylesheet ANY>
> <!ATTLIST xsl:stylesheet id ID #IMPLIED
> version CDATA #IMPLIED>
> ]>
> <doc xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
> <xsl:stylesheet id="HERE" version="1.0">
> ...
> </xsl:stylesheet>
> </doc>
>
> In order to index a set of nodes that are "beneath" a some-tag
> element, the way you are trying to, I think you'd have to use the
"XPointer
> scheme" [3] in the XPointer Framework in something like the following
> fashion. (I'm not clear on the semantics, so this might just select the
> element and not its children.)
>
> <xsl:include href="cqr:////<some name to the content which contains the
> XSL>#xpointer(some-tag/* %5B
> namespace-uri()='http://www.w3.org/1999/XSL/Transform' and
> local-name()='stylesheet' %5D)"/>
>
> However, Xalan-J Interpretive appears only to support the limited case
I've
> described above, in which an ID value appears after the number sign. I
> think it would probably be a good thing for Xalan-J to support the more
> general forms of addressing described by those proposed recommendations
-
> perhaps via support in an XML parser, like Xerces-J.
>
> I'm not sure I understand the examples you describe under
"Additional
> points to consider". Could I ask you to provide real examples to
> illustrate the points?
>
> Thanks,
>
> Henry
> [1] http://www.w3.org/TR/xptr-framework/#language
> [2] http://www.w3.org/TR/xptr-framework/#shorthand
> [3] http://www.w3.org/TR/xptr-xpointer/
> ------------------------------------------------------------------
> Henry Zongaro Xalan development
> IBM SWS Toronto Lab Tie Line 969-6044; Phone (905) 413-6044
> mailto:[EMAIL PROTECTED]
>
>
> Simon Del Fabbro
> <simon.delfab@cqr To:
[EMAIL PROTECTED]
> data.com> cc:
> Sent by: Subject: Re: Xalan
Java2: XPath fragment with href in include element
> simon.delfab@cqrd
> ata.com
>
>
> 02/05/2003 11:46
> AM
> Please respond to
> xalan-dev
>
>
>
> Hi,
>
> I have encountered a problem when trying to include a stylesheet which
> has an XPath fragment in a URI.
>
> I am working on a document management system and we have our own
> namespace,
> URL and URL handler. A stylesheet is wrapped up in some element as
> follows
>
> <some-tag>
> <xsl:stylesheet>
> ...
> </xsl:stylesheet>
> </some-tag>
>
> To import the stylesheet I would write:
>
> <xsl:include href="cqr:////<some name to the content which contains the
> XSL>#some-tag/* %5B
> namespace-uri()='http://www.w3.org/1999/XSL/Transform' and
> local-name()='stylesheet' %5D"/>
>
> where %5B and %5D are [ and ] respectively.
>
> This doesn't work. The templates defined in the imported template aren't
> imported. Looking
> at the Xalan code I noticed that the following method defined
> org.apache.xalan.processor.StyleSheetHandler
> sets the variable m_shouldProcess to false because my base identifier
> has a # in it and therefore
> the stylesheet doesn't get imported.
>
> void pushBaseIndentifier(String baseID)
> {
> if (null != baseID)
> {
> int posOfHash = baseID.indexOf('#');
>
> if (posOfHash > -1)
> {
> m_fragmentIDString = baseID.substring(posOfHash + 1);
> m_shouldProcess = false;
> }
> else {
> m_shouldProcess = true;
> }
> }
> else
> m_shouldProcess = true;
>
> m_baseIdentifiers.push(baseID);
> }
>
> So here's my question: what is this method doing? i.e. what sort of base
> identifiers is this check
> looking for?
>
> Also, pushBaseIndentifier is misspelt.
>
> Additional points to consider:
> URL handler with XPath works OK. Grabs the right blob of XML elements
> i.e. a stream containing an XML document which is
> a stylesheet.
> Here's weird one. The included stylesheet contained a template which the
> importing stylesheet called. This template wasn't
> obviously being called (trace writes verified this), but no error was
> raised. That is, no-template-with-name-was-found type
> error was raised. Removing this include statement or placing it at the
> end of the stylesheet and it complained that it couldn't
> find the template.
>
> S.
