RE: select v. select-elements

[Jonathan Marsh <jmarsh@xxxxxxxxxxxxx>]

Ah! I think I see a couple of potential sources for confusion.
1)	The contents of <select-elements> is a single pattern, thus it can
have only a single <target-element>.
2)	Hierarchy may also be included as in the following example.  But
<select-elements> looks for <target-elements>s that are immediate children
of the current node, in general from="descendants" must be used to search
deeper down in the tree.

<select-elements from="descendants">
  <element type="chapter">
    <target-element type="title"/>
  </element>
</select-elements>

If from="children" (the default) is used, then this action would only return
results when inside a rule for "chapter", which makes <element/> redundant.

This is at least the way we understood the Proposal and implemented MSXSL.

Jonathan Marsh
phone   425.703.4591
 <mailto:jmarsh@xxxxxxxxxxxxx> jmarsh@xxxxxxxxxxxxx



		-----Original Message-----
		From:	Martin Bryan [mailto:mtbryan@xxxxxxxxxxxxxx]
		Sent:	Saturday, March 07, 1998 1:00 AM
		To:	xsl-list@xxxxxxxxxxxxxxxx
		Subject:	Re: select v. select-elements




		>Has any-one had any luck using either of the  above
elements in the MSXSL
		>processor? Select-elements seems to produce no result at
all( I cant even
		>generate an HTM file), inspite of the MS tutorial
championing it, and
		select
		>just produces an empty drop down box. ( the select seems to
be passed on to
		>the HTML code unprocessed)

		<select-elements> does work, providing you only put a single
		<target-element> in each select-elements, e.g.
		     <select-elements>
		      <target-element type="Message-Date"/>
		     </select-elements>
		     <select-elements>
		      <target-element type="Buyer-EAN"/>
		     </select-elements>
		     <select-elements>
		      <target-element type="Order-No"/>
		     </select-elements>



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


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