Multi-target pattern issues

[David Kellum <dkellum@xxxxxxxx>]

According to the XSL spec. [3.1], multiple target-element siblings are
treated as "OR's".  For example:

(Example 1)

	<element type="A">
		<target-element type="B"/>
		<target-element type="C"/>
	</element>


This should match any instance of "B" with "A" as its parent as well as
any instance of "C" with "A" as its parent. Now, what about the
following:

(Example 2)

	<element type="A">
		<target-element type="B"/>
		<element type="C"/>
	</element>

>From my interpretation, this should match any instance of "B" that has
"A" as its parent and at least one "C" as a sibling.   I found no
examples of this in the spec. but it appears useful, in keeping with the
intent of the spec., and the only reasonable interpretation.  An
interesting point here is that the "target" modifier of C in the first
example, not only makes it a target but essentially hides it from being
a qualifier of A as far as B is concerned.  This might not be good,
considering that the specified conflict rules [3.2.6] count
target-elements and elements equally for any given rule.


Now, how about this:

(Example 3)

	<target-element type="A">
		<target-element type="B">
	</target-element>

Don't laugh!  There might actually be a good use for this.  The spec.
doesn't disqualify it except in the DTD and one could get around this by
wrapping the B target-element in an "any" tag (this is legal according
to the DTD).  I think this should be considered valid syntax (the DTD
can't validate for it anyway) with the interpretation that this pattern
matches on all A's that have a B child and all B's that have an "A"
child.  But here, unlike the first example, both target-elements
contribute an element to the other.


Perhaps, one could argue that allowing this complicates things more then
is useful. But here is a quite reasonable and DTD-valid case that is
also confusing:

(Example 4)

<element type="x">
	<element type="a">
		<target-element type="y"/>
	</element>
	<element type="b">
		<target-element type="z"/>
	</element>
</element>

The question here becomes, which of the following y's match:

1)
	<x>
		<a>
			<y/>
		</a>
	</x>

2)
	<x>
		<a>
			<y/>
		</a>
		<b/>
	</x>

3)
	<x>
		<a>
			<y/>
		</a>
		<b>
			<z/>
		</b>
	</x>

Here's my guess: 
1) No.
2) Maybe.
3) Yes.

If this truly is a flaw in the spec (as opposed to my misinterpretation)
then I suggest the following:

1. target-elements are always treated as if they were elements with
respect to other target-elements. In other words, the "target" part is
an additive property that doesn't effect the "element" aspect.

2. If the or-syntax of the first example is really necessary given the
fact that you can get the same behavior in two rules, then provide an
explicit "or-group" tag that explicitly identifies the behavior. So
example 1 becomes the following:

	
	<element type="A">
		<or-group>
			<target-element type="B"/>
			<target-element type="C"/>
		</or-group>
	</element>


This syntax, might actually be quite useful in some other situations.
For example, with or'ing different attribute criteria, etc.


-David Kellum
dkellum@xxxxxxxx


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