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.
