Hello 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.
