Accessing values from another sub-tree

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

	I've been trying to achieve a particular result without success.
Since I'm unsure if the problem is my own thickheadedness, the
implementation of XSL I'm using (IE5b2), or the language itself, I turn to
this forum for advice.

	I've cooked up an XML encoding of UML by working as directly as
possible from the UML spec. A VB script inside Rational Rose lets me build
schemas such as:
<Schema name="SimpleBank">
<Class name="Customer">
	<Property name="FirstName" datatype="String"/>
	<Property name="LastName" datatype="String"/>
	<Property name="ID" datatype="Integer"/>
	<Key primary="true">
		<Part href="../Property/@name='ID'" />
	</Key>
</Class>

<Class name="Address">
	<Property name="Street" datatype="String"/>
	<Property name="City" datatype="String"/>
	<Property name="ZIP" datatype="String"/>
	<Property name="State" datatype="String"/>
	<Key primary="true">
		<Part href="../Property/@name='Zip'" />
		<Part href="../Property/@name='Street'" />
	</Key>
</Class>

<Association name="AccessibleAt">
	<AssociationEnd href="//Class/@name='Customer'" role="theCustomer"
cardinality="*"/>
	<AssociationEnd href="//Class/@name='Address'" role="theAddress"
cardinality="*"/>
</Association>
</Schema>

	Given this type of schema, I'm attempting to use an XSL stylesheet
to transform the schema into SQL DDL. The result I'm aiming for from the
above schema would be something like this:
Create Schema SimpleBank 
Create Table Customer (
	FirstName varchar,
	LastName varchar,
	ID integer,
	Primary Key ( ID )
);
Create Table Address (
	Street varchar,
	City varchar,
	ZIP varchar,
	State varchar,
	Primary Key ( Street, ZIP )
);
Create Table AccessibleAt (
	-- from theCustomer
	ID integer,
	-- from theAddress
	Street varchar,
	ZIP varchar
);

	The many-to-many association becomes a join table. The stylesheet
looks like:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl";>
  <xsl:template match="/">
	Create Schema <xsl:value-of select="//Schema/@name"/>
         <xsl:for-each select="//Class">
		Create Table <xsl:value-of select="@name"/> (
	         <xsl:for-each select="Property">
		<xsl:value-of select="@name"/>&#32;<xsl:value-of
select="@datatype"/>
		<xsl:if match="Property[$not$ end()]">,</xsl:if>
	          </xsl:for-each>
	         <xsl:for-each select="Key[@primary='true']">,
		Primary Key (
		         <xsl:for-each select="Part">
			<xsl:value-of select="follow(@href)/@name"/>
				<xsl:if match="Part[$not$ end()]">,
</xsl:if>
		          </xsl:for-each> )
	          </xsl:for-each>
		);
          </xsl:for-each>
        <xsl:for-each select="//Association">
		Create Table <xsl:value-of select="@name"/> (
	         <xsl:for-each select="AssociationEnd">
			-- From <xsl:value-of select="@role"/>
			<xsl:for-each
select="follow(@href)/Key[@primary='true']/Part">
				<xsl:value-of select="follow(@href)/@name"/>
				<xsl:if match="Part[$not$ end()]">,
</xsl:if>
			</xsl:for-each>
			<xsl:if match="AssociationEnd[$not$
end()]">,</xsl:if>
	          </xsl:for-each>
		);
          </xsl:for-each>
   </xsl:template>  
</xsl:stylesheet>

	Now, everything in the stylesheet is plain vanilla, except for that
follow() function in the selection patterns. Its sort of like the WD
function id() on steroids. The question I put before you is whether or not
the functionality of follow() can be accomplished within the spec or within
any implementation. If not, consider this a plea for such functionality in
the pattern language. Given the position of the XSL WG in its position paper
for QL '98, that the W3C should look in-house for technology for the generic
query language, it would be nice if XSL itself understood a little about
links and the "in-house W3C technology" of XLink and XPointer.
Cheers,
David vun Kannon
Manager, KPMG LLP
*****************************************************************************
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