[EMAIL PROTECTED] wrote:
> Entities are expanded by the XML parser before Xalan ever sees them. If
> you're using Xalan's XPath by passing strings into the XPath API, then that
> certainly won't work, since there will be no parser involved. I'm also
> don't understand what expression you're trying to evaluate. Why are you
> using two sets of quotes?
> title[text()='Gone Fishing']
> or:
> title[text()="Gone Fishing"]
> makes sense, but this:
> title[text()=""Gone Fishing""]
> does not.
So what you're saying is that nobody would ever want to search for an
element with a value of "Gone Fishing" that includes the surrounding
quotes? :)
Actually, you're right, the spec is based on post-normalized XML, so
unfortunately the W3C has made an oversight in their design. But let me
state more clearly what I'm talking about. In reference to embedded
quotes, XPath's only way of escaping embedded quotes is to use the
opposite enclosing character than the embedded one. This is especially
problematic when you're looking for a string with both characters in it
or when you're dynamically generating queries and would rather escape
the characters instead of programmatically determining which type of
enclosing quote to use.
So, according to the spec, literals like ["Gone Fishing"] and ['Gone
Fishing'] are ok, but when it comes to literals like ["Gone 'Fishing'"],
there's no way to properly represent them, short of using concatenation
functions. So there's clearly a limitation to easily declaring literal
strings. Who at the W3C should be shot for this?
--
Tom Bradford --- The dbXML Project --- http://www.dbxml.org/
We store your XML data a hell of a lot better than /dev/null
