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

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

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


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]