RE: How do you get the non-transformed character entit

In that case, this is a bug in MSXML3.  It doesn't seem to return anything
if you use the browser to view it through XSLT, but if you do the following:

  doc:=CoDomDocument.Create;
  doc.load('tester.xml');
  node:=doc.selectSingleNode('/test/@attr/text()');
  edit1.text:=node.xml;

it returns '<'.
As an aside, what is the reasoning behind attributes not having a single
text node child?

As stated in section 5.7 of the XPath 1.0 spec, "Characters inside comments,
processing instructions and attribute values do not produce text nodes."

It seems to me that XPath is lacking in this case.  Of those three, comments
are the only ones that end up only having text within them.  Attributes have
an expanded name and text, and processing instructions have a 'string value'
as defined by the spec, but also have what appear to be attributes (though
they aren't defined as such).
I'm sure this wasn't just done randomly, but I fail to see the logic in
this.  Why is XPath limited by its data model, etc. to not be able to select
just the text portion of these nodes?  Can someone please clue me in?
Thanks.

-Nate
naustin@idsgrp

P.S. Sorry for the misinformation.  One would have thought I'd have picked
that up in the last thousand or so digests and year and a half of XSLT work.
I guess it's time to re-read the specs and Mike's book.

> Date: Tue, 18 Sep 2001 21:42:04 +0100
> From: "Michael Kay" <mhkay@xxxxxxxxxxxx>
> Subject: RE:  How do you get the non-transformed 
> character entity out of MSXML3.0
> 
> > If you modify your XPath statement to be
> > /somenode/@someattribute/text()
> 
> That means /child::somenode/attribute:someattribute/child::text().
> 
> An attribute never has children, so this will always return an empty
> node-set.
> 
> Mike Kay
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

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