Re: [xml] contains() argument treated like XPath expression

[Daniel Veillard <veillard redhat com>]

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 
> node. T

   "&#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
     defined"

 i.e. exactly the same answer as in my previous mail.

Daniel

-- 
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/