[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
RE: Accessing XSL context - Was: RE: Question
Subject: RE: Accessing XSL context - Was: RE: Question From: "Vun Kannon, David" <dvunkannon@xxxxxxxx> Date: Fri, 5 Feb 1999 10:55:22 -0500 |
I agree that this is a problem, but I disagree with your characterisation of the problem as one of context bookkeeping. The root issue in my mind is the ability of the stylesheet to operate on hyperlinks that exist in the source document. (There might certainly be other kinds of context processing problems.) xsl:id and id() are fine for globally unique and direct links, but there are other kinds of links possible. On the pattern of xsl:id and id(), I have proposed xsl:href and follow(). There's not much syntax to an id, but for a generic pointer, the stylesheet needs to know the encoding of the fragment identifier. I prefer to use the syntax of XSL select attributes, primarily because the parser for that syntax is at hand in the style engine already. It might seem surprising that I've seen the need for specifying that an attribute of an element is a pointer, without ever specifying that the containing element is a link, simple or otherwise. I don't have a ready answer to that, except to say that knowing that an element is a link and of what kind, role etc. hasn't yet come up in my own work. I find it surprising that coordination with XLink and XPointer is not well addressed in the XSL WD, not even to the level of Namespaces (where at least an editor's note exists that recognises that source documents might use namespaces, and ponders what that might mean to the stylesheet). XLink is not referenced by the WD, and XPointer only to raise the possibility that stylesheets might contain XPointers, not have to operate on them. If there is an XML oversight committee, I feel that this lack of awareness in the WD is one of its oversights. In the style of your other solutions, then, my proposal would look like this: <CLASS> <METHOD name="foo">...</METHOD> <METHOD name="bar">...</METHOD> <METHOD name="baz">...</METHOD> <METHOD name="jaz">...</METHOD> <DESCRIPTION><METHODREF name="ancestor(CLASS)/METHOD[@name='foo']"/> is very fooey</DESCRIPTION> </CLASS> <xsl:template match="METHODREF"> <xsl:href attribute="name" syntax="XSLSelect"> <xsl:value-of select=".[follow(@name)]"> </xsl:template> Very obviously, my solution shifts knowledge of the target out of the stylesheet, back into the source. Because I'm approaching the problem as one of supporting hyperlinks, I think this is appropriate. From personal experience, I know that the XML source documents that I will be processing with XSL stylesheets will be link-rich, because links are the most appropriate way to express certain information. There is a need to style the link. For instance: <PACKAGE> <CLASS name="foo">...</CLASS> <CLASS name="bar"> <EXTENDS href="ancestor(PACKAGE)/CLASS[@name='foo']"/> </CLASS> </PACKAGE> When I style this document into SQL, the ability to create a view that contains all the columns of "foo" and "bar" together depends on following that link, and any other arbitrary EXTENDS link. The stylesheet can't know a priori where the links will go, so the specification of the pointer must exist completely in the source document, and the stylesheet can only "follow()" it. My team is currently extending XT to add this functionality. Cheers, David vun Kannon Manager, Financial Services Consulting KPMG LLP > -----Original Message----- > From: Mike Dierken [SMTP:mike@xxxxxxxxxxxxxxx] > Sent: Thursday, February 04, 1999 6:21 PM > To: xsl-list@xxxxxxxxxxxxxxxx > Subject: Accessing XSL context - Was: RE: Question > > Paul, > I agree that accessing several context is important. > The full approach I would like to suggest provides for a parameter to > context() which traverses up the 'xsl action' tree. So, context(0) would > be > equivalent to '.' > > So, do we have a general agreement that this is a real problem? > Currently, there are three approaches that seem to fit the requirements: > (if there are more suggestions, please let us know & provide example XSL) > (also, I am biased toward #3, so please add some pros & cons to these...) > > Mike D > > > ============================== > Problem: Accessing XSL context > <CLASS> > <METHOD name="foo">...</METHOD> > <METHOD name="bar">...</METHOD> > <METHOD name="baz">...</METHOD> > <METHOD name="jaz">...</METHOD> > <DESCRIPTION><METHODREF name="foo"/> is very fooey</DESCRIPTION> > </CLASS> > > "foo" is not a globally unique id. I know that it will be unique in the > CLASS however. What I need is to do something like this: > > <xsl:template match="METHODREF"> > <xsl:value-of select="ancestor(CLASS)/METHOD[@name=***]"> > </xsl:template> > > The problem is that at the point of the *** I've lost the context of the > METHODREF and don't have a way to get its @name anymore. > > > ============================== > Solution 1: 'constant()' method > PROS: > Access multiple contexts. > Uses existing concepts. > > CONS: > Requires multiple, similar declarations to access different contexts. > > EXAMPLE: > <xsl:template match="METHODREF"> > <xsl:constant name="where-am-i" value="{@name}"/> > <xsl:value-of > select="ancestor(CLASS)/METHOD[@name=constant(where-am-i)]"/> > </xsl:template> > > ============================== > Solution 2: macros and 'arg()' method > PROS: > Access multiple contexts. > Uses existing concepts. > > CONS: > The 'arg()' method isn't currently supported in query strings. > Requires multiple, similar declarations to access different contexts. > > EXAMPLE: > <xsl:macro name='helper'> > <xsl:macro-arg name='where-am-i'/> > <xsl:value-of select="ancestor(CLASS)/METHOD[@name=arg(where-am-i)]"/> > </xsl:macro-arg> > </xsl:macro> > > <xsl:template match="METHODREF"> > <xsl:invoke macro='helper'> > <xsl:arg name="where-am-i" value="{@name}"/> > </xsl:invoke> > </xsl:template> > > ============================== > Solution 3: 'context()' method > PROS: > Access multiple contexts. > Doesn't require declarations to access different contexts. > More declarative of what you want, rather than how to get it. > > CONS: > Introduces new concept. > > EXAMPLE: > <xsl:template match="METHODREF"> > <xsl:value-of select="ancestor(CLASS)/METHOD[@name=context(1)/@name]"/> > </xsl:template> > > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list ***************************************************************************** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email are subject to the terms and conditions expressed in the governing KPMG client engagement letter. ***************************************************************************** XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
XSL Parameters was: RE: Accessing X, Borden, Jonathan | Thread | Re: Accessing XSL context - Was: RE, Paul Prescod |
Formatting Objects and Page-breaks, Bovone Stefano | Date | XSL Parameters was: RE: Accessing X, Borden, Jonathan |
Month |