From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/94725 Path: news.gmane.org!not-for-mail From: "Meer, Hans van der" Newsgroups: gmane.comp.tex.context Subject: Re: xml expression error Date: Thu, 12 May 2016 11:49:29 +0000 Message-ID: <6BA7C71B-3A5F-4F0E-8968-FBF42ED9F18A@uva.nl> References: <52F14AAC-EE1A-4A01-AC8D-2B1900EA1BED@ziggo.nl> <6fdc9bcd-6249-1d6d-ba10-8bc994b39ab8@gmx.es> Reply-To: mailing list for ConTeXt users NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6428177506198996194==" X-Trace: ger.gmane.org 1463053822 7397 80.91.229.3 (12 May 2016 11:50:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 May 2016 11:50:22 +0000 (UTC) To: NTG ConTeXt Original-X-From: ntg-context-bounces@ntg.nl Thu May 12 13:50:10 2016 Return-path: Envelope-to: gctc-ntg-context-518@m.gmane.org Original-Received: from zapf.boekplan.nl ([5.39.185.232] helo=zapf.ntg.nl) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b0p86-00049H-1A for gctc-ntg-context-518@m.gmane.org; Thu, 12 May 2016 13:50:10 +0200 Original-Received: from localhost (localhost [127.0.0.1]) by zapf.ntg.nl (Postfix) with ESMTP id 61D7DC774; Thu, 12 May 2016 13:49:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at zapf.boekplan.nl Original-Received: from zapf.ntg.nl ([127.0.0.1]) by localhost (zapf.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujRA1ZDX0s9P; Thu, 12 May 2016 13:49:42 +0200 (CEST) Original-Received: from zapf.ntg.nl (localhost [IPv6:::1]) by zapf.ntg.nl (Postfix) with ESMTP id 8AD6EC775; Thu, 12 May 2016 13:49:42 +0200 (CEST) Original-Received: from localhost (localhost [127.0.0.1]) by zapf.ntg.nl (Postfix) with ESMTP id E764DC772 for ; Thu, 12 May 2016 13:49:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at zapf.boekplan.nl Original-Received: from zapf.ntg.nl ([127.0.0.1]) by localhost (zapf.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GYBeS81o34M for ; Thu, 12 May 2016 13:49:40 +0200 (CEST) Original-Received: from HUB01.uva.nl (hub01.uva.nl [146.50.108.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by zapf.ntg.nl (Postfix) with ESMTPS id 727C2C73A for ; Thu, 12 May 2016 13:49:30 +0200 (CEST) Original-Received: from MBX02.uva.nl ([169.254.2.29]) by HUB01.uva.nl ([2002:9232:6737::9232:6737]) with mapi id 14.03.0279.002; Thu, 12 May 2016 13:49:30 +0200 Thread-Topic: [NTG-context] xml expression error Thread-Index: AQHRoWALYwbpBQQAK0OFHN0Y0l61+p+fsIkAgAEam4CAFFlDgA== In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [84.106.134.200] x-endpointsecurity-0xde81-ev: v:6.2.7.719, d:out, a:y, w:t, t:0, sv:1463043695, ts:1463053770 X-BeenThere: ntg-context@ntg.nl X-Mailman-Version: 2.1.16 Precedence: list List-Id: mailing list for ConTeXt users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ntg-context-bounces@ntg.nl Original-Sender: "ntg-context" Xref: news.gmane.org gmane.comp.tex.context:94725 Archived-At: --===============6428177506198996194== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_6BA7C71B3A5F4F0E8968FBF42ED9F18Auvanl_" --_000_6BA7C71B3A5F4F0E8968FBF42ED9F18Auvanl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think I have the problem nailed down to the fact that in the comparison: something >=3D -1234 the parser in question separates the minus in the negative number into a se= parate child node, apart from the digits; witness the errormessage in the l= og below. Changing the number -1234 in the arithmetic expression to number("-1234") = (mind the quotes) does give a correctly evaluated expression. Still, I am baffled by the fact that in arithmetic expressions positive and= negative numbers are treated differently in the filtering operation. Hans van der Meer On 29 Apr 2016, at 15:04, Meer, Hans van der > wrote: Here is a minimal example showing that even a number as -1 is not correctly= handled by the lpath[selection]-code. I really am convinced that not handling negative numbers should qualify as = a mistake. Hans van der Meer % failure of negative number comparison. \startxmlsetups demo:numberfail \xmlsetsetup{#1}{root|node}{demo:numberfail:*} \stopxmlsetups \xmlregisterdocumentsetup{demo}{demo:numberfail} \startxmlsetups demo:numberfail:root @atta >=3D 1:\crlf \xmlfilter{#1}{/[number(@atta) >=3D 1]/command(demo:numberfail:node)} \blank @atta >=3D -1:\crlf \xmlfilter{#1}{/[number(@atta) >=3D -1]/command(demo:numberfail:node)} \xmlfilter{#1}{/[number(@atta) >=3D number(-1)]/command(demo:numberfail:nod= e)} \stopxmlsetups \startxmlsetups demo:numberfail:node node: attribute atta =3D \xmlatt{#1}{atta}\crlf \stopxmlsetups \startbuffer[numberfail] \stopbuffer \starttext \xmlprocessbuffer{demo}{numberfail}{} the error from \type{\xmlfilter{#1}{/[number(@atta) >=3D -1]/command(demo:n= umberfail:node)}}: \starttyping xml > lpath > error in expression: number(@atta) >=3D -1 =3D> expr.number((= ll.at and ll.at['atta'])) >=3D expr.child(ll,= '-')1 \stoptyping the error from \type{\xmlfilter{#1}{/[number(@atta) >=3D number(-1)]/comman= d(demo:numberfail:node)}}: \starttyping xml > lpath > error in expression: number(@atta) >=3D number(-1) =3D> expr.= number((ll.at and ll.at['atta'])) >=3D expr.n= umber(expr.child(ll,'-')1) \stoptyping \stoptext ___________________________________________________________________________= ________ --_000_6BA7C71B3A5F4F0E8968FBF42ED9F18Auvanl_ Content-Type: text/html; charset="us-ascii" Content-ID: <6538034BA058EC4997B352D2E8F8FEB1@uva.nl> Content-Transfer-Encoding: quoted-printable I think I have the problem nailed down to the fact that in the comparison:
something >=3D -1234
the parser in question separates the minus in the negative = number into a separate child node, apart from the digits; witness the error= message in the log below.
Changing the number  -1234 in the arithmetic expression to number("-1234") (mind the quotes) does give a corre= ctly evaluated expression.

Still, I am baffled by the fact that in arithmetic expressi= ons positive and negative numbers are treated differently in the filtering = operation.

Hans van der Meer


On 29 Apr 2016, at 15:04, Meer, Hans van der <H.vanderMeer@uva.nl> wrote:<= /div>

Here is a minimal example sh= owing that even a number as -1 is not correctly handled by the lpath[select= ion]-code.
I really am convinced that not handling negative numbers sh= ould qualify as a mistake.

Hans van der Meer


% failure of negative num= ber comparison.
\startxmlsetups demo:numb= erfail
\xmlsetsetup{#1}{root|node}{demo:n= umberfail:*}
\stopxmlsetups
\xmlregisterdocumentsetup= {demo}{demo:numberfail}
\startxmlsetups demo:numb= erfail:root
@atta >=3D 1:\crlf
\xmlfilter{#1}{/[number(@atta) >= ;=3D 1]/command(demo:numberfail:node)}
\blank
@atta >=3D -1:\crlf
\xmlfilter{#1}{/[number(@atta) >= ;=3D -1]/command(demo:numberfail:node)}
\xmlfilter{#1}{/[number(@atta) >= ;=3D number(-1)]/command(demo:numberfail:node)}
\stopxmlsetups
\startxmlsetups demo:numb= erfail:node
node: attribute atta =3D \xmlatt{#= 1}{atta}\crlf
\stopxmlsetups
\startbuffer[numberfail]<= /font>
<root>
<node atta=3D"2&q= uot;/>
<node atta=3D"3&q= uot;/>
</root>
\stopbuffer
\starttext
\xmlprocessbuffer{demo}{n= umberfail}{}
the error from \type{\xml= filter{#1}{/[number(@atta) >=3D -1]/command(demo:numberfail:node)}}:
\starttyping
xml > lpath > error= in expression: number(@atta) >=3D -1 =3D> expr.number((ll.at and ll.at['atta'])) >=3D expr.child= (ll,'-')1
\stoptyping

the error from \type{\xml= filter{#1}{/[number(@atta) >=3D number(-1)]/command(demo:numberfail:node= )}}:
\starttyping
xml > lpath > error= in expression: number(@atta) >=3D number(-1) =3D> expr.number((ll.at and ll.at['atta'])) >=3D expr.numbe= r(expr.child(ll,'-')1)
\stoptyping
\stoptext

___________________________________________________________= ________________________

--_000_6BA7C71B3A5F4F0E8968FBF42ED9F18Auvanl_-- --===============6428177506198996194== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KSWYgeW91ciBxdWVzdGlvbiBpcyBvZiBpbnRlcmVz dCB0byBvdGhlcnMgYXMgd2VsbCwgcGxlYXNlIGFkZCBhbiBlbnRyeSB0byB0aGUgV2lraSEKCm1h aWxsaXN0IDogbnRnLWNvbnRleHRAbnRnLm5sIC8gaHR0cDovL3d3dy5udGcubmwvbWFpbG1hbi9s aXN0aW5mby9udGctY29udGV4dAp3ZWJwYWdlICA6IGh0dHA6Ly93d3cucHJhZ21hLWFkZS5ubCAv IGh0dHA6Ly90ZXguYWFuaGV0Lm5ldAphcmNoaXZlICA6IGh0dHA6Ly9mb3VuZHJ5LnN1cGVsZWMu ZnIvcHJvamVjdHMvY29udGV4dHJldi8Kd2lraSAgICAgOiBodHRwOi8vY29udGV4dGdhcmRlbi5u ZXQKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18= --===============6428177506198996194==--