Re: [xml] contains() argument treated like XPath expression
- From: Daniel Veillard <veillard redhat com>
- To: Larry Siden <lsiden-public comcast net>
- Cc: xml gnome org
- Subject: Re: [xml] contains() argument treated like XPath expression
- Date: Fri, 25 Jul 2003 10:12:10 -0400
On Thu, Jul 24, 2003 at 11:06:34PM -0400, Larry Siden wrote:
The function's definition makes it clear that /contains(string)/is about
finding one string within another.
Yes one XPath string within another XPath string.
Function: boolean contains(string, string)
Therefore, I do not understand your
last comment, which implies that there is some hidden requirement that
the implementation of /contains(string) / be coupled to XPath. XPath
Because that function is an XPath function ! It is defined in the
XPath spec, and defined only as such !
evaluates a special syntax of expressions that specify a search through
XML parse trees. What does that have to do with searching for a
substring within another string?
I still wonder if you read the definition.
If you don't pass a string input then the XPath spec ask you to
first cast to a string, that cast is also defined in the XPath rec.
And that function is implemented as part of the XPath module.
Either I don't understand what you're talking about or there is some
serious confusion on either side...
Regular expressions aren't of that much concern to me, right now. It's
they are simply out of scope for this function, that was my point.
of more concern to me that /contains(string)/ satisfy its primary
definition: to find an occurance of a substring within another string.
it does I think. If not provide a full bug report based on an
XSLT stylesheet and an XML file showing where this fails !
For example, my own goal was to be able to match all occurences of the
newline character ('\n') in a block of text. To accomplish that,
/contains(string)/ must be capable of recognizing "\n" (by convention)
you have to use the character reference corresponding to \n
There is NO WAY you can expect that XPath function to understand your
special semantic and stay compliant to the way it is defined. So I oppose
such a change.
as a line feed character in it's argument. By extension,
/contains(string) /should recognize all the other customary di-graphs
for non-printable characters, as well as character codes such as
"&#Xnnnn" for Unicode characters, any of which might be found in a text
"&#Xnnnn" is concerted to the equivalent unicode when XML is
parsed. XPath is not strictly defined outside of XSLt or XPointer
and both spec explains how to pass such characters to the XPath
layer (either by using the XML parser capabilitiesto convert character
references, or by using the URI %XX escaping conventions). The limitation
is not at the XPath level.
(It's probably a better idea, anyway, to define a different function for
that purpose, say,
That is actually plain wrong. Extensing a defined function part of
a standard to have custom support is what plagued this industry for years
and I completely oppose such a perverted approach.
I hope this is now clearer.
I'm still not 100% sure, but if I understand my answer is again:
"No do not extend standard function behaviour to make it
non conformant to its definition from the spec where it is
i.e. exactly the same answer as in my previous mail.
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
] [Thread Prev