Re: Conflicting Node Values

Subject: Re: Conflicting Node Values
From: Jeni Tennison <Jeni.Tennison@xxxxxxxxxxxxxxxx>
Date: Thu, 25 May 2000 12:36:53 +0100
John,

>1) Why are XT and MSXML3 giving me different results?

To understand the results you're getting, you have to make two realisations.

The first realisation is that the nodes that make up an element's children
include text nodes, even if they're just whitespace (unless you tell the
processor that the text nodes aren't significant).

The second realisation is that position() gives the position of a node
within the current node list, which is *usually* the list of child nodes of
the node's parent node (i.e. the list of the child nodes of the SUBSYSTEM
element in your example).

That means that the tree of nodes within your document includes:

                         Node Type         position()
SUBSYSTEM                 element
+- (carriage return)       text                1
+- SUBSYSTEMNAME          element              2
+- (carriage return)       text                3
+- ALIAS                  element              4
   +- 'SEQUENCER'          text                
+- (carriage return)       text                5
+- ALIAS                  element              6
   +- 'WATCHER'            text                
...

This explains why XT gives the result it does: the first ALIAS node that is
a child of SUBSYSTEM is the 4th child of SUBSYSTEM, the second the 6th and
so on.

It also kind of explains why MSXML3 gives the result that it does: it looks
as if MSXML3 assumes that whitespace within the SUBSYSTEM element is
insignificant, and thus ignores it, but you still have a SUBSYSTEMNAME
element which is the first child of SUBSYSTEM; the first ALIAS node is the
2nd child of SUBSYSTEM under MSXML3 counting.

(I'm not certain which of XT and MSXML3 is correct, but I think that MSXML3
is wrong to make the assumption that whitespace is insignificant, unless
you have defined a document type.)

>2) Why is it that "ALIAS[n]" doesn't work at all?

My guess on this would be that you're using this xsl:if within the
ALIAS-matching template, i.e.:

<xsl:template match="ALIAS">
  <xsl:if test="./child::ALIAS[4]"><h5>ALIASES: </h5></xsl:if>
  ...
</xsl:template>

If you look at the test expression, it says "see if the current node has a
child element called ALIAS that is the fourth such child element called
ALIAS".  There are two problems with that:

1. the 'current node' is an ALIAS node - it won't have *any* child elements
called ALIAS
2. you want the first child element called ALIAS, not the fourth

The test that you want, if you want to do it like this, is: "see if the
current node is the first child element called ALIAS of its parent", which
you could express as:

<xsl:if test="current() = ../ALIAS[1]"><h5>ALIASES: </h5></xsl:if>

This is equivalent to "see if the current node does not have any preceding
siblings that are also called ALIAS".  In other words:

<xsl:if test="not(preceding-sibling::ALIAS)"><h5>ALIASES: </h5></xsl:if>

I don't know which gives better performance.

An alternative approach, which would enable you to use your original test,
would be to make sure that the current node list when the ALIAS-matching
template is called only holds the ALIAS children of the SUBSYSTEM element.
You can do this by applying templates to only those elements:

<xsl:template match="SUBSYSTEM">
  ...
  <xsl:apply-templates select="ALIAS" />
  ...
</xsl:template>

Finally, rather than adding the heading within the ALIAS-matching template
you could add it within the SUBSYSTEM-matching template:

<xsl:template match="SUBSYSTEM">
  ...
  <xsl:if test="ALIAS"><h5>ALIASES: </h5></xsl:if>
  <xsl:apply-templates select="ALIAS" />
  ...
</xsl:template>

<xsl:template match="ALIAS">
  <b><xsl:value-of select="."/></b>
</xsl:template>

I personally find that more appealing, but it's just a matter of taste.

Hope that helps,

Jeni

Dr Jeni Tennison
Epistemics Ltd, Strelley Hall, Nottingham, NG8 6PE
Telephone 0115 9061301 ? Fax 0115 9061304 ? Email
jeni.tennison@xxxxxxxxxxxxxxxx



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread