Schema Relationships in v6.8

Introduction

We extended Relationships in v6.8 so Data sites now support the following:

• Multiple relationships may be defined for two tables as long as they use different columns
• Relationships may be defined that reference the same table
• Relationships may be defined with child columns that are External Key values

This Developer Note is focused primarily on the intended consequence of both of the first two. These options now make the related XML content harder to identify in the XSL since they could produce similar "types" of content.

For Example:

Imagine a simple Data Site implementation intended to show Toys. The requirement is to show other "related" Toy records on the Detail page so we can cross-sell...

• show Toys that are intended for the same age group of kids
• show Toys made by the same Manufacturer 
• show Toys that develop the same skill-sets.

So when all these different toys come back, and we need to render them to the user, how do we know which ones are which? In the past, you could count on the fact that a "type" of content would be there only once. Now, we have lots of Toy records coming back for different reasons. We could even have the same records coming back for different reasons. 

Relationship Names

In previous versions, Relationship names were arbitrary. We now need them to support our ability to differentiate related content in our XSL code. Relationship names no longer support the use of special characters so we can safely use them in the return XML.

The database upgrade script for v6.8 includes a section to scrub relationship names so they follow the new requirements. For more information, see the related note on Character Scrubbing in T-SQL.

In our returned XML, you can now expect the following:

<Item>
	<DocID />
	<Version />
	<LinkParameter />
	<!-- other data fields for the main "Toy" -->
	<Classifications DocTotal="1" Rights="1">
		<!-- tag and lookup data for the main Toy -->
	</Classifications>
	
	<RelatedData>
		<Toy Rel="Similar Age">
			<DocID />
			<Version />
			<LinkParameter />
			<!-- other data fields for this "related Toy" -->
			<Classifications>
				<!-- tag and lookup data for this "related Toy" -->
			</Classifications>
		</Toy>
		<Toy Rel="Same Manufacturer">
			<DocID />
			<Version />
			<LinkParameter />
			<!-- other data fields for this "related Toy" -->
			<Classifications>
				<!-- tag and lookup data for this "related Toy" -->
			</Classifications>
		</Toy>
		<Toy Rel="Similar Age">
			<DocID />
			<Version />
			<LinkParameter />
			<!-- other data fields for this "related Toy" -->
			<Classifications>
				<!-- tag and lookup data for this "related Toy" -->
			</Classifications>
		</Toy>
	</RelatedData>
	
	<!-- other common elements -->
</Item>

Note that all related content is still together in the RelatedData element, but is easily identified by the attribute "Rel". This maintains backward compatibility for our existing Data Template XSL code and provides us a way to handle the new related content in a consistent way in XSL using an apply-templates (as we do within a "fieldprocessor" template):

<xsl:template match="RelatedPseudo_Toy_SimilarAge" mode="fieldProcessor">
	<xsl:param name="Node" />
	<xsl:param name="StyleNode" />
	<xsl:apply-templates select="$Node/RelatedData/Toy[@Rel='Similar Age']" mode="relatedWithFields">
		<xsl:with-param name="StyleNode" select="$StyleNode" />
		<xsl:with-param name="Fields" select="$Toy_SimilarAgeFields" />
	</xsl:apply-templates>
</xsl:template>