MSXML Perf Stats

["Steven Livingstone" <s.livingstone@xxxxxxxxxxxxxx>]

Can someone at microsoft point me to performance statistics on the *latest*
parser - preferably July.

I am looking for details based on the number of transforms per second (i
know there is no absolute value for this) w.r.t tree sizes etc...

thanks,
steven

-----Original Message-----
From: owner-xsl-list@xxxxxxxxxxxxxxxx
[mailto:owner-xsl-list@xxxxxxxxxxxxxxxx]On Behalf Of Andrew Kimball
Sent: 31 July 2000 20:37
To: 'xsl-list@xxxxxxxxxxxxxxxx'
Subject: RE: microsoft latest, bug with extension elements?


Mike,

The spec explicitly does not specify that the XSLT processor must construct
the tree.  Furthermore, the input tree may have gone through any number of
transformations before reaching the XSLT processor.  In the MSXML case, the
tree is actually constructed by the MS DOM implementation, in accordance
with XML 1.0 rules.  These rules state that in the absence of any in-scope
xml:space="preserve" elements, the whitespace processing rules are
application dependent.  Therefore, it is conformant for the DOM to strip
this whitespace on load and construction of the tree.  It is also valid to
allow users to transform the tree (including stripping any whitespace they
please) using the DOM API before sending it along to the XSL processor.

The XSL whitespace rules are only applied after the tree is constructed
(notice there is no mention of rules by which this tree must be constructed,
just so it conforms to the XPath data model).  If the user authorized
whitespace stripping implicitly (via a default DOM load), or explicitly (via
DOM API calls), then the "true" tree has gone through a simple
transformation *before* entering the XSLT processor.  Since this happens
before XSLT processing, the XSLT whitespace rules do not disallow this (and
nor should they).

~Andy Kimball
MSXSL Dev

-----Original Message-----
From: Mike Brown [mailto:mike@xxxxxxxx]
Sent: Monday, July 31, 2000 11:45 AM
To: xsl-list@xxxxxxxxxxxxxxxx
Subject: Re: microsoft latest, bug with extension elements?


Andrew Kimball wrote:
> When the document is passed to the XSL processor, the processor cannot
> determine what whitespace was originally present within the xsl:text
> element, so it outputs a single space by default.

If I am interpreting this correctly, then this is in violation of
http://www.w3.org/TR/xslt#strip, which says

"After the tree for a source document or stylesheet document has been
constructed, but before it is otherwise processed by XSLT, some text nodes
are stripped. A text node is never stripped unless it contains only
whitespace characters. Stripping the text node removes the text node from
the tree. The stripping process takes as input a set of element names for
which whitespace must be preserved.

 [...]

A text node is preserved if any of the following apply:

The element name of the parent of the text node is in the set of
whitespace-preserving element names.

 [...]

For stylesheets, the set of whitespace-preserving element names consists of
just xsl:text."

So text node children of xsl:text elements must not be stripped even if they
are nothing but whitespace characters.

-Mike


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


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


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