Tom Bradford wrote:
> [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? :)
Well, it's not really me that saying it, but rather the XPath
recommendation. ;-)
> 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.
Yup, that's pretty much the way it is.
> 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?
I would imagine the editors of the XPath recommendation ought to be your
target. The recommendation states you can reach them at:
[EMAIL PROTECTED] <[EMAIL PROTECTED]>
Dave
