Re: Multi-target pattern issues

[Paul Grosso <paul@xxxxxxxxxxxxx>]

At 23:57 1998 05 04 -0400, David Kellum wrote:
>According to the XSL spec. [3.1], multiple target-element siblings are
>treated as "OR's".  For example:

It's not exactly "multiple target-element siblings"; rather, the
submission allowed for multiple patterns in a single construction
rule.  And, yes, multiple patterns are or-ed (just as if they were
really individual rules which all have the same right hand side).

If you reconsider your thoughts in light of multiple patterns where
each pattern has to follow those shown in the submission, you'll
probably realize that many of your examples are not allowed.  However,
the XSL WG plans to have a draft ready for July that will have a
different syntax for patterns. 

>
>(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
>
>


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