RE: Accessing XSL context - Was: RE: Question

["Vun Kannon, David" <dvunkannon@xxxxxxxx>]

	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