From tony.cauli@rd.francetelecom.com Mon Sep 2 04:50:01 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by mail.gnome.org (Postfix) with ESMTP id 1BBF5182A8 for ; Mon, 2 Sep 2002 04:50:01 -0400 (EDT) Received: from LANMHS20.rd.francetelecom.fr ([10.193.21.60]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 2 Sep 2002 10:49:59 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2525D.B7DFB764" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 2 Sep 2002 10:49:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: xsltApplyStylesheetUser Thread-Index: AcJSXblWe1ZCc75EEdaiEQBgCAlsyQ== From: "zze-CAULI Tony FTRD/DTL/LAN" To: X-OriginalArrivalTime: 02 Sep 2002 08:49:59.0312 (UTC) FILETIME=[B80D7100:01C2525D] Subject: [xslt] xsltApplyStylesheetUser Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------_=_NextPart_001_01C2525D.B7DFB764 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello. I have a technical problem : I can't see the source code of the function = xsltApplyStylesheetUser. The link given in reference : = http://cvs.gnome.org/lxr/source/libxslt/libxslt/transform.c#3425 do not = indicate the source code of this function. Help ! ------_=_NextPart_001_01C2525D.B7DFB764 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable xsltApplyStylesheetUser

Hello.
I have a technical problem : I can't = see the source code of the function xsltApplyStylesheetUser.
The link given in reference : http://cvs.gnome.org/lxr/source/libxslt/libxslt/transform.c#3425 do = not indicate the source code of this function.

Help !

------_=_NextPart_001_01C2525D.B7DFB764-- From Holger.Rauch@heitec.de Mon Sep 2 05:25:54 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from christel.heitec.net (christel.heitec.net [193.101.232.3]) by mail.gnome.org (Postfix) with ESMTP id 274FB18675 for ; Mon, 2 Sep 2002 05:25:54 -0400 (EDT) Received: from miami.datech2.er.heitec.net (paladin.heitec.net [193.101.232.30]) by christel.heitec.net (Postfix) with ESMTP id B47DDB820A for ; Mon, 2 Sep 2002 11:25:53 +0200 (CEST) Date: Mon, 2 Sep 2002 11:25:52 +0200 (CEST) From: Holger Rauch To: xslt@gnome.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [xslt] Using libxslt to convert XML to non-XML Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: Holger Rauch List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Hi! I'm using libxslt to apply a stylesheet converting a XML file to space-separated values. Clearly, the output is no longer well-formed XML. So, my question is: How do I use the xmlDocPtr to access non-XML contents returned by xsltApplyStylesheet? I tried the following, but that of course doesn't work since the output produced by the stylesheet is not XML, so there is no root node: result = xsltApplyStylesheet( style, doc, NULL ); rootNode = xmlDocGetRootElement( result ); xmlBuff = xmlBufferCreate(); xmlNodeDump( xmlBuff, result, rootNode, 0, 1 ); result_set = g_string_new( xmlBufferContent( xmlBuff ) ); Thanks in advance for any help! Greetings, Holger From veillard@redhat.com Mon Sep 2 05:48:16 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1DADE1823D for ; Mon, 2 Sep 2002 05:48:16 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g829mCB13148 for xslt@gnome.org; Mon, 2 Sep 2002 05:48:12 -0400 Date: Mon, 2 Sep 2002 05:48:12 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] Using libxslt to convert XML to non-XML Message-ID: <20020902054812.A13160@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Holger.Rauch@heitec.de on Mon, Sep 02, 2002 at 11:25:52AM +0200 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Mon, Sep 02, 2002 at 11:25:52AM +0200, Holger Rauch wrote: > Hi! > > I'm using libxslt to apply a stylesheet converting a XML file to > space-separated values. Clearly, the output is no longer well-formed > XML. So, my question is: How do I use the xmlDocPtr to > access non-XML contents returned by xsltApplyStylesheet? I tried the Walk the doc->children tree(s) 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/ From veillard@redhat.com Mon Sep 2 05:51:31 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 098DC18398 for ; Mon, 2 Sep 2002 05:51:31 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g829pUI13832 for xslt@gnome.org; Mon, 2 Sep 2002 05:51:30 -0400 Date: Mon, 2 Sep 2002 05:51:30 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] xsltApplyStylesheetUser Message-ID: <20020902055130.B13160@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from tony.cauli@rd.francetelecom.com on Mon, Sep 02, 2002 at 10:49:59AM +0200 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Mon, Sep 02, 2002 at 10:49:59AM +0200, zze-CAULI Tony FTRD/DTL/LAN wrote: > Hello. > I have a technical problem : I can't see the source code of the function xsltApplyStylesheetUser. > The link given in reference : http://cvs.gnome.org/lxr/source/libxslt/libxslt/transform.c#3425 do not indicate the source code of this function. > Help ! The sources are available as tarball, it is the normal way to look at the code: ftp://xmlsoft.org/libxslt-version.tar.gz I can't provide any garantee on the LXR on-line engine, 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/ From datenkueche2001@yahoo.de Wed Sep 4 05:39:18 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from web21201.mail.yahoo.com (web21201.mail.yahoo.com [216.136.129.59]) by mail.gnome.org (Postfix) with SMTP id EC5E018920 for ; Wed, 4 Sep 2002 05:39:17 -0400 (EDT) Message-ID: <20020904093917.32060.qmail@web21201.mail.yahoo.com> Received: from [212.186.108.243] by web21201.mail.yahoo.com via HTTP; Wed, 04 Sep 2002 11:39:17 CEST Date: Wed, 4 Sep 2002 11:39:17 +0200 (CEST) From: =?iso-8859-1?q?Bernhard=20Zwischenbrugger?= To: xslt@gnome.org In-Reply-To: <20020902055130.B13160@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [xslt] Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: bz@datenkueche.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Hi I don't understand the difference between ---- 1 ---- and ---- 2 ---- ------------------------------------- In my opinion the result should be the same, but it isn't. Is this an error in libxslt (1.0.20) or is it a "user error". bye Bernhard Zwischenbrugger http://datenkueche.com __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Möchten Sie mit einem Gruß antworten? http://grusskarten.yahoo.de From Steve.Ball@zveno.com Thu Sep 5 17:15:08 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from waycool.zveno.com (static-ctb0236.webone.com.au [210.9.242.36]) by mail.gnome.org (Postfix) with ESMTP id 2E1B018863 for ; Thu, 5 Sep 2002 17:15:07 -0400 (EDT) Received: from zveno.com (pbook [192.168.1.4]) by waycool.zveno.com (8.12.5/8.12.5) with ESMTP id g85LOxuJ032039 for ; Fri, 6 Sep 2002 07:25:00 +1000 Message-ID: <3D77C9F7.60300@zveno.com> Date: Fri, 06 Sep 2002 07:17:43 +1000 From: Steve Ball Organization: Zveno Pty Ltd User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xslt@gnome.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [xslt] libxslt-1.0.20 Mac OS X Binaries Available Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: Steve.Ball@zveno.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Binaries for Mac OS X (10.1.5) for: libxml2-2.4.24 libxslt-1.0.20 are now available from http://www.zveno.com/open_source/ These are built as OS X frameworks. The libxml2 framework now has the header files moved into the 'libxml2' subdirectory. This should a problem with the previous distribution. Enjoy, Steve Ball -- Steve Ball | XSLT Standard Library | Training & Seminars Zveno Pty Ltd | Web Tcl Complete | XML XSL Schemas http://www.zveno.com/ | TclXML TclDOM | Tcl, Web Development Steve.Ball@zveno.com +---------------------------+--------------------- Ph. +61 2 6242 4099 | Mobile (0413) 594 462 | Fax +61 2 6242 4099 From andyh@myinternet.com.au Fri Sep 6 01:59:55 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from adm2.snc.schools.net.au (adm2.snc.schools.net.au [203.2.135.112]) by mail.gnome.org (Postfix) with ESMTP id 24AAE182E4 for ; Fri, 6 Sep 2002 01:59:55 -0400 (EDT) Received: by adm2.snc.schools.net.au (Postfix, from userid 500) id 0ED274358C; Fri, 6 Sep 2002 15:59:54 +1000 (EST) Received: from andyhirdlaptop (203.2.135.22) by (sina-mail/3.16-1.92, 18055) on Fri Sep 06 15:59:44 EST 2002 From: "Andy Hird" To: Date: Fri, 6 Sep 2002 15:58:38 +1000 Organization: Myinternet Message-ID: <002401c2556a$74e05b30$5209a8c0@andyhirdlaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sina-Mail-Agent: sinadeliver-3.16-1.92 Subject: [xslt] libxslt escaping urls when outputting HTML Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Hi all, I suspect this question has been asked before but having looked through the archives and bug db I couldn't find anything to help so here goes... I've been using libxslt for a while under Debian Linux for a while but have seen a change in behaviour in libxslt since the latest version came out (it involved an upgrade of libxslt from 1.16 -> 1.18). When the output method is set to html any commas in URLs are escaped (to %2C). eg. Got a stylesheet: test And an XML file: Running xsltproc with no options in version 1.16 we got the output: test (i.e. Comma between the hello and world) and with version 1.18 (and version 1.20 I just tested) we get: test I know that they are, in essence, the same thing but unfortunately we have some software relying on the former output (which we will fix). I was curious what prompted the change in libxslt and whether there was a way (within the xslt) of changing that escaping for the whole document (rather than using xsl:text elements with escape exceptions). Thanks Andy Hird From veillard@redhat.com Fri Sep 6 05:33:11 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 52FC818186 for ; Fri, 6 Sep 2002 05:33:11 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g869XBI21621 for xslt@gnome.org; Fri, 6 Sep 2002 05:33:11 -0400 Date: Fri, 6 Sep 2002 05:33:11 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] libxslt-1.0.20 Mac OS X Binaries Available Message-ID: <20020906053311.Z25901@redhat.com> References: <3D77C9F7.60300@zveno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D77C9F7.60300@zveno.com>; from Steve.Ball@zveno.com on Fri, Sep 06, 2002 at 07:17:43AM +1000 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Fri, Sep 06, 2002 at 07:17:43AM +1000, Steve Ball wrote: > Binaries for Mac OS X (10.1.5) for: > > libxml2-2.4.24 > libxslt-1.0.20 > > are now available from http://www.zveno.com/open_source/ > These are built as OS X frameworks. > > The libxml2 framework now has the header files moved into > the 'libxml2' subdirectory. This should a problem with the > previous distribution. Hi Steve, do you intend to maintain those binaries at this address ? Basically I'm wondering if I should link to them from the web site pages, if you plan to maintain those for some time, I will be happy to make that link, 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/ From veillard@redhat.com Fri Sep 6 05:46:05 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id EEB2618186 for ; Fri, 6 Sep 2002 05:46:04 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g869k4524598 for xslt@gnome.org; Fri, 6 Sep 2002 05:46:04 -0400 Date: Fri, 6 Sep 2002 05:46:04 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] libxslt escaping urls when outputting HTML Message-ID: <20020906054604.A25901@redhat.com> References: <002401c2556a$74e05b30$5209a8c0@andyhirdlaptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <002401c2556a$74e05b30$5209a8c0@andyhirdlaptop>; from andyh@myinternet.com.au on Fri, Sep 06, 2002 at 03:58:38PM +1000 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Fri, Sep 06, 2002 at 03:58:38PM +1000, Andy Hird wrote: [...] > and with version 1.18 (and version 1.20 I just tested) we get: > > test > > > I know that they are, in essence, the same thing but unfortunately we > have some software relying on the former output (which we will fix). > > I was curious what prompted the change in libxslt and whether there was > a way (within the xslt) of changing that escaping for the whole document > (rather than using xsl:text elements with escape exceptions). The reason is simple: standard conformance http://www.w3.org/TR/xslt#section-HTML-Output-Method "The html output method should escape non-ASCII characters in URI attribute values using the method recommended in Section B.2.1 of the HTML 4.0 Recommendation." RFC 2396 section 2.2. defines "," as being in the reserved character set which need escaping when the character may influence the semantic of the URI if not escaped. In the case of "," maybe this should not be escaped when present in the path section of the URI, that can be debated and possibly changed in libxml2 (i.e. I could be relatively easilly convince to change this :-) but it's always difficult to estimate the consequences of such changes). However considering the complexity of the issue, maybe it's a good thing to not rely on the former output anyway, and there isn't a way to avoid the escaping (even the xsl:text trick won't work in that case, the URI serializer won't look at this, the escaping disabling wasn't intended for this). 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/ From ast@gbt.tfo.upm.es Fri Sep 6 06:49:04 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from buzz.etsit.upm.es (buzz.etsit.upm.es [138.100.17.3]) by mail.gnome.org (Postfix) with SMTP id 4867B183B7 for ; Fri, 6 Sep 2002 06:49:03 -0400 (EDT) Received: (qmail 10230 invoked from network); 6 Sep 2002 10:48:08 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 6 Sep 2002 10:48:08 -0000 Received: (qmail 10227 invoked from network); 6 Sep 2002 10:48:08 -0000 Received: from torlux.gbt.tfo.upm.es (HELO gbt.tfo.upm.es) (138.4.10.78) by buzz.etsit.upm.es with SMTP; 6 Sep 2002 10:48:08 -0000 Received: from gbt.tfo.upm.es (leo.gbt.tfo.upm.es [138.4.10.70]) by gbt.tfo.upm.es (8.11.0/8.11.0) with ESMTP id g86AwU307176 for ; Fri, 6 Sep 2002 12:58:30 +0200 Message-ID: <3D7889DD.5050505@gbt.tfo.upm.es> Date: Fri, 06 Sep 2002 12:56:29 +0200 From: =?ISO-8859-1?Q?Alberto_S=E1ez_Torres?= User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: es, en-us, en MIME-Version: 1.0 To: xslt@gnome.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [xslt] Problems with validation and xslt Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Hello. I've some help with libxslt and xsltproc. I have been working with saxon 7.2, and now I need to sure than the xsl stylesheet is cross-plataform. I have 2 problems. +first: xsltproc doesn't validate against a dtd. + second: with the next code: (...) (...) I get the error message: compilation error: file ../base/curso2lecHTML.xsl line 34 element stylesheet xsl:version: only 1.0 features are supported compilation error: file ../base/general.xsl line 605 element result-document xsltStylePreCompute: unknown xsl:result-document Why?? I use element-avaiable and fallback; What is the problem?? Thanks a lot for your help I have another question: The xslt 2.0 spec is great. Why only saxon implements it ? (yes, I know that the spec isn't read yet, ) From Steve.Ball@zveno.com Fri Sep 6 19:54:20 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from waycool.zveno.com (static-ctb0236.webone.com.au [210.9.242.36]) by mail.gnome.org (Postfix) with ESMTP id 07C2C181C2 for ; Fri, 6 Sep 2002 19:54:20 -0400 (EDT) Received: from zveno.com (pbook [192.168.1.4]) by waycool.zveno.com (8.12.5/8.12.5) with ESMTP id g8704LuJ007367 for ; Sat, 7 Sep 2002 10:04:22 +1000 Message-ID: <3D7940C6.5060003@zveno.com> Date: Sat, 07 Sep 2002 09:56:54 +1000 From: Steve Ball Organization: Zveno Pty Ltd User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xslt@gnome.org Subject: Re: [xslt] libxslt-1.0.20 Mac OS X Binaries Available References: <3D77C9F7.60300@zveno.com> <20020906053311.Z25901@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: Steve.Ball@zveno.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Hi Daniel, You wrote: > On Fri, Sep 06, 2002 at 07:17:43AM +1000, Steve Ball wrote: > >>Binaries for Mac OS X (10.1.5) for: [...snip...] > > do you intend to maintain those binaries at this address ? > Basically I'm wondering if I should link to them from the > web site pages, if you plan to maintain those for some time, > I will be happy to make that link, Last time I looked the website already had the appropriate link in the Downloads page. The actual address is http://www.zveno.com/open_source/libxml2xslt.html and this is on the xmlsoft page. My intention is to maintain the Mac OS X binaries at that address on the Zveno website for the forseeable future. Cheers, Steve Ball -- Steve Ball | XSLT Standard Library | Training & Seminars Zveno Pty Ltd | Web Tcl Complete | XML XSL Schemas http://www.zveno.com/ | TclXML TclDOM | Tcl, Web Development Steve.Ball@zveno.com +---------------------------+--------------------- Ph. +61 2 6242 4099 | Mobile (0413) 594 462 | Fax +61 2 6242 4099 From veillard@redhat.com Mon Sep 9 06:58:38 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id C17D01828E for ; Mon, 9 Sep 2002 06:58:37 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g89AwbT02111 for xslt@gnome.org; Mon, 9 Sep 2002 06:58:37 -0400 Date: Mon, 9 Sep 2002 06:58:37 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] libxslt-1.0.20 Mac OS X Binaries Available Message-ID: <20020909065837.C10346@redhat.com> References: <3D77C9F7.60300@zveno.com> <20020906053311.Z25901@redhat.com> <3D7940C6.5060003@zveno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D7940C6.5060003@zveno.com>; from Steve.Ball@zveno.com on Sat, Sep 07, 2002 at 09:56:54AM +1000 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Sat, Sep 07, 2002 at 09:56:54AM +1000, Steve Ball wrote: [...] > Last time I looked the website already had the appropriate > link in the Downloads page. The actual address is > http://www.zveno.com/open_source/libxml2xslt.html and this > is on the xmlsoft page. > > My intention is to maintain the Mac OS X binaries at that > address on the Zveno website for the forseeable future. Okay I wanted to add a link on the left bar of the pages like the links for the Windows and Solaris binaries in the "Related Links" section, done now check http://xmlsoft.org/ ! thanks ! 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/ From bko@ix.netcom.com Mon Sep 9 00:52:42 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by mail.gnome.org (Postfix) with ESMTP id AA776181FD for ; Mon, 9 Sep 2002 00:52:42 -0400 (EDT) Received: from 207-237-114-80.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com ([207.237.114.80] helo=[192.168.1.100]) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.35 #6) id 17oGXS-0003Ok-00 for xslt@gnome.org; Mon, 09 Sep 2002 00:52:42 -0400 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 09 Sep 2002 00:52:40 -0400 From: Ben Ko To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [xslt] Possible bug in libxslt? Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: The following stylesheet w/a single match should drop all content from the processed xml file. With MSXML on Windows, it drops all the text, as expected With Xalan on Windows, it drops all the text, as expected With ActiveState Komodo on Windows, it drops all text, as expected With Sabltron on OS X, it drops all the text, as expected With LibXSLT, on both Windows and OS X, it preserves all the text, which is not what I expected. Is this a bug in LibXSLT? Or does LibXSLT expect the rule to be written differently? Thanks, Ben From veillard@redhat.com Mon Sep 9 08:19:39 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D91AC18618 for ; Mon, 9 Sep 2002 08:19:38 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g89CJbu20788; Mon, 9 Sep 2002 08:19:37 -0400 Date: Mon, 9 Sep 2002 08:19:37 -0400 From: Daniel Veillard To: bko@ix.netcom.com Cc: xslt@gnome.org Subject: Re: [xslt] Possible bug in libxslt? Message-ID: <20020909081937.D10346@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from bko@ix.netcom.com on Mon, Sep 09, 2002 at 12:52:40AM -0400 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Mon, Sep 09, 2002 at 12:52:40AM -0400, Ben Ko wrote: > The following stylesheet w/a single match > > > > > > should drop all content from the processed xml file. > > With MSXML on Windows, it drops all the text, as expected > > With Xalan on Windows, it drops all the text, as expected > > With ActiveState Komodo on Windows, it drops all text, as expected > > With Sabltron on OS X, it drops all the text, as expected > > With LibXSLT, on both Windows and OS X, it preserves all the text, which is > not what I expected. > > Is this a bug in LibXSLT? Or does LibXSLT expect the rule to be written > differently? it was a bug, now fixed in CVS: http://cvs.gnome.org/bonsai/cvsquery.cgi?module=libxslt&branch=HEAD&branchtype=match&dir=libxslt&file=&filetype=match&who=veillard&whotype=match&sortby=Date&hours=&date=explicit&mindate=09%2F09%2F02+08%3A07&maxdate=09%2F09%2F02+08%3A09&cvsroot=%2Fcvs%2Fgnome thanks ! 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/ From dcramer@broadjump.com Mon Sep 9 18:41:37 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from macross.inhouse.broadjump.com (ns.broadjump.com [12.39.176.252]) by mail.gnome.org (Postfix) with ESMTP id 7EE0A188EC for ; Mon, 9 Sep 2002 18:41:37 -0400 (EDT) Received: from logos.inhouse.broadjump.com (logos.inhouse.broadjump.com [10.64.3.15]) by macross.inhouse.broadjump.com (8.12.2/8.12.2) with ESMTP id g89Mfadn011933 for ; Mon, 9 Sep 2002 17:41:36 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Sep 2002 17:41:36 -0500 Message-ID: <97B71B827DFB2B448A73EC00E5DA0EE63CA07C@logos.inhouse.broadjump.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: xsltproc on windows front slash/backslash conundrum Thread-Index: AcJYUg2/CtMbKhkLTnKkDKG/PQBL/g== From: "David Cramer" To: X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Subject: [xslt] xsltproc on windows front slash/backslash conundrum Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Our tool chain runs on Solaris and Windows. In the following example (on Win2K), the xslt branding.xsl sets some params and imports filter.xsl. If I invoke xsltproc in the following way, with back slashes in the path to branding.xsl, I get the following error: H:\pkdp\docmodules\mary\enus\frankenhelp>"C:\Documents and Settings\dcramer\Desk top\xsltproc\bin\xsltproc.exe" -o frankenfiltered.xml "h:\pkdp\docmodules\doctoo ls\1.0\DocShared\xsl\filter\branding.xsl" frankenproc.xml warning: failed to load external entity "filter.xsl" compilation error: file h:/pkdp/docmodules/doctools/1.0/DocShared/xsl/filter/branding.xsl line 7 element import xsl:import : unable to load filter.xsl If I change the backslashes to front slashes, it works fine as long as the document doesn't contain any external entities (and the xsl tries to resolve them). If the document contains external entities and I use forward slashes in the path, then I get: H:\pkdp\docmodules\mary\enus\frankenhelp>"C:\Documents and Settings\dcramer\Desk top\xsltproc\bin\xsltproc.exe" -o frankenfiltered.xml "h:/pkdp/docmodules/doctoo ls/1.0/DocShared/xsl/share/holmanize.xsl" frankenhelp.xml warning: failed to load external entity "h:///pkdp/docmodules/doctools/1.0/DocShared/xsl/share/frankenguide.xml" In this case, xsltproc is very confused about where to look for frankenguide.xml, which is really in the same directory as frankenhelp.xml, not in the same directory as the xsl stylesheet.=20 Unfortunately, we have doc build system in perl that runs our docs through a series of transformations, the first of which would work if I used xsltproc with back slashes, the rest if I used back slashes. I'd like to switch to xsltproc for the speed savings, but don't think I can talk the developer who owns the code into using backslashes on one pass and front slashes on the others. It would probably be better to fix xsltproc or the code it uses anyway. I've tried various combinations of front and backslashes, with no luck. If there's nothing I'm missing, I'd like to report this as a bug. Thanks, David Version Info: H:\pkdp\docmodules\mary\enus\frankenhelp>"C:\Documents and Settings\dcramer\Desk top\xsltproc\bin\xsltproc.exe" --version Using libxml 20424, libxslt 10020 and libexslt 711 xsltproc was compiled against libxml 20424, libxslt 10020 and libexslt 711 libxslt 10020 was compiled against libxml 20424 libexslt 711 was compiled against libxml 20424 From veillard@redhat.com Tue Sep 10 04:49:43 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 9881D1894D for ; Tue, 10 Sep 2002 04:49:43 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8A8nhf05056 for xslt@gnome.org; Tue, 10 Sep 2002 04:49:43 -0400 Date: Tue, 10 Sep 2002 04:49:43 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] xsltproc on windows front slash/backslash conundrum Message-ID: <20020910044943.A2295@redhat.com> References: <97B71B827DFB2B448A73EC00E5DA0EE63CA07C@logos.inhouse.broadjump.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <97B71B827DFB2B448A73EC00E5DA0EE63CA07C@logos.inhouse.broadjump.com>; from dcramer@broadjump.com on Mon, Sep 09, 2002 at 05:41:36PM -0500 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Mon, Sep 09, 2002 at 05:41:36PM -0500, David Cramer wrote: > H:\pkdp\docmodules\mary\enus\frankenhelp>"C:\Documents and > Settings\dcramer\Desk > top\xsltproc\bin\xsltproc.exe" -o frankenfiltered.xml > "h:/pkdp/docmodules/doctoo > ls/1.0/DocShared/xsl/share/holmanize.xsl" frankenhelp.xml > warning: failed to load external entity > "h:///pkdp/docmodules/doctools/1.0/DocShared/xsl/share/frankenguide.xml" > > In this case, xsltproc is very confused about where to look for > frankenguide.xml, which is really in the same directory as > frankenhelp.xml, not in the same directory as the xsl stylesheet. > > Unfortunately, we have doc build system in perl that runs our docs > through a series of transformations, the first of which would work if I > used xsltproc with back slashes, the rest if I used back slashes. I'd > like to switch to xsltproc for the speed savings, but don't think I can > talk the developer who owns the code into using backslashes on one pass > and front slashes on the others. It would probably be better to fix > xsltproc or the code it uses anyway. > > I've tried various combinations of front and backslashes, with no luck. > If there's nothing I'm missing, I'd like to report this as a bug. Have you tried the following ? file:///h:/pkdp/docmodules/doctools/1.0/DocShared/xsl/share/frankenguide.xml I think that's the correct URL for a resource on a local Windows system. The problem is that when parsed h:///pkdp/docmodules/doctools/1.0/DocShared/xsl/share/frankenguide.xml according to RFC 2396 URI parsing rules your file path generate an URI which is unfetchable (protocol "h" !) I'm kind of annoyed by: 1/ the number of time this get raised 2/ the fact that trying to fix it might be a deviation to the strict rules of the standard But as 1/ accumulates maybe I'm gonna get really bored and make a special routine when compiling on windows to automagically convert a Windows file path to a correct URI, it's not fun but ... 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/ From veillard@redhat.com Tue Sep 10 08:15:08 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id B4674187C6; Tue, 10 Sep 2002 08:15:07 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8ACF7s19090; Tue, 10 Sep 2002 08:15:07 -0400 Date: Tue, 10 Sep 2002 08:15:07 -0400 From: Daniel Veillard To: xslt@gnome.org, xml@gnome.org Subject: Re: [xslt] xsltproc on windows front slash/backslash conundrum Message-ID: <20020910081507.D2295@redhat.com> References: <97B71B827DFB2B448A73EC00E5DA0EE63CA07C@logos.inhouse.broadjump.com> <20020910044943.A2295@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020910044943.A2295@redhat.com>; from veillard@redhat.com on Tue, Sep 10, 2002 at 04:49:43AM -0400 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [initally posted in xslt@gnome.org but this really affects all libxml2 users] On Tue, Sep 10, 2002 at 04:49:43AM -0400, Daniel Veillard wrote: > I think that's the correct URL for a resource on a local Windows system. > The problem is that when parsed > h:///pkdp/docmodules/doctools/1.0/DocShared/xsl/share/frankenguide.xml > according to RFC 2396 URI parsing rules your file path generate an URI > which is unfetchable (protocol "h" !) > > I'm kind of annoyed by: > 1/ the number of time this get raised > 2/ the fact that trying to fix it might be a deviation to the strict rules > of the standard > > But as 1/ accumulates maybe I'm gonna get really bored and make a special > routine when compiling on windows to automagically convert a Windows > file path to a correct URI, it's not fun but ... Okay, 1/ won ! I tried to cover the various paths where a filename is passed down the library for loading of a resource and plug a Windows->URL filename converter. I would appreciate if Windows users could test the enclosed patch I commited to CVS for libxml2 and report problems or unvovered code paths where the conversion might still be missing. BTW the new function xmlNormalizeWindowsPath() doesn't try to fix \a\b\c to file:///a/b/c while it should fix c:\a\b\c to file:///c:a/b/c 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/ --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="windowspaths.patch" Index: DOCBparser.c =================================================================== RCS file: /cvs/gnome/gnome-xml/DOCBparser.c,v retrieving revision 1.25 retrieving revision 1.26 diff -c -r1.25 -r1.26 *** DOCBparser.c 5 Sep 2002 11:33:24 -0000 1.25 --- DOCBparser.c 10 Sep 2002 11:13:43 -0000 1.26 *************** *** 6025,6031 **** } memset(inputStream, 0, sizeof(docbParserInput)); ! inputStream->filename = xmlMemStrdup(filename); inputStream->line = 1; inputStream->col = 1; inputStream->buf = buf; --- 6025,6031 ---- } memset(inputStream, 0, sizeof(docbParserInput)); ! inputStream->filename = xmlNormalizeWindowsPath(filename); inputStream->line = 1; inputStream->col = 1; inputStream->buf = buf; Index: HTMLparser.c =================================================================== RCS file: /cvs/gnome/gnome-xml/HTMLparser.c,v retrieving revision 1.118 retrieving revision 1.119 diff -c -r1.118 -r1.119 *** HTMLparser.c 5 Sep 2002 11:33:24 -0000 1.118 --- HTMLparser.c 10 Sep 2002 11:13:43 -0000 1.119 *************** *** 4881,4887 **** } memset(inputStream, 0, sizeof(htmlParserInput)); ! inputStream->filename = xmlMemStrdup(filename); inputStream->line = 1; inputStream->col = 1; inputStream->buf = buf; --- 4881,4887 ---- } memset(inputStream, 0, sizeof(htmlParserInput)); ! inputStream->filename = xmlNormalizeWindowsPath(filename); inputStream->line = 1; inputStream->col = 1; inputStream->buf = buf; Index: error.c =================================================================== RCS file: /cvs/gnome/gnome-xml/error.c,v retrieving revision 1.42 diff -c -r1.42 error.c *** error.c 5 Sep 2002 14:21:11 -0000 1.42 --- error.c 10 Sep 2002 12:11:07 -0000 *************** *** 353,359 **** int len = xmlStrlen((const xmlChar *) msg); static int had_info = 0; int need_context = 0; - int need_info = 0; if ((len > 1) && (msg[len - 2] != ':')) { if (ctxt != NULL) { --- 353,358 ---- Index: parser.c =================================================================== RCS file: /cvs/gnome/gnome-xml/parser.c,v retrieving revision 1.219 retrieving revision 1.220 diff -c -r1.219 -r1.220 *** parser.c 5 Sep 2002 11:33:24 -0000 1.219 --- parser.c 10 Sep 2002 11:13:42 -0000 1.220 *************** *** 666,672 **** static void deallocblankswrapper (xmlChar *str) {xmlFree(str);} ! xmlParserInputPtr xmlNewBlanksWrapperInputStream(xmlParserCtxtPtr ctxt, xmlEntityPtr entity) { xmlParserInputPtr input; xmlChar *buffer; --- 666,672 ---- static void deallocblankswrapper (xmlChar *str) {xmlFree(str);} ! static xmlParserInputPtr xmlNewBlanksWrapperInputStream(xmlParserCtxtPtr ctxt, xmlEntityPtr entity) { xmlParserInputPtr input; xmlChar *buffer; *************** *** 1808,1819 **** * and the name for mismatch */ ! xmlChar * xmlParseNameAndCompare(xmlParserCtxtPtr ctxt, xmlChar const *other) { const xmlChar *cmp = other; const xmlChar *in; xmlChar *ret; - int count = 0; GROW; --- 1808,1818 ---- * and the name for mismatch */ ! static xmlChar * xmlParseNameAndCompare(xmlParserCtxtPtr ctxt, xmlChar const *other) { const xmlChar *cmp = other; const xmlChar *in; xmlChar *ret; GROW; *************** *** 2275,2282 **** xmlChar * xmlParseAttValue(xmlParserCtxtPtr ctxt) { xmlChar limit = 0; ! xmlChar *buf = NULL; ! xmlChar *in = NULL; xmlChar *ret = NULL; SHRINK; GROW; --- 2274,2280 ---- xmlChar * xmlParseAttValue(xmlParserCtxtPtr ctxt) { xmlChar limit = 0; ! const xmlChar *in = NULL; xmlChar *ret = NULL; SHRINK; GROW; *************** *** 9002,9008 **** if (filename == NULL) inputStream->filename = NULL; else ! inputStream->filename = xmlMemStrdup(filename); inputStream->buf = buf; inputStream->base = inputStream->buf->buffer->content; inputStream->cur = inputStream->buf->buffer->content; --- 9000,9007 ---- if (filename == NULL) inputStream->filename = NULL; else ! inputStream->filename = (char *) ! xmlNormalizeWindowsPath((const xmlChar *) filename); inputStream->buf = buf; inputStream->base = inputStream->buf->buffer->content; inputStream->cur = inputStream->buf->buffer->content; *************** *** 10021,10026 **** --- 10020,10026 ---- xmlParserCtxtPtr ctxt; xmlParserInputPtr inputStream; char *directory = NULL; + xmlChar *normalized; ctxt = xmlNewParserCtxt(); if (ctxt == NULL) { *************** *** 10030,10046 **** return(NULL); } ! inputStream = xmlLoadExternalEntity(filename, NULL, ctxt); if (inputStream == NULL) { xmlFreeParserCtxt(ctxt); return(NULL); } inputPush(ctxt, inputStream); if ((ctxt->directory == NULL) && (directory == NULL)) ! directory = xmlParserGetDirectory(filename); if ((ctxt->directory == NULL) && (directory != NULL)) ctxt->directory = directory; return(ctxt); } --- 10030,10054 ---- return(NULL); } ! normalized = xmlNormalizeWindowsPath((const xmlChar *) filename); ! if (normalized == NULL) { ! xmlFreeParserCtxt(ctxt); ! return(NULL); ! } ! inputStream = xmlLoadExternalEntity((char *) normalized, NULL, ctxt); if (inputStream == NULL) { xmlFreeParserCtxt(ctxt); + xmlFree(normalized); return(NULL); } inputPush(ctxt, inputStream); if ((ctxt->directory == NULL) && (directory == NULL)) ! directory = xmlParserGetDirectory((char *) normalized); if ((ctxt->directory == NULL) && (directory != NULL)) ctxt->directory = directory; + + xmlFree(normalized); return(ctxt); } Index: xmlIO.c =================================================================== RCS file: /cvs/gnome/gnome-xml/xmlIO.c,v retrieving revision 1.87 diff -c -r1.87 xmlIO.c *** xmlIO.c 5 Sep 2002 11:33:25 -0000 1.87 --- xmlIO.c 10 Sep 2002 12:11:08 -0000 *************** *** 123,128 **** --- 123,185 ---- static int xmlOutputCallbackNr = 0; static int xmlOutputCallbackInitialized = 0; + /************************************************************************ + * * + * Handling of Windows file paths * + * * + ************************************************************************/ + + #define IS_WINDOWS_PATH(p) \ + ((p != NULL) && \ + (((p[0] >= 'a') && (p[0] <= 'z')) || \ + ((p[0] >= 'A') && (p[0] <= 'Z'))) && \ + (p[1] == ':') && ((p[2] == '/') || (p[2] == '\\'))) + + + /** + * xmlNormalizeWindowsPath + * @path: a windows path like "C:/foo/bar" + * + * Normalize a Windows path to make an URL from it + * + * Returns a new URI which must be freed by the caller or NULL + * in case of error + */ + xmlChar * + xmlNormalizeWindowsPath(const xmlChar *path) + { + int len, i, j; + xmlChar *ret; + + if (path == NULL) + return(NULL); + if (!IS_WINDOWS_PATH(path)) + return(xmlStrdup(path)); + + len = xmlStrlen(path); + ret = xmlMalloc(len + 10); + if (ret == NULL) + return(NULL); + + ret[0] = 'f'; + ret[1] = 'i'; + ret[2] = 'l'; + ret[3] = 'e'; + ret[4] = ':'; + ret[5] = '/'; + ret[6] = '/'; + ret[7] = '/'; + for (i = 0,j = 8;i < len;i++,j++) { + /* TODO: UTF8 conversion + URI escaping ??? */ + if (path[i] == '\\') + ret[j] = '/'; + else + ret[j] = path[i]; + } + ret[j] = 0; + return(ret); + } + /** * xmlCleanupInputCallbacks: * *************** *** 296,302 **** return((void *) fd); } ! if (!xmlStrncasecmp(BAD_CAST filename, BAD_CAST "file://localhost", 16)) #if defined (_WIN32) && !defined(__CYGWIN__) path = &filename[17]; #else --- 353,359 ---- return((void *) fd); } ! if (!xmlStrncasecmp(BAD_CAST filename, BAD_CAST "file://localhost/", 17)) #if defined (_WIN32) && !defined(__CYGWIN__) path = &filename[17]; #else *************** *** 343,350 **** return((void *) fd); } ! if (!xmlStrncasecmp(BAD_CAST filename, BAD_CAST "file://localhost", 16)) path = &filename[16]; else if (!xmlStrncasecmp(BAD_CAST filename, BAD_CAST "file:///", 8)) { #if defined (_WIN32) && !defined(__CYGWIN__) path = &filename[8]; --- 400,411 ---- return((void *) fd); } ! if (!xmlStrncasecmp(BAD_CAST filename, BAD_CAST "file://localhost/", 17)) ! #if defined (_WIN32) && !defined(__CYGWIN__) ! path = &filename[17]; ! #else path = &filename[16]; + #endif else if (!xmlStrncasecmp(BAD_CAST filename, BAD_CAST "file:///", 8)) { #if defined (_WIN32) && !defined(__CYGWIN__) path = &filename[8]; *************** *** 460,467 **** return((void *) fd); } ! if (!xmlStrncasecmp(BAD_CAST filename, BAD_CAST "file://localhost", 16)) path = &filename[16]; else if (!xmlStrncasecmp(BAD_CAST filename, BAD_CAST "file:///", 8)) { #if defined (_WIN32) && !defined(__CYGWIN__) path = &filename[8]; --- 521,532 ---- return((void *) fd); } ! if (!xmlStrncasecmp(BAD_CAST filename, BAD_CAST "file://localhost/", 17)) ! #if defined (_WIN32) && !defined(__CYGWIN__) ! path = &filename[17]; ! #else path = &filename[16]; + #endif else if (!xmlStrncasecmp(BAD_CAST filename, BAD_CAST "file:///", 8)) { #if defined (_WIN32) && !defined(__CYGWIN__) path = &filename[8]; *************** *** 502,509 **** return((void *) fd); } ! if (!xmlStrncasecmp(BAD_CAST filename, BAD_CAST "file://localhost", 16)) path = &filename[16]; else if (!xmlStrncasecmp(BAD_CAST filename, BAD_CAST "file:///", 8)) { #if defined (_WIN32) && !defined(__CYGWIN__) path = &filename[8]; --- 567,578 ---- return((void *) fd); } ! if (!xmlStrncasecmp(BAD_CAST filename, BAD_CAST "file://localhost/", 17)) ! #if defined (_WIN32) && !defined(__CYGWIN__) ! path = &filename[17]; ! #else path = &filename[16]; + #endif else if (!xmlStrncasecmp(BAD_CAST filename, BAD_CAST "file:///", 8)) { #if defined (_WIN32) && !defined(__CYGWIN__) path = &filename[8]; *************** *** 1656,1666 **** --- 1725,1738 ---- int i = 0; void *context = NULL; char *unescaped; + char *normalized; if (xmlInputCallbackInitialized == 0) xmlRegisterDefaultInputCallbacks(); if (URI == NULL) return(NULL); + normalized = (char *) xmlNormalizeWindowsPath((const xmlChar *)URI); + if (normalized == NULL) return(NULL); #ifdef LIBXML_CATALOG_ENABLED #endif *************** *** 1670,1676 **** * Go in reverse to give precedence to user defined handlers. * try with an unescaped version of the URI */ ! unescaped = xmlURIUnescapeString(URI, 0, NULL); if (unescaped != NULL) { for (i = xmlInputCallbackNr - 1;i >= 0;i--) { if ((xmlInputCallbackTable[i].matchcallback != NULL) && --- 1742,1748 ---- * Go in reverse to give precedence to user defined handlers. * try with an unescaped version of the URI */ ! unescaped = xmlURIUnescapeString((char *) normalized, 0, NULL); if (unescaped != NULL) { for (i = xmlInputCallbackNr - 1;i >= 0;i--) { if ((xmlInputCallbackTable[i].matchcallback != NULL) && *************** *** 1691,1702 **** for (i = xmlInputCallbackNr - 1;i >= 0;i--) { if ((xmlInputCallbackTable[i].matchcallback != NULL) && (xmlInputCallbackTable[i].matchcallback(URI) != 0)) { ! context = xmlInputCallbackTable[i].opencallback(URI); if (context != NULL) break; } } } if (context == NULL) { return(NULL); } --- 1763,1775 ---- for (i = xmlInputCallbackNr - 1;i >= 0;i--) { if ((xmlInputCallbackTable[i].matchcallback != NULL) && (xmlInputCallbackTable[i].matchcallback(URI) != 0)) { ! context = xmlInputCallbackTable[i].opencallback(normalized); if (context != NULL) break; } } } + xmlFree(normalized); if (context == NULL) { return(NULL); } *************** *** 1736,1741 **** --- 1809,1815 ---- int i = 0; void *context = NULL; char *unescaped; + char *normalized; int is_http_uri = 0; /* Can't change if HTTP disabled */ *************** *** 1743,1753 **** xmlRegisterDefaultOutputCallbacks(); if (URI == NULL) return(NULL); #ifdef LIBXML_HTTP_ENABLED /* Need to prevent HTTP URI's from falling into zlib short circuit */ ! is_http_uri = xmlIOHTTPMatch( URI ); #endif --- 1817,1829 ---- xmlRegisterDefaultOutputCallbacks(); if (URI == NULL) return(NULL); + normalized = (char *) xmlNormalizeWindowsPath((const xmlChar *)URI); + if (normalized == NULL) return(NULL); #ifdef LIBXML_HTTP_ENABLED /* Need to prevent HTTP URI's from falling into zlib short circuit */ ! is_http_uri = xmlIOHTTPMatch( normalized ); #endif *************** *** 1756,1762 **** * Go in reverse to give precedence to user defined handlers. * try with an unescaped version of the URI */ ! unescaped = xmlURIUnescapeString(URI, 0, NULL); if (unescaped != NULL) { #ifdef HAVE_ZLIB_H if ((compression > 0) && (compression <= 9) && (is_http_uri == 0)) { --- 1832,1838 ---- * Go in reverse to give precedence to user defined handlers. * try with an unescaped version of the URI */ ! unescaped = xmlURIUnescapeString(normalized, 0, NULL); if (unescaped != NULL) { #ifdef HAVE_ZLIB_H if ((compression > 0) && (compression <= 9) && (is_http_uri == 0)) { *************** *** 1769,1774 **** --- 1845,1851 ---- ret->closecallback = xmlGzfileClose; } xmlFree(unescaped); + xmlFree(normalized); return(ret); } } *************** *** 1797,1803 **** if (context == NULL) { #ifdef HAVE_ZLIB_H if ((compression > 0) && (compression <= 9) && (is_http_uri == 0)) { ! context = xmlGzfileOpenW(URI, compression); if (context != NULL) { ret = xmlAllocOutputBuffer(encoder); if (ret != NULL) { --- 1874,1880 ---- if (context == NULL) { #ifdef HAVE_ZLIB_H if ((compression > 0) && (compression <= 9) && (is_http_uri == 0)) { ! context = xmlGzfileOpenW(normalized, compression); if (context != NULL) { ret = xmlAllocOutputBuffer(encoder); if (ret != NULL) { *************** *** 1805,1817 **** ret->writecallback = xmlGzfileWrite; ret->closecallback = xmlGzfileClose; } return(ret); } } #endif for (i = xmlOutputCallbackNr - 1;i >= 0;i--) { if ((xmlOutputCallbackTable[i].matchcallback != NULL) && ! (xmlOutputCallbackTable[i].matchcallback(URI) != 0)) { #if defined(LIBXML_HTTP_ENABLED) && defined(HAVE_ZLIB_H) /* Need to pass compression parameter into HTTP open calls */ if (xmlOutputCallbackTable[i].matchcallback == xmlIOHTTPMatch) --- 1882,1895 ---- ret->writecallback = xmlGzfileWrite; ret->closecallback = xmlGzfileClose; } + xmlFree(normalized); return(ret); } } #endif for (i = xmlOutputCallbackNr - 1;i >= 0;i--) { if ((xmlOutputCallbackTable[i].matchcallback != NULL) && ! (xmlOutputCallbackTable[i].matchcallback(normalized) != 0)) { #if defined(LIBXML_HTTP_ENABLED) && defined(HAVE_ZLIB_H) /* Need to pass compression parameter into HTTP open calls */ if (xmlOutputCallbackTable[i].matchcallback == xmlIOHTTPMatch) *************** *** 1824,1829 **** --- 1902,1908 ---- } } } + xmlFree(normalized); if (context == NULL) { return(NULL); *************** *** 2450,2457 **** if (URL == NULL) return(0); ! if (!xmlStrncasecmp(BAD_CAST URL, BAD_CAST "file://localhost", 16)) path = &URL[16]; else if (!xmlStrncasecmp(BAD_CAST URL, BAD_CAST "file:///", 8)) { #if defined (_WIN32) && !defined(__CYGWIN__) path = &URL[8]; --- 2529,2540 ---- if (URL == NULL) return(0); ! if (!xmlStrncasecmp(BAD_CAST URL, BAD_CAST "file://localhost/", 17)) ! #if defined (_WIN32) && !defined(__CYGWIN__) ! path = &URL[17]; ! #else path = &URL[16]; + #endif else if (!xmlStrncasecmp(BAD_CAST URL, BAD_CAST "file:///", 8)) { #if defined (_WIN32) && !defined(__CYGWIN__) path = &URL[8]; *************** *** 2639,2646 **** if (URL == NULL) return (0); ! if (!xmlStrncasecmp(BAD_CAST URL, BAD_CAST "file://localhost", 16)) ! path = &URL[16]; else if (!xmlStrncasecmp(BAD_CAST URL, BAD_CAST "file:///", 8)) { #if defined (_WIN32) && !defined(__CYGWIN__) path = &URL[8]; --- 2722,2733 ---- if (URL == NULL) return (0); ! if (!xmlStrncasecmp(BAD_CAST URL, BAD_CAST "file://localhost/", 17)) ! #if defined (_WIN32) && !defined(__CYGWIN__) ! path = &URL[17]; ! #else ! path = &URL[16]; ! #endif else if (!xmlStrncasecmp(BAD_CAST URL, BAD_CAST "file:///", 8)) { #if defined (_WIN32) && !defined(__CYGWIN__) path = &URL[8]; Index: include/libxml/xmlIO.h =================================================================== RCS file: /cvs/gnome/gnome-xml/include/libxml/xmlIO.h,v retrieving revision 1.36 retrieving revision 1.37 diff -c -r1.36 -r1.37 *** include/libxml/xmlIO.h 1 May 2002 18:32:27 -0000 1.36 --- include/libxml/xmlIO.h 10 Sep 2002 11:13:41 -0000 1.37 *************** *** 252,257 **** --- 252,258 ---- const char *ID, xmlParserCtxtPtr ctxt); + xmlChar *xmlNormalizeWindowsPath (const xmlChar *path); /** * Default 'file://' protocol callbacks --XOIedfhf+7KOe/yw-- From dcramer@broadjump.com Tue Sep 10 14:24:20 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from arapahoe.inhouse.broadjump.com (ns3.broadjump.com [12.39.176.253]) by mail.gnome.org (Postfix) with ESMTP id 285FA18152; Tue, 10 Sep 2002 14:24:20 -0400 (EDT) Received: from logos.inhouse.broadjump.com (logos.inhouse.broadjump.com [10.64.3.15]) by arapahoe.inhouse.broadjump.com (8.12.2/8.12.2) with ESMTP id g8AIOI6C001236; Tue, 10 Sep 2002 13:24:18 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Sep 2002 13:24:18 -0500 Message-ID: <97B71B827DFB2B448A73EC00E5DA0EE63CA084@logos.inhouse.broadjump.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: periods legal in an NMTOKEN Thread-Index: AcJY90axyT2ycbIfRwGfHzvwAifOiA== From: "David Cramer" To: , X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Subject: [xslt] periods legal in an NMTOKEN Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: We have a dtd with attributes defined as NMTOKEN. When the attribute values have periods in them, we get the error: "validity error: standalone: foo on bar value had to be normalized based on external subset declaration" Our processing system is designed to die on the word error (some other xsl processors aren't so nice with their exit codes). If I change NMTOKEN to CDATA in the DTD, we no longer get the error but that causes other problems.=20 Looking at the spec, I think periods should be ok in an NMTOKEN: http://www.w3c.org/TR/2000/REC-xml-20001006#NT-Nmtoken Thanks, David From veillard@redhat.com Tue Sep 10 17:29:09 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1B03418BFE; Tue, 10 Sep 2002 17:29:09 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8ALSu204244; Tue, 10 Sep 2002 17:28:56 -0400 Date: Tue, 10 Sep 2002 17:28:55 -0400 From: Daniel Veillard To: David Cramer Cc: xslt@gnome.org, xml@gnome.org Message-ID: <20020910172855.D9261@redhat.com> References: <97B71B827DFB2B448A73EC00E5DA0EE63CA084@logos.inhouse.broadjump.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <97B71B827DFB2B448A73EC00E5DA0EE63CA084@logos.inhouse.broadjump.com>; from dcramer@broadjump.com on Tue, Sep 10, 2002 at 01:24:18PM -0500 Subject: [xslt] Re: [xml] periods legal in an NMTOKEN Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Tue, Sep 10, 2002 at 01:24:18PM -0500, David Cramer wrote: > We have a dtd with attributes defined as NMTOKEN. When the attribute > values have periods in them, we get the error: > > "validity error: standalone: foo on bar value had to be normalized based > on external subset declaration" > > Our processing system is designed to die on the word error (some other > xsl processors aren't so nice with their exit codes). If I change > NMTOKEN to CDATA in the DTD, we no longer get the error but that causes > other problems. > > Looking at the spec, I think periods should be ok in an NMTOKEN: > > http://www.w3c.org/TR/2000/REC-xml-20001006#NT-Nmtoken Right, give me a sample test case according to http://xmlsoft.org/bugs.html Then I will look into it, thanks, 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/ From dcramer@broadjump.com Wed Sep 11 18:19:56 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from macross.inhouse.broadjump.com (ns.broadjump.com [12.39.176.252]) by mail.gnome.org (Postfix) with ESMTP id 39154181E8; Wed, 11 Sep 2002 18:19:56 -0400 (EDT) Received: from logos.inhouse.broadjump.com (logos.inhouse.broadjump.com [10.64.3.15]) by macross.inhouse.broadjump.com (8.12.2/8.12.2) with ESMTP id g8BMJsdn013417; Wed, 11 Sep 2002 17:19:54 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Sep 2002 17:19:54 -0500 Message-ID: <97B71B827DFB2B448A73EC00E5DA0EE63CA087@logos.inhouse.broadjump.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [xml] periods legal in an NMTOKEN Thread-Index: AcJZERk5rcZagEgQRHqc6YRWKmu8AwAJiNfA From: "David Cramer" To: Cc: , X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Subject: [xslt] RE: [xml] periods legal in an NMTOKEN Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Sigh. I prepared a small test case and xsltproc does fine with NMTOKENs. Apparently it's something else--either a bug in our xsl that Saxon misses or a bug in xsltproc that our stuff reveals. I'll try to get a test case that's small enough to be useful.=20 Any chance there's a hidden --quiet switch on xsltproc? It processes the document fine, despite its complaints.=20 Thanks, David -----Original Message----- From: Daniel Veillard [mailto:veillard@redhat.com] Sent: Tuesday, September 10, 2002 4:29 PM To: David Cramer Cc: xslt@gnome.org; xml@gnome.org Subject: Re: [xml] periods legal in an NMTOKEN On Tue, Sep 10, 2002 at 01:24:18PM -0500, David Cramer wrote: > We have a dtd with attributes defined as NMTOKEN. When the attribute > values have periods in them, we get the error: >=20 > "validity error: standalone: foo on bar value had to be normalized based > on external subset declaration" >=20 > Our processing system is designed to die on the word error (some other > xsl processors aren't so nice with their exit codes). If I change > NMTOKEN to CDATA in the DTD, we no longer get the error but that causes > other problems.=20 >=20 > Looking at the spec, I think periods should be ok in an NMTOKEN: >=20 > http://www.w3c.org/TR/2000/REC-xml-20001006#NT-Nmtoken Right, give me a sample test case according to http://xmlsoft.org/bugs.html Then I will look into it, thanks, Daniel --=20 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/ From veillard@redhat.com Wed Sep 11 18:25:23 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 5738C18D1E; Wed, 11 Sep 2002 18:25:23 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8BMPGH29603; Wed, 11 Sep 2002 18:25:16 -0400 Date: Wed, 11 Sep 2002 18:25:16 -0400 From: Daniel Veillard To: David Cramer Cc: xslt@gnome.org, xml@gnome.org Message-ID: <20020911182516.H9261@redhat.com> References: <97B71B827DFB2B448A73EC00E5DA0EE63CA087@logos.inhouse.broadjump.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <97B71B827DFB2B448A73EC00E5DA0EE63CA087@logos.inhouse.broadjump.com>; from dcramer@broadjump.com on Wed, Sep 11, 2002 at 05:19:54PM -0500 Subject: [xslt] Re: [xml] periods legal in an NMTOKEN Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Wed, Sep 11, 2002 at 05:19:54PM -0500, David Cramer wrote: > Sigh. I prepared a small test case and xsltproc does fine with NMTOKENs. > Apparently it's something else--either a bug in our xsl that Saxon > misses or a bug in xsltproc that our stuff reveals. I'll try to get a > test case that's small enough to be useful. > > Any chance there's a hidden --quiet switch on xsltproc? It processes the > document fine, despite its complaints. Well, the problem is that xsltproc does *not* do validity checks like the message you seems to report. It loads the DTD in order to expands entities and defaulted attributes but does not do checks or report them, so the message seems issued by your stylesheets actually. Why, I have no idea ... Run xsltproc with the -v verbose mode and save the stderr output on a file, you should be able to spot where the message get issued and debug your problem. 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/ From dcramer@broadjump.com Thu Sep 12 00:08:43 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from macross.inhouse.broadjump.com (ns.broadjump.com [12.39.176.252]) by mail.gnome.org (Postfix) with ESMTP id 4820218153; Thu, 12 Sep 2002 00:08:43 -0400 (EDT) Received: from logos.inhouse.broadjump.com (logos.inhouse.broadjump.com [10.64.3.15]) by macross.inhouse.broadjump.com (8.12.2/8.12.2) with ESMTP id g8C48fdn016044; Wed, 11 Sep 2002 23:08:41 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Sep 2002 23:08:41 -0500 Message-ID: <97B71B827DFB2B448A73EC00E5DA0EE63CA093@logos.inhouse.broadjump.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [xml] periods legal in an NMTOKEN Thread-Index: AcJZ4h7NIVXb0wwLQiS8BqGg1QFqOQAI1yyA From: "David Cramer" To: Cc: , X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Subject: [xslt] RE: [xml] periods legal in an NMTOKEN Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: You aren't kidding when you say verbose. I guess it normally is quite by contrast :) Turns out xsltproc is correct--I was feeding it some questionable xml in the form: attr=3D"foo " (where attr is an NMTOKEN). Not sure if it is strictly a 'validity error'; nsgmls doesn't complain about it.=20 I promise that the message I mentioned isn't coming from an xsl:message tho. Maybe some of the code is doing more than you think? Total processing time (including a fo renderer and ghostscript) for one of our larger docs: xsltproc: 681 seconds =20 Saxon: 580 seconds =20 That surprises me--I'd expected xsltproc to be faster. Maybe I can do some profiling to figure out where the expensive stuff is in any case. Btw., these are docbook documents, preprocessed extensively, then run through the docbook xsls (v. 1.50.0 + our customizations). Other interesting differences: * Saxon outputs things like — as unicode characters, while xsltproc leaves them as numeric entity references: e.g. ­. * Saxon sorts AaBbCc, xsltproc sorts ABC.. abc... There are other differences--I can tell because of pagination differences, but I haven't figured out where they are yet. In the fo I can see that generated id values are different and the order of attributes is different--other things are harder to make out in the sea of tags and line break differences.=20 Thanks for your help, David > -----Original Message----- > From: Daniel Veillard [mailto:veillard@redhat.com] > Sent: Wednesday, September 11, 2002 5:25 PM > To: David Cramer > Cc: xslt@gnome.org; xml@gnome.org > Subject: Re: [xml] periods legal in an NMTOKEN >=20 >=20 > On Wed, Sep 11, 2002 at 05:19:54PM -0500, David Cramer wrote: > > Sigh. I prepared a small test case and xsltproc does fine=20 > with NMTOKENs. > > Apparently it's something else--either a bug in our xsl that Saxon > > misses or a bug in xsltproc that our stuff reveals. I'll=20 > try to get a > > test case that's small enough to be useful.=20 > >=20 > > Any chance there's a hidden --quiet switch on xsltproc? It=20 > processes the > > document fine, despite its complaints.=20 >=20 > Well, the problem is that xsltproc does *not* do validity > checks like the message you seems to report. It loads the DTD > in order to expands entities and defaulted attributes but does > not do checks or report them, so the message seems issued by > your stylesheets actually. Why, I have no idea ... > Run xsltproc with the -v verbose mode and save the stderr > output on a file, you should be able to spot where the message get > issued and debug your problem. >=20 > Daniel From wbrack@mmm.com.hk Thu Sep 12 02:19:00 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from delightful.com.hk (adsl-63-204-84-206.dsl.sktn01.pacbell.net [63.204.84.206]) by mail.gnome.org (Postfix) with ESMTP id 1417918280 for ; Thu, 12 Sep 2002 02:18:59 -0400 (EDT) Received: from delightful.com.hk (localhost [127.0.0.1]) by delightful.com.hk (8.12.5/8.12.4) with SMTP id g8C6JQlW019715 for ; Thu, 12 Sep 2002 06:19:26 GMT Received: from 202.73.253.3 (SquirrelMail authenticated user wbrack) by delightful.com.hk with HTTP; Thu, 12 Sep 2002 14:19:26 +0800 (HKT) Message-ID: <1229.202.73.253.3.1031811566.squirrel@delightful.com.hk> Date: Thu, 12 Sep 2002 14:19:26 +0800 (HKT) Subject: Re: [xslt] RE: [xml] periods legal in an NMTOKEN From: "William M. Brack" To: In-Reply-To: <97B71B827DFB2B448A73EC00E5DA0EE63CA093@logos.inhouse.broadjump.com> References: <97B71B827DFB2B448A73EC00E5DA0EE63CA093@logos.inhouse.broadjump.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.7) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: >> Well, the problem is that xsltproc does *not* do validity >> checks like the message you seems to report. It loads the DTD >> in order to expands entities and defaulted attributes but does >> not do checks or report them, so the message seems issued by >> your stylesheets actually. Why, I have no idea ... FWIW the reported message is coming from libxml2's valid.c, line 3118 (in the routine xmlValidCtxtNormalizeAttributeValue). According to my understanding of the logic preceding the message (as well as comments at the beginning of the routine), the "deep inner significance" is that an attribute value contains 1) a leading space 2) more than one consecutive embedded spaces or 3) one or more trailing spaces. Not directly related to "periods", however.... From wesley@terpstra.ca Fri Sep 13 06:28:53 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from bagofholding.com (unknown [24.83.204.254]) by mail.gnome.org (Postfix) with ESMTP id 072AA1819A for ; Fri, 13 Sep 2002 06:28:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bagofholding.com (Postfix) with ESMTP id DC77E90322; Fri, 13 Sep 2002 03:28:52 -0700 (PDT) Received: from maul.vpn (localhost [127.0.0.1]) by bagofholding.com (Postfix) with ESMTP id C23369001F; Fri, 13 Sep 2002 03:28:50 -0700 (PDT) Received: from terpstra by maul.vpn with local (Exim 3.35 #1 (Debian)) id 17pngu-0000r5-00; Fri, 13 Sep 2002 12:28:48 +0200 Date: Fri, 13 Sep 2002 12:28:48 +0200 To: xslt@gnome.org Cc: Daniel Veillard , Andy Hird Subject: Re: [xslt] libxslt escaping urls when outputting HTML Message-ID: <20020913102848.GA3216@maul.vpn> References: <002401c2556a$74e05b30$5209a8c0@andyhirdlaptop> <20020906054604.A25901@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20020906054604.A25901@redhat.com> User-Agent: Mutt/1.3.28i From: "Wesley W. Terpstra" X-Virus-Scanned: by AMaViS new-20020517 X-Razor-id: dbff479ac5b7abc97c93a6010f30ca12b234ca59 X-Spam-Status: No Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Fri, Sep 06, 2002 at 05:46:04AM -0400, Daniel Veillard wrote: > On Fri, Sep 06, 2002 at 03:58:38PM +1000, Andy Hird wrote: > [...] > > and with version 1.18 (and version 1.20 I just tested) we get: > >=20 > > test > >=20 > >=20 > > I know that they are, in essence, the same thing but unfortunately we > > have some software relying on the former output (which we will fix).=20 > >=20 > > I was curious what prompted the change in libxslt and whether there was > > a way (within the xslt) of changing that escaping for the whole document > > (rather than using xsl:text elements with escape exceptions). >=20 > The reason is simple: standard conformance > http://www.w3.org/TR/xslt#section-HTML-Output-Method >=20 > "The html output method should escape non-ASCII characters in URI > attribute values using the method recommended in Section B.2.1 of > the HTML 4.0 Recommendation." Uhm, forgive me if I am mistaken, but isn't "," an ASCII character? So "should escape _non_-ASCII characters" does not apply? I read this part of the specification to be refering to utf-8, but non-asciii characters...=20 So, a german umlaut would be utf-8->uri encoded, but a comma should not? > However considering the complexity of the issue, maybe it's a good thing= =20 > to not rely on the former output anyway, and there isn't a way to avoid t= he > escaping (even the xsl:text trick won't work in that case, the URI serial= izer > won't look at this, the escaping disabling wasn't intended for this). There is supposed to be an parameter to the xsl:output element in XSL 2.0 to turn this off as well, but I don't think it was in 1.0? Again, though, I believe this is only supposed to apply to non-ascii utf-8 characters... I personally think the specification needs to make this section clearer and simpler: this is really important for those of us who actually deal with full scale utf-8 in uri POST elements or other non-html specific locations... Later. --=20 Wesley W. Terpstra From veillard@redhat.com Fri Sep 13 06:51:34 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 6DB811819A for ; Fri, 13 Sep 2002 06:51:34 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8DApWs05671; Fri, 13 Sep 2002 06:51:32 -0400 Date: Fri, 13 Sep 2002 06:51:32 -0400 From: Daniel Veillard To: "Wesley W. Terpstra" Cc: xslt@gnome.org, Andy Hird Subject: Re: [xslt] libxslt escaping urls when outputting HTML Message-ID: <20020913065132.H27778@redhat.com> References: <002401c2556a$74e05b30$5209a8c0@andyhirdlaptop> <20020906054604.A25901@redhat.com> <20020913102848.GA3216@maul.vpn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020913102848.GA3216@maul.vpn>; from wesley@terpstra.ca on Fri, Sep 13, 2002 at 12:28:48PM +0200 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Fri, Sep 13, 2002 at 12:28:48PM +0200, Wesley W. Terpstra wrote: > On Fri, Sep 06, 2002 at 05:46:04AM -0400, Daniel Veillard wrote: > > On Fri, Sep 06, 2002 at 03:58:38PM +1000, Andy Hird wrote: > > [...] > > > and with version 1.18 (and version 1.20 I just tested) we get: > > > > > > test > > > > > > > > > I know that they are, in essence, the same thing but unfortunately we > > > have some software relying on the former output (which we will fix). > > > > > > I was curious what prompted the change in libxslt and whether there was > > > a way (within the xslt) of changing that escaping for the whole document > > > (rather than using xsl:text elements with escape exceptions). > > > > The reason is simple: standard conformance > > http://www.w3.org/TR/xslt#section-HTML-Output-Method > > > > "The html output method should escape non-ASCII characters in URI > > attribute values using the method recommended in Section B.2.1 of > > the HTML 4.0 Recommendation." > > Uhm, forgive me if I am mistaken, but isn't "," an ASCII character? Hum, maybe it wasn't precisely the right thing to point to, but RFC 2396 is the core spec in this respect. And ',' is in the reserved set. > There is supposed to be an parameter to the xsl:output element in XSL 2.0 to > turn this off as well, but I don't think it was in 1.0? no idea and I don't try to be XSLT-2.0 compliant... it requires XPath 2.0 which itself requires XML Schemas ... maybe in a couple of years !!! > Again, though, I believe this is only supposed to apply to non-ascii utf-8 > characters... I personally think the specification needs to make this the rules from RFC 2396 are very general, they apply in the HTML framework ! > section clearer and simpler: this is really important for those of us who > actually deal with full scale utf-8 in uri POST elements or other non-html > specific locations... I'm not involved anymore in this level of the standards, and I don't think there will be a new revision of the SGML based HTML specification ... 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/ From pj@walter-graphtek.com Fri Sep 13 07:33:24 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from jessenlenz.com (mail.jessenlenz.com [212.79.192.34]) by mail.gnome.org (Postfix) with ESMTP id 9E047184F7 for ; Fri, 13 Sep 2002 07:33:23 -0400 (EDT) Received: from SOFTDEV8 (217.227.29.192) by jessenlenz.com with ESMTP (Eudora Internet Mail Server 3.1.3); Fri, 13 Sep 2002 14:35:16 +0200 From: "Peter Jacobi" To: Daniel Veillard Date: Fri, 13 Sep 2002 13:36:45 +0200 MIME-Version: 1.0 Subject: Re: [xslt] libxslt escaping urls when outputting HTML Cc: xslt@gnome.org, Andy Hird Message-ID: <3D81E9ED.396.10A270B@localhost> Priority: normal In-reply-to: <20020913065132.H27778@redhat.com> References: <20020913102848.GA3216@maul.vpn>; from wesley@terpstra.ca on Fri, Sep 13, 2002 at 12:28:48PM +0200 X-mailer: Pegasus Mail for Windows (v4.02) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Hi Daniel, I'm disagreeing with you in this case. > > Uhm, forgive me if I am mistaken, but isn't "," an ASCII character? > > Hum, maybe it wasn't precisely the right thing to point to, but > RFC 2396 is the core spec in this respect. And ',' is in the reserved set. > Characters in the reserved set may occur in a RFC2396 URI and in fact an URI changes meaning, whether it is escaped or not, so it's not good to always escape them. The application generating the URI must have some clue whether one particular ',' needs escaping or not. Characters in the excluded set must always be escaped. Regards, Peter Jacobi From veillard@redhat.com Fri Sep 13 08:14:11 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 6ED141879D for ; Fri, 13 Sep 2002 08:14:11 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8DCE6903366; Fri, 13 Sep 2002 08:14:06 -0400 Date: Fri, 13 Sep 2002 08:14:06 -0400 From: Daniel Veillard To: Peter Jacobi Cc: xslt@gnome.org, Andy Hird Subject: Re: [xslt] libxslt escaping urls when outputting HTML Message-ID: <20020913081406.I27778@redhat.com> References: <20020913102848.GA3216@maul.vpn>; <20020913065132.H27778@redhat.com> <3D81E9ED.396.10A270B@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D81E9ED.396.10A270B@localhost>; from pj@walter-graphtek.com on Fri, Sep 13, 2002 at 01:36:45PM +0200 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Fri, Sep 13, 2002 at 01:36:45PM +0200, Peter Jacobi wrote: > Hi Daniel, > > I'm disagreeing with you in this case. Hum, I'm not sure. > > > Uhm, forgive me if I am mistaken, but isn't "," an ASCII character? > > > > Hum, maybe it wasn't precisely the right thing to point to, but > > RFC 2396 is the core spec in this respect. And ',' is in the reserved set. > > > > Characters in the reserved set may occur in a RFC2396 URI > and in fact an URI changes meaning, whether it is escaped or not, > so it's not good to always escape them. reread what I said in my first answer ... It depends on the context and in the specific case he pointed out this might not have been escaped. but to not rely on it being left as-is. > The application generating the URI must have some clue whether > one particular ',' needs escaping or not. Yes, depends on the part of the URI where it is present. 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/ From jta@bristowhill.com Sat Sep 14 11:22:14 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from smtp2.san.rr.com (smtp2.san.rr.com [24.25.195.39]) by mail.gnome.org (Postfix) with ESMTP id 88EF9180F4 for ; Sat, 14 Sep 2002 11:22:13 -0400 (EDT) Received: from bristowhill.com (dt089n06.san.rr.com [204.210.25.6]) by smtp2.san.rr.com (8.11.4/8.11.4) with ESMTP id g8EFMCL24242 for ; Sat, 14 Sep 2002 08:22:12 -0700 (PDT) Message-ID: <3D8353DC.60703@bristowhill.com> Date: Sat, 14 Sep 2002 08:21:00 -0700 From: "Jean T. Anderson" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xslt@gnome.org Subject: [xslt] Is the xsltproc --warnnet option implemented? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: I'm using libxslt-1.0.20. http://xmlsoft.org/XSLT/xsltproc2.html mentions an xsltproc --warnnet option, but I don't spot how that option gets supported in xsltproc.c (or elsewhere in libxslt). Did this option get implemented? or did it perhaps slip through the cracks? regards, -jean Jean T. Anderson jta@bristowhill.com From jfleck@inkstain.net Sat Sep 14 17:54:57 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from taka.swcp.com (taka.swcp.com [198.59.115.12]) by mail.gnome.org (Postfix) with ESMTP id 5AE9418169 for ; Sat, 14 Sep 2002 17:54:57 -0400 (EDT) Received: from [10.0.0.3] ([216.184.14.36]) by taka.swcp.com (8.12.3/8.12.3) with ESMTP id g8ELsq6q097354 for ; Sat, 14 Sep 2002 15:54:53 -0600 (MDT) Subject: Re: [xslt] Is the xsltproc --warnnet option implemented? From: John Fleck To: xslt@gnome.org In-Reply-To: <3D8353DC.60703@bristowhill.com> References: <3D8353DC.60703@bristowhill.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 14 Sep 2002 15:54:47 -0600 Message-Id: <1032040493.1138.2.camel@jelloiii> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.5 required=10.0 tests=IN_REP_TO,REFERENCES X-Spam-Level: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Sat, 2002-09-14 at 09:21, Jean T. Anderson wrote: > I'm using libxslt-1.0.20. > > http://xmlsoft.org/XSLT/xsltproc2.html mentions an xsltproc --warnnet > option, but I don't spot how that option gets supported in xsltproc.c > (or elsewhere in libxslt). > > Did this option get implemented? or did it perhaps slip through the cracks? > Daniel removed that last year: Wed Oct 31 18:53:26 CET 2001 Daniel Veillard * xsltproc/xsltproc.c: cleanup, moved xsllNoNetExternalEntityLoader() to libxml and removed the --warnnet option Dunno why, but I guess we need to update the documentation. Cheers, John -- John Fleck jfleck@inkstain.net (h) jfleck@abqjournal.com (w) http://www.inkstain.net http://www.abqjournal.com "Sometimes, a diner is all about the mac and cheese." - Zippy the Pinhead From philipp@dunkel.org Mon Sep 16 05:36:37 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from ei.epochales.com (1gbit.gateway.viennatec.com [80.64.130.177]) by mail.gnome.org (Postfix) with SMTP id 3072C18A5A for ; Mon, 16 Sep 2002 05:36:37 -0400 (EDT) Received: (qmail 25829 invoked from network); 16 Sep 2002 09:36:27 -0000 Received: from unknown (HELO ?192.168.1.6?) (212.17.81.60) by res.epochales.com with SMTP; 16 Sep 2002 09:36:27 -0000 Subject: Re: [xslt] libxslt escaping urls when outputting HTML From: Philipp Dunkel To: xslt@gnome.org In-Reply-To: <20020913081406.I27778@redhat.com> References: <20020913102848.GA3216@maul.vpn>; <20020913065132.H27778@redhat.com> <3D81E9ED.396.10A270B@localhost> <20020913081406.I27778@redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 16 Sep 2002 11:36:27 +0200 Message-Id: <1032168987.21780.17.camel@stationary.home.dunkel.org> Mime-Version: 1.0 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: If you remember we had this discussion about a month ago as well. Back then I gave up. I just wanted you to think about one thing: Invention is using things that exist in a totally unpredicted new way. There seem to be a lot of people having troubles with URL-escaping, some of them resorting to patching libxslt (I did for my own use, but did not distribute since I don't want to fork or even put down your great work, especially since in terms of experience and knowledge your are by far the better programmer). Now This part of libxslt is not really that much of a core functionality, that it really matters that much. And the behavior that is currently there is absolutely the right thing as a default. But if it's not really a core issue, why not make it a runtime option. I could, during initialization just call IllegalEscaping(1); and the URL-escaping would be turned of and left up to me to do within the XSL. I need it and modified libxslt according to my needs, but is that the right way to do things for an issue like that? I don't think so. So why not take a more practical approach and make this change choosable at init-time. It would eliminate this discussion and make everyone happy: A standards compliant parser by default. WIth some neat extras if you really need them for a specific instance. Now this is just a thought, and I presume you have had it before.Non the less, I would be quite interrested in hearing your reasoning about why not to follow a path like that. TTY Philipp On Fri, 2002-09-13 at 14:14, Daniel Veillard wrote: > On Fri, Sep 13, 2002 at 01:36:45PM +0200, Peter Jacobi wrote: > > Hi Daniel, > > > > I'm disagreeing with you in this case. > > Hum, I'm not sure. > > > > > Uhm, forgive me if I am mistaken, but isn't "," an ASCII character? > > > > > > Hum, maybe it wasn't precisely the right thing to point to, but > > > RFC 2396 is the core spec in this respect. And ',' is in the reserved set. > > > > > > > Characters in the reserved set may occur in a RFC2396 URI > > and in fact an URI changes meaning, whether it is escaped or not, > > so it's not good to always escape them. > > reread what I said in my first answer ... It depends on the context > and in the specific case he pointed out this might not have been escaped. > but to not rely on it being left as-is. > > > The application generating the URI must have some clue whether > > one particular ',' needs escaping or not. > > Yes, depends on the part of the URI where it is present. > > 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/ > _______________________________________________ > xslt mailing list, project page http://xmlsoft.org/XSLT/ > xslt@gnome.org > http://mail.gnome.org/mailman/listinfo/xslt From veillard@redhat.com Mon Sep 16 05:56:35 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id A4A4B18404 for ; Mon, 16 Sep 2002 05:56:35 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8G9uZO05680 for xslt@gnome.org; Mon, 16 Sep 2002 05:56:35 -0400 Date: Mon, 16 Sep 2002 05:56:35 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] libxslt escaping urls when outputting HTML Message-ID: <20020916055635.M27778@redhat.com> References: <20020913102848.GA3216@maul.vpn>; <20020913065132.H27778@redhat.com> <3D81E9ED.396.10A270B@localhost> <20020913081406.I27778@redhat.com> <1032168987.21780.17.camel@stationary.home.dunkel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1032168987.21780.17.camel@stationary.home.dunkel.org>; from philipp@dunkel.org on Mon, Sep 16, 2002 at 11:36:27AM +0200 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Mon, Sep 16, 2002 at 11:36:27AM +0200, Philipp Dunkel wrote: > If you remember we had this discussion about a month ago as well. Back > then I gave up. > I just wanted you to think about one thing: > Invention is using things that exist in a totally unpredicted new way. > There seem to be a lot of people having troubles with URL-escaping, some > of them resorting to patching libxslt (I did for my own use, but did not > distribute since I don't want to fork or even put down your great work, > especially since in terms of experience and knowledge your are by far > the better programmer). Now This part of libxslt is not really that much > of a core functionality, that it really matters that much. And the > behavior that is currently there is absolutely the right thing as a > default. But if it's not really a core issue, why not make it a runtime > option. I could, during initialization just call IllegalEscaping(1); and > the URL-escaping would be turned of and left up to me to do within the > XSL. > I need it and modified libxslt according to my needs, but is that the > right way to do things for an issue like that? I don't think so. So why > not take a more practical approach and make this change choosable at > init-time. It would eliminate this discussion and make everyone happy: A > standards compliant parser by default. WIth some neat extras if you > really need them for a specific instance. > Now this is just a thought, and I presume you have had it before.Non the > less, I would be quite interrested in hearing your reasoning about why > not to follow a path like that. Basically the problems are: - one more API changing the behaviour of the framework - one more global variable, which I try to chase down to the minimum Of course it would be an "easy" solution, I would just prefer an "exact" solution. Now I'm not 100% opposed to doing it, just reluctant ... Apparently people have had troubles w.r.t. URI escaping in XSLT framework, like it appears new APIs are being added to XPath-2.0 and/or XQuery 2.0. If someone could do the research to what those may need in the future and suggest a solution which would be ready for the long term I would feel very inclined to apply/implement/follow it :-) 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/ From rm@mh-freiburg.de Mon Sep 16 12:17:28 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from forte.mh-freiburg.de (mail.mh-freiburg.de [193.197.131.2]) by mail.gnome.org (Postfix) with ESMTP id E69881869E for ; Mon, 16 Sep 2002 12:17:27 -0400 (EDT) Received: by forte.mh-freiburg.de (Postfix, from userid 104) id 4DED81B32F2; Mon, 16 Sep 2002 18:16:55 +0200 (MEST) Date: Mon, 16 Sep 2002 18:16:54 +0200 To: xslt@gnome.org Subject: Re: [xslt] libxslt escaping urls when outputting HTML Message-ID: <20020916181654.B13904@forte.mh-freiburg.de> References: <20020913102848.GA3216@maul.vpn>; <20020913065132.H27778@redhat.com> <3D81E9ED.396.10A270B@localhost> <20020913081406.I27778@redhat.com> <1032168987.21780.17.camel@stationary.home.dunkel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <1032168987.21780.17.camel@stationary.home.dunkel.org>; from philipp@dunkel.org on Mon, Sep 16, 2002 at 11:36:27AM +0200 From: rm@mh-freiburg.de (Le grande pinguin) Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Mon, Sep 16, 2002 at 11:36:27AM +0200, Philipp Dunkel wrote: > If you remember we had this discussion about a month ago as well. Back > then I gave up. > I just wanted you to think about one thing: > Invention is using things that exist in a totally unpredicted new way. > There seem to be a lot of people having troubles with URL-escaping, some > of them resorting to patching libxslt (I did for my own use, but did not > distribute since I don't want to fork or even put down your great work, > especially since in terms of experience and knowledge your are by far > the better programmer). Now This part of libxslt is not really that much > of a core functionality, that it really matters that much. This is a dangerous statement, to say the least. If it doesn't break _your_ code this doen't mean it doesn't break someones carefully crafted standard conformant code somewhere (no, not mine, i case you ask :) > And the > behavior that is currently there is absolutely the right thing as a > default. But if it's not really a core issue, why not make it a runtime > option. I could, during initialization just call IllegalEscaping(1); and > the URL-escaping would be turned of and left up to me to do within the > XSL. Please, _no_ more globals! If you use libxml in an environment where the library might be needed by several components of an application (webserver with loadable modules, for example) this setup is asking for trouble. Imagine module A loading libxml and setting IllegalEscaping to true. Then, at some point some serveradmin installs module B which happens to set IllegalEscaping to false, and all a sudden module A stops working the way it used to ... > I need it and modified libxslt according to my needs, but is that the > right way to do things for an issue like that? I don't think so. So why > not take a more practical approach and make this change choosable at > init-time. It would eliminate this discussion and make everyone happy: A > standards compliant parser by default. WIth some neat extras if you > really need them for a specific instance. > Now this is just a thought, and I presume you have had it before.Non the > less, I would be quite interrested in hearing your reasoning about why > not to follow a path like that. > Well, the two possible solutions is see are: - since this is a problem of serialisation, why not modify the serialisation code? Write your own (copying Daniels html- serializer) version that does the wanted escaping. - Create an xslt extension function and use it in your transformation: My link Ralf Mattes From jta@bristowhill.com Mon Sep 16 13:51:19 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from smtp2.san.rr.com (smtp2.san.rr.com [24.25.195.39]) by mail.gnome.org (Postfix) with ESMTP id DADAB18B9B for ; Mon, 16 Sep 2002 13:51:18 -0400 (EDT) Received: from bristowhill.com (dt089n06.san.rr.com [204.210.25.6]) by smtp2.san.rr.com (8.11.4/8.11.4) with ESMTP id g8GHpHi18752 for ; Mon, 16 Sep 2002 10:51:17 -0700 (PDT) Message-ID: <3D8619C8.9050401@bristowhill.com> Date: Mon, 16 Sep 2002 10:50:00 -0700 From: "Jean T. Anderson" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xslt@gnome.org Subject: Re: [xslt] libxslt escaping urls when outputting HTML References: <20020913102848.GA3216@maul.vpn>; <20020913065132.H27778@redhat.com> <3D81E9ED.396.10A270B@localhost> <20020913081406.I27778@redhat.com> <1032168987.21780.17.camel@stationary.home.dunkel.org> <20020916181654.B13904@forte.mh-freiburg.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Le grande pinguin wrote: >On Mon, Sep 16, 2002 at 11:36:27AM +0200, Philipp Dunkel wrote: > >>And the >>behavior that is currently there is absolutely the right thing as a >>default. But if it's not really a core issue, why not make it a runtime >>option. I could, during initialization just call IllegalEscaping(1); and >>the URL-escaping would be turned of and left up to me to do within the >>XSL. >> > >Please, _no_ more globals! If you use libxml in an environment where >the library might be needed by several components of an application >(webserver with loadable modules, for example) this setup is asking >for trouble. Imagine module A loading libxml and setting IllegalEscaping to >true. Then, at some point some serveradmin installs module B which happens >to set IllegalEscaping to false, and all a sudden module A stops working >the way it used to ... > I'm just a wee libxslt newbie with about 3 weeks experience, but I'll second this motion. I'm working on integrating libxslt into a shared library and providing some support for xsltproc options. I'm having to create two distinct processes for executing requests: one for xsltproc options that get set at the thread level, such as --param, and another for options that get set at the global level, such as --verbose, --maxdepth, --nonet, and --novalid. (The fact that memory allocation routines and error handlers also get registered at the process level instead of the thread level aren't a problem for this particular application.) It's threads like this one on escaping urls that remind me that I am far from having a handle on all the globals that are out there. -jean Jean T. Anderson From veillard@redhat.com Mon Sep 16 14:58:43 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 582EF18BE2 for ; Mon, 16 Sep 2002 14:58:43 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8GIwhb23335 for xslt@gnome.org; Mon, 16 Sep 2002 14:58:43 -0400 Date: Mon, 16 Sep 2002 14:58:42 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] libxslt escaping urls when outputting HTML Message-ID: <20020916145842.P27778@redhat.com> References: <20020913102848.GA3216@maul.vpn>; <20020913065132.H27778@redhat.com> <3D81E9ED.396.10A270B@localhost> <20020913081406.I27778@redhat.com> <1032168987.21780.17.camel@stationary.home.dunkel.org> <20020916181654.B13904@forte.mh-freiburg.de> <3D8619C8.9050401@bristowhill.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D8619C8.9050401@bristowhill.com>; from jta@bristowhill.com on Mon, Sep 16, 2002 at 10:50:00AM -0700 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Mon, Sep 16, 2002 at 10:50:00AM -0700, Jean T. Anderson wrote: > I'm working on integrating libxslt into a shared library and providing > some support for xsltproc options. I'm having to create two distinct > processes for executing requests: one for xsltproc options that get set > at the thread level, such as --param, and another for options that get > set at the global level, such as --verbose, --maxdepth, --nonet, and > --novalid. (The fact that memory allocation routines and error handlers > also get registered at the process level instead of the thread level > aren't a problem for this particular application.) > > It's threads like this one on escaping urls that remind me that I am far > from having a handle on all the globals that are out there. Just to be sure: you have checked include/libxml/globals.h include/libxml/threads.h and http://xmlsoft.org/threads.html I assume that yes, but just in case :-) 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/ From jta@bristowhill.com Mon Sep 16 15:29:13 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from smtp1.san.rr.com (smtp1.san.rr.com [24.25.195.37]) by mail.gnome.org (Postfix) with ESMTP id 12568188D0 for ; Mon, 16 Sep 2002 15:29:13 -0400 (EDT) Received: from bristowhill.com (dt089n06.san.rr.com [204.210.25.6]) by smtp1.san.rr.com (8.11.4/8.11.4) with ESMTP id g8GJTBl07993 for ; Mon, 16 Sep 2002 12:29:11 -0700 (PDT) Message-ID: <3D8630B9.7010502@bristowhill.com> Date: Mon, 16 Sep 2002 12:27:53 -0700 From: "Jean T. Anderson" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xslt@gnome.org Subject: Re: [xslt] libxslt escaping urls when outputting HTML References: <20020913102848.GA3216@maul.vpn>; <20020913065132.H27778@redhat.com> <3D81E9ED.396.10A270B@localhost> <20020913081406.I27778@redhat.com> <1032168987.21780.17.camel@stationary.home.dunkel.org> <20020916181654.B13904@forte.mh-freiburg.de> <3D8619C8.9050401@bristowhill.com> <20020916145842.P27778@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Daniel Veillard wrote: >On Mon, Sep 16, 2002 at 10:50:00AM -0700, Jean T. Anderson wrote: > >>I'm working on integrating libxslt into a shared library and providing >>some support for xsltproc options. I'm having to create two distinct >>processes for executing requests: one for xsltproc options that get set >>at the thread level, such as --param, and another for options that get >>set at the global level, such as --verbose, --maxdepth, --nonet, and >>--novalid. (The fact that memory allocation routines and error handlers >>also get registered at the process level instead of the thread level >>aren't a problem for this particular application.) >> >>It's threads like this one on escaping urls that remind me that I am far >>from having a handle on all the globals that are out there. >> > > Just to be sure: you have checked include/libxml/globals.h >include/libxml/threads.h and http://xmlsoft.org/threads.html > > I assume that yes, but just in case :-) > >Daniel > Yes, but never assume anything with newbies :-), and I'm configuring both libxml2 and libxslt with the '--with-threads --with-thread-alloc' options. In fact, I discovered that doing so consumes considerably less memory than running with the default configuration. For the one test I analyzed (the "Hello, World!" example from page 22 of Doug Tidwell's XSLT book), using the default lib configurations resulted in 446,153 bytes allocated, while using libs configured with the thread options resulted in only 84,791 bytes allocated. This seemed kind of surprising, but may make perfect sense to you all who have been working with this for so long. regards, -jean From philipp@dunkel.org Mon Sep 16 20:24:06 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from ei.epochales.com (1gbit.gateway.viennatec.com [80.64.130.177]) by mail.gnome.org (Postfix) with SMTP id 0384718575 for ; Mon, 16 Sep 2002 20:24:06 -0400 (EDT) Received: (qmail 19874 invoked from network); 17 Sep 2002 00:23:56 -0000 Received: from unknown (HELO ?192.168.1.6?) (80.110.102.69) by res.epochales.com with SMTP; 17 Sep 2002 00:23:56 -0000 Subject: Re: [xslt] libxslt escaping urls when outputting HTML From: Philipp Dunkel To: xslt@gnome.org In-Reply-To: <20020916181654.B13904@forte.mh-freiburg.de> References: <20020913102848.GA3216@maul.vpn>; <20020913065132.H27778@redhat.com> <3D81E9ED.396.10A270B@localhost> <20020913081406.I27778@redhat.com> <1032168987.21780.17.camel@stationary.home.dunkel.org> <20020916181654.B13904@forte.mh-freiburg.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 17 Sep 2002 02:23:55 +0200 Message-Id: <1032222235.4573.3.camel@stationary.home.dunkel.org> Mime-Version: 1.0 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Well without further ado, you are RIGHT! Well at least as globals go etc,etc... The point I was trying to make is simply: Different serialisation for html seems to be a common request. This request is always responded to with "That not standard" I think not standard is not an excuse because it hampers invention On the point of globals I have to agree and retract my solution. It's OK for me for the time being. This is the reason I didn't publish it. I had a feeling, that it was a horrible hack, and should not really be used. It was actually more of an experiment than anything useful. The serialisation idea sounds good. How about Just thinking out loud. This could be included without doing any harm, wouldn't cause any standards problem, since I think someone writing an xsl with an output method named like that will know that they are doing something quite unstandard. Well I play the though through and might act on it if I needit. Summary: It's not the topic I disagree on it's the "standard's respospne" I dislike. TTY Philipp P.S.: As always everyone is invited (and to some degree expected) to disagree with me, since I see this as a valuable way of learning (at least for me) On Mon, 2002-09-16 at 18:16, Le grande pinguin wrote: > On Mon, Sep 16, 2002 at 11:36:27AM +0200, Philipp Dunkel wrote: > > If you remember we had this discussion about a month ago as well. Back > > then I gave up. > > I just wanted you to think about one thing: > > Invention is using things that exist in a totally unpredicted new way. > > There seem to be a lot of people having troubles with URL-escaping, some > > of them resorting to patching libxslt (I did for my own use, but did not > > distribute since I don't want to fork or even put down your great work, > > especially since in terms of experience and knowledge your are by far > > the better programmer). Now This part of libxslt is not really that much > > of a core functionality, that it really matters that much. > > This is a dangerous statement, to say the least. If it doesn't break > _your_ code this doen't mean it doesn't break someones carefully > crafted standard conformant code somewhere (no, not mine, i case you > ask :) > > > And the > > behavior that is currently there is absolutely the right thing as a > > default. But if it's not really a core issue, why not make it a runtime > > option. I could, during initialization just call IllegalEscaping(1); and > > the URL-escaping would be turned of and left up to me to do within the > > XSL. > > Please, _no_ more globals! If you use libxml in an environment where > the library might be needed by several components of an application > (webserver with loadable modules, for example) this setup is asking > for trouble. Imagine module A loading libxml and setting IllegalEscaping to > true. Then, at some point some serveradmin installs module B which happens > to set IllegalEscaping to false, and all a sudden module A stops working > the way it used to ... > > > I need it and modified libxslt according to my needs, but is that the > > right way to do things for an issue like that? I don't think so. So why > > not take a more practical approach and make this change choosable at > > init-time. It would eliminate this discussion and make everyone happy: A > > standards compliant parser by default. WIth some neat extras if you > > really need them for a specific instance. > > Now this is just a thought, and I presume you have had it before.Non the > > less, I would be quite interrested in hearing your reasoning about why > > not to follow a path like that. > > > Well, the two possible solutions is see are: > > - since this is a problem of serialisation, why not modify the > serialisation code? Write your own (copying Daniels html- > serializer) version that does the wanted escaping. > > - Create an xslt extension function and use it in your transformation: > > My link > > > > Ralf Mattes > > _______________________________________________ > xslt mailing list, project page http://xmlsoft.org/XSLT/ > xslt@gnome.org > http://mail.gnome.org/mailman/listinfo/xslt From veillard@redhat.com Tue Sep 17 04:55:35 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 51E9A182D7 for ; Tue, 17 Sep 2002 04:55:34 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8H8tXN00478 for xslt@gnome.org; Tue, 17 Sep 2002 04:55:33 -0400 Date: Tue, 17 Sep 2002 04:55:33 -0400 From: Daniel Veillard To: xslt@gnome.org Message-ID: <20020917045533.T27778@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: [xslt] Troubles with the EXSLT date extensions Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Hi, seems some people are using them and are hitting a few bugs: http://bugzilla.gnome.org/show_bug.cgi?id=93444 http://bugzilla.gnome.org/show_bug.cgi?id=92818 Is there anybody on the list which could chase this down ? This should be self contained in the libexslt/date.c module, and not really requiring knowledge of libxslt internals. Any taker ? 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/ From rm@mh-freiburg.de Tue Sep 17 07:28:29 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from forte.mh-freiburg.de (mail.mh-freiburg.de [193.197.131.2]) by mail.gnome.org (Postfix) with ESMTP id EC6B318176 for ; Tue, 17 Sep 2002 07:28:28 -0400 (EDT) Received: by forte.mh-freiburg.de (Postfix, from userid 104) id 8AEA41B32F2; Tue, 17 Sep 2002 13:27:56 +0200 (MEST) Date: Tue, 17 Sep 2002 13:27:56 +0200 To: xslt@gnome.org Subject: Re: [xslt] libxslt escaping urls when outputting HTML Message-ID: <20020917132756.A24118@forte.mh-freiburg.de> References: <20020913102848.GA3216@maul.vpn>; <20020913065132.H27778@redhat.com> <3D81E9ED.396.10A270B@localhost> <20020913081406.I27778@redhat.com> <1032168987.21780.17.camel@stationary.home.dunkel.org> <20020916181654.B13904@forte.mh-freiburg.de> <1032222235.4573.3.camel@stationary.home.dunkel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <1032222235.4573.3.camel@stationary.home.dunkel.org>; from philipp@dunkel.org on Tue, Sep 17, 2002 at 02:23:55AM +0200 From: rm@mh-freiburg.de (Le grande pinguin) Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Tue, Sep 17, 2002 at 02:23:55AM +0200, Philipp Dunkel wrote: > > [...] > > Different serialisation for html seems to be a common request. > This request is always responded to with "That not standard" > I think not standard is not an excuse because it hampers invention > Well, i see the real-life problems as well (after all, i write software for webservers and i have seen the problems many browsers seem to have with "correct" output. > On the point of globals I have to agree and retract my solution. It's OK > for me for the time being. This is the reason I didn't publish it. I had > a feeling, that it was a horrible hack, and should not really be used. > It was actually more of an experiment than anything useful. > > The serialisation idea sounds good. How about method="html-with-illegal-hrefs"/> Yes, to me it looks like the cleanest solution -- unfortunately, after browsing the sources for a while i got the impression that it's not that trivial to extend the set of output methods. To me it looks like the existing methods are pretty much hardcoded into libxslt :-( As a long-term solution it might be interessting to have 'plugable' serializers, but otoh there might be little common code left to serialisation once you have plugins, so maybe you realy need to write your own serializer (the only benefit speaking for the plugin aproach would be the ability to set the serializer from within the stylesheet). > Just thinking out loud. This could be included without doing any harm, > wouldn't cause any standards problem, since I think someone writing an > xsl with an output method named like that will know that they are doing > something quite unstandard. > > Well I play the though through and might act on it if I needit. Lookin' forward to see the outcome ;-) Ralf > P.S.: As always everyone is invited (and to some degree expected) to > disagree with me, since I see this as a valuable way of learning (at > least for me) P.S.: i fully agree with that ;-) From veillard@redhat.com Tue Sep 17 07:41:53 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id C790618C68 for ; Tue, 17 Sep 2002 07:41:52 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8HBfqd12369 for xslt@gnome.org; Tue, 17 Sep 2002 07:41:52 -0400 Date: Tue, 17 Sep 2002 07:41:52 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] libxslt escaping urls when outputting HTML Message-ID: <20020917074152.V27778@redhat.com> References: <20020913102848.GA3216@maul.vpn>; <20020913065132.H27778@redhat.com> <3D81E9ED.396.10A270B@localhost> <20020913081406.I27778@redhat.com> <1032168987.21780.17.camel@stationary.home.dunkel.org> <20020916181654.B13904@forte.mh-freiburg.de> <1032222235.4573.3.camel@stationary.home.dunkel.org> <20020917132756.A24118@forte.mh-freiburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020917132756.A24118@forte.mh-freiburg.de>; from rm@mh-freiburg.de on Tue, Sep 17, 2002 at 01:27:56PM +0200 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Tue, Sep 17, 2002 at 01:27:56PM +0200, Le grande pinguin wrote: > On Tue, Sep 17, 2002 at 02:23:55AM +0200, Philipp Dunkel wrote: > > On the point of globals I have to agree and retract my solution. It's OK > > for me for the time being. This is the reason I didn't publish it. I had > > a feeling, that it was a horrible hack, and should not really be used. > > It was actually more of an experiment than anything useful. > > > > The serialisation idea sounds good. How about > method="html-with-illegal-hrefs"/> > > Yes, to me it looks like the cleanest solution -- unfortunately, after > browsing the sources for a while i got the impression that it's not that > trivial to extend the set of output methods. To me it looks like the > existing methods are pretty much hardcoded into libxslt :-( > yes they are hardcoded, because they are hardcoded in the specification, and if you want to provide your own serialization simply write your own version of xsltSaveResult... equivalent. > As a long-term solution it might be interessting to have 'plugable' serializers, > but otoh there might be little common code left to serialisation once you have > plugins, so maybe you realy need to write your own serializer (the only benefit > speaking for the plugin aproach would be the ability to set the serializer from > within the stylesheet). Right I could make it easy by providing an API for new serialization methods provided by the user code. > > Just thinking out loud. This could be included without doing any harm, > > wouldn't cause any standards problem, since I think someone writing an > > xsl with an output method named like that will know that they are doing > > something quite unstandard. > > > > Well I play the though through and might act on it if I needit. > > Lookin' forward to see the outcome ;-) The problem is that basically one need to duplicate the code of the HTML serializer, and this just for ensuring a "non conformant to the spec" behaviour that 99% of the users should not use. Understand it sounds like bloat to them ... the HTML serializer is part of libxml2, adding an xhtml serializer could be added reasonably but one just for not doing the processing that the HTML spec requires on URI-References when serializing, err it's just too much IMHO... 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/ From rm@mh-freiburg.de Tue Sep 17 08:00:34 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from forte.mh-freiburg.de (mail.mh-freiburg.de [193.197.131.2]) by mail.gnome.org (Postfix) with ESMTP id 41FE11827B for ; Tue, 17 Sep 2002 08:00:33 -0400 (EDT) Received: by forte.mh-freiburg.de (Postfix, from userid 104) id 546861B32F2; Tue, 17 Sep 2002 14:00:00 +0200 (MEST) Date: Tue, 17 Sep 2002 14:00:00 +0200 To: xslt@gnome.org Subject: Re: [xslt] libxslt escaping urls when outputting HTML# Message-ID: <20020917140000.B24118@forte.mh-freiburg.de> References: <20020913102848.GA3216@maul.vpn>; <20020913065132.H27778@redhat.com> <3D81E9ED.396.10A270B@localhost> <20020913081406.I27778@redhat.com> <1032168987.21780.17.camel@stationary.home.dunkel.org> <20020916181654.B13904@forte.mh-freiburg.de> <1032222235.4573.3.camel@stationary.home.dunkel.org> <20020917132756.A24118@forte.mh-freiburg.de> <20020917074152.V27778@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20020917074152.V27778@redhat.com>; from veillard@redhat.com on Tue, Sep 17, 2002 at 07:41:52AM -0400 From: rm@mh-freiburg.de (Le grande pinguin) Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Tue, Sep 17, 2002 at 07:41:52AM -0400, Daniel Veillard wrote: > > yes they are hardcoded, because they are hardcoded in the specification, > and if you want to provide your own serialization simply write your own > version of xsltSaveResult... equivalent. Yes, that's what i gathered from the sources. But given the use cases for libxml2/lixslt i see this would mean writing my own versions of several funcions (toFile/toBuffer etc.). So my first reaction was: this is a separate level of functionality that could/should be factored out into an API. > > As a long-term solution it might be interessting to have 'plugable' serializers, > > but otoh there might be little common code left to serialisation once you have > > plugins, so maybe you realy need to write your own serializer (the only benefit > > speaking for the plugin aproach would be the ability to set the serializer from > > within the stylesheet). > > Right I could make it easy by providing an API for new serialization > methods provided by the user code. > > [...] > > Lookin' forward to see the outcome ;-) > > The problem is that basically one need to duplicate the code of the > HTML serializer, and this just for ensuring a "non conformant to the spec" > behaviour that 99% of the users should not use. Understand it sounds like > bloat to them ... the HTML serializer is part of libxml2, adding an xhtml > serializer could be added reasonably but one just for not doing the > processing that the HTML spec requires on URI-References when serializing, > err it's just too much IMHO... Understandable. At least in the context of XSLT serialization (which, in my eyes is a bit strange anyway, since XSLT is pretty much serialisation-agnostic. But that's another topic :-) In the context of libxml2 i think a dedicated serialisation API could save some time (reuse of code for the different output methods). And i can think of a lot of interesting serializers (LaTeX, Python/Perl code etc.). ... just thinking loud myself Ralf From veillard@redhat.com Tue Sep 17 08:10:26 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id C906818248 for ; Tue, 17 Sep 2002 08:10:25 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8HCAPu20025 for xslt@gnome.org; Tue, 17 Sep 2002 08:10:25 -0400 Date: Tue, 17 Sep 2002 08:10:25 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] libxslt escaping urls when outputting HTML# Message-ID: <20020917081025.X27778@redhat.com> References: <20020913102848.GA3216@maul.vpn>; <20020913065132.H27778@redhat.com> <3D81E9ED.396.10A270B@localhost> <20020913081406.I27778@redhat.com> <1032168987.21780.17.camel@stationary.home.dunkel.org> <20020916181654.B13904@forte.mh-freiburg.de> <1032222235.4573.3.camel@stationary.home.dunkel.org> <20020917132756.A24118@forte.mh-freiburg.de> <20020917074152.V27778@redhat.com> <20020917140000.B24118@forte.mh-freiburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020917140000.B24118@forte.mh-freiburg.de>; from rm@mh-freiburg.de on Tue, Sep 17, 2002 at 02:00:00PM +0200 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Tue, Sep 17, 2002 at 02:00:00PM +0200, Le grande pinguin wrote: > On Tue, Sep 17, 2002 at 07:41:52AM -0400, Daniel Veillard wrote: > > > > yes they are hardcoded, because they are hardcoded in the specification, > > and if you want to provide your own serialization simply write your own > > version of xsltSaveResult... equivalent. > > Yes, that's what i gathered from the sources. But given the use cases for > libxml2/lixslt i see this would mean writing my own versions of several > funcions (toFile/toBuffer etc.). So my first reaction was: this is a separate > level of functionality that could/should be factored out into an API. As said, adding such an API sounds fine to me. The output method would have to be a QName if I remember correctly, and one would just have to add an API to register (namespace , name) with a serialization entry point taking an xmlOutputBufferPtr, the xmlDocPtr result and the xsltStylesheetPtr stylesheet pointer. > Understandable. At least in the context of XSLT serialization (which, in my > eyes is a bit strange anyway, since XSLT is pretty much serialisation-agnostic. yes conformance to the spec don't even requires a serialization > But that's another topic :-) In the context of libxml2 i think a dedicated > serialisation API could save some time (reuse of code for the different output > methods). And i can think of a lot of interesting serializers (LaTeX, Python/Perl > code etc.). sure, 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/ From igor@stud.fh-frankfurt.de Tue Sep 17 08:23:58 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by mail.gnome.org (Postfix) with ESMTP id EB70218248 for ; Tue, 17 Sep 2002 08:23:57 -0400 (EDT) Received: from fwd04.sul.t-online.de by mailout11.sul.t-online.com with smtp id 17rHOV-0007tI-01; Tue, 17 Sep 2002 14:23:55 +0200 Received: from spell.home.loc (510057364475-0001@[217.81.187.108]) by fmrl04.sul.t-online.com with esmtp id 17rHOL-0xVA8mC; Tue, 17 Sep 2002 14:23:45 +0200 Received: from 192.168.9.72 (ident=unknown) by spell.home.loc with smtp (MasqMail 0.1.16) id 17rHOQ-5yO-00 for xslt@gnome.org; Tue, 17 Sep 2002 14:23:50 +0200 Message-ID: <001a01c25e45$5c4e60b0$4809a8c0@raven> From: Igor Zlatkovic To: References: <20020917045533.T27778@redhat.com> Subject: Re: [xslt] Troubles with the EXSLT date extensions Date: Tue, 17 Sep 2002 14:25:51 +0200 Organization: UAS Frankfurt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 510057364475-0001@t-dialin.net Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: Igor Zlatkovic List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Hi there, > seems some people are using them and are hitting a few bugs: > http://bugzilla.gnome.org/show_bug.cgi?id=93444 > http://bugzilla.gnome.org/show_bug.cgi?id=92818 The one thing I believe is wrong is the reversed substraction. Exslt.org says, that in d = date:difference(x, y): d is positive if x < y (means if x occurs before y), d is negative if x > y. Folowing this, the basic guide would be to compute the difference as d = y - x The relevant function inn libexslt computes it as d = x - y which results in the wrong sign. Can it be, that I am right there? :-) That should however produce the wrong result dw, which is nothing else than dw = d * -1 but it should not produce anything different to that, which it does for certain combinations of x and y. I'll now check where the wrong numbers, that is those which differ from the correct result by more than d * -1, come from. I suspect the problem to be some odd double->long conversion, or similar. Ciao Igor From veillard@redhat.com Tue Sep 17 08:42:31 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id C813C18CBB for ; Tue, 17 Sep 2002 08:42:30 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8HCgUI31871 for xslt@gnome.org; Tue, 17 Sep 2002 08:42:30 -0400 Date: Tue, 17 Sep 2002 08:42:30 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] Troubles with the EXSLT date extensions Message-ID: <20020917084230.Y27778@redhat.com> References: <20020917045533.T27778@redhat.com> <001a01c25e45$5c4e60b0$4809a8c0@raven> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <001a01c25e45$5c4e60b0$4809a8c0@raven>; from igor@stud.fh-frankfurt.de on Tue, Sep 17, 2002 at 02:25:51PM +0200 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Tue, Sep 17, 2002 at 02:25:51PM +0200, Igor Zlatkovic wrote: > Hi there, > > > seems some people are using them and are hitting a few bugs: > > http://bugzilla.gnome.org/show_bug.cgi?id=93444 > > http://bugzilla.gnome.org/show_bug.cgi?id=92818 > > The one thing I believe is wrong is the reversed substraction. Exslt.org > says, that in > d = date:difference(x, y): > d is positive if x < y (means if x occurs before y), > d is negative if x > y. > Folowing this, the basic guide would be to compute the difference as > d = y - x > The relevant function inn libexslt computes it as > d = x - y > which results in the wrong sign. Can it be, that I am right there? :-) heh :-) > That should however produce the wrong result dw, which is nothing else than > dw = d * -1 > but it should not produce anything different to that, which it does for > certain combinations of x and y. > > I'll now check where the wrong numbers, that is those which differ from the > correct result by more than d * -1, come from. I suspect the problem to be > some odd double->long conversion, or similar. Okay, you're in control, feel free to commit of course ! Daniel P.S.: BTW what is the resolution on the WinCE patch of libxml2 ? -- 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/ From igor@stud.fh-frankfurt.de Tue Sep 17 10:09:02 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by mail.gnome.org (Postfix) with ESMTP id 97CE918CA0 for ; Tue, 17 Sep 2002 10:09:01 -0400 (EDT) Received: from fwd08.sul.t-online.de by mailout08.sul.t-online.com with smtp id 17rJ2C-0007Ju-06; Tue, 17 Sep 2002 16:09:00 +0200 Received: from spell.home.loc (510057364475-0001@[217.81.187.108]) by fmrl08.sul.t-online.com with esmtp id 17rJ25-2JxeU4C; Tue, 17 Sep 2002 16:08:53 +0200 Received: from 192.168.9.72 (ident=unknown) by spell.home.loc with smtp (MasqMail 0.1.16) id 17rJ2A-60i-00 for xslt@gnome.org; Tue, 17 Sep 2002 16:08:58 +0200 Message-ID: <002e01c25e54$0f5ca9b0$4809a8c0@raven> From: Igor Zlatkovic To: References: <20020917045533.T27778@redhat.com> <001a01c25e45$5c4e60b0$4809a8c0@raven> <20020917084230.Y27778@redhat.com> Subject: Re: [xslt] Troubles with the EXSLT date extensions Date: Tue, 17 Sep 2002 16:11:04 +0200 Organization: UAS Frankfurt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 510057364475-0001@t-dialin.net Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: Igor Zlatkovic List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Hi there, > > I'll now check where the wrong numbers, that is those which differ from the > > correct result by more than d * -1, come from. I suspect the problem to be > > some odd double->long conversion, or similar. > > Okay, you're in control, feel free to commit of course ! A second glance has revealed that not the datatype conversion plagues us, but that the conversion of the duration to string is somewhat wrong, now that we corrected the xy order :-) Look: Given these arguments: x = 2002-01-01T23:59:59 y = 2002-01-02T00:00:00 we can see that the difference is exactly one second. The relevant code in libexslt computes the difference between the two dates and two times separately, then it builds a sum of those differences. When it compares the dates, it discovers that there is one day difference. When it compares the times, it discovers the difference of -86339 sec. Adding these to each other, 1 day + (-86339 sec) = 86340 sec + (-86339 sec), yields a duration of one second. Still: d = -P1DT23H59M59S which is wrong. The formatting function, exsltDateFormatDuration, wrongly assumes that the duration is negative if any one of the components (secs, days, months, years) is negative, then it makes all negative components positive and combines them. The truth is that these components must be combined with regard to their sign, so that one year and negative twelve months yield zero, for example. I'll fix that and hope all else will remain unbroken.. Charlie? :-) The old cal utility on any Unix tells another story: [spell:~]$ cal 9 1752 September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 We can see that September 1752 in the gregorian calendar had few days less than it normally does. If the x and y lay on different sides of that year, our date:difference(x,y) will compute a wrong duration. Am I severly misguided in my understanding of the gregorian calendar and if I am not, shouldn't something be done here? Ciao Igor From veillard@redhat.com Tue Sep 17 10:17:05 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 6AD2C18D33 for ; Tue, 17 Sep 2002 10:17:05 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8HEH4F28564 for xslt@gnome.org; Tue, 17 Sep 2002 10:17:04 -0400 Date: Tue, 17 Sep 2002 10:17:04 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] Troubles with the EXSLT date extensions Message-ID: <20020917101704.E27778@redhat.com> References: <20020917045533.T27778@redhat.com> <001a01c25e45$5c4e60b0$4809a8c0@raven> <20020917084230.Y27778@redhat.com> <002e01c25e54$0f5ca9b0$4809a8c0@raven> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <002e01c25e54$0f5ca9b0$4809a8c0@raven>; from igor@stud.fh-frankfurt.de on Tue, Sep 17, 2002 at 04:11:04PM +0200 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Tue, Sep 17, 2002 at 04:11:04PM +0200, Igor Zlatkovic wrote: > Hi there, > The old cal utility on any Unix tells another story: > > [spell:~]$ cal 9 1752 > September 1752 > Su Mo Tu We Th Fr Sa > 1 2 14 15 16 > 17 18 19 20 21 22 23 > 24 25 26 27 28 29 30 > > We can see that September 1752 in the gregorian calendar had few days less > than it normally does. If the x and y lay on different sides of that year, > our date:difference(x,y) will compute a wrong duration. Am I severly > misguided in my understanding of the gregorian calendar and if I am not, > shouldn't something be done here? err... that's a bit extreme. Maybe log that as an issue in the comment in the source and if someone really wants to play and fix this he will know why and possibly how, but I don't think there is an use for it ATM. A side question is that the EXSLT date and the date XML Schemas type have somewhat similar code coming from the same source, and I'm wondering if some of your finding shouldn't have to be reflected in schemastype.c in libxml2 code... 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/ From igor@stud.fh-frankfurt.de Tue Sep 17 10:30:27 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by mail.gnome.org (Postfix) with ESMTP id 1913E1814C for ; Tue, 17 Sep 2002 10:30:27 -0400 (EDT) Received: from fwd03.sul.t-online.de by mailout04.sul.t-online.com with smtp id 17rJMt-0001Gg-08; Tue, 17 Sep 2002 16:30:23 +0200 Received: from spell.home.loc (510057364475-0001@[217.81.187.108]) by fmrl03.sul.t-online.com with esmtp id 17rJMZ-1O9FyaC; Tue, 17 Sep 2002 16:30:03 +0200 Received: from 192.168.9.72 (ident=unknown) by spell.home.loc with smtp (MasqMail 0.1.16) id 17rJMe-61R-00 for xslt@gnome.org; Tue, 17 Sep 2002 16:30:08 +0200 Message-ID: <003e01c25e57$045992a0$4809a8c0@raven> From: Igor Zlatkovic To: References: <20020917045533.T27778@redhat.com> <001a01c25e45$5c4e60b0$4809a8c0@raven> <20020917084230.Y27778@redhat.com> <002e01c25e54$0f5ca9b0$4809a8c0@raven> <20020917101704.E27778@redhat.com> Subject: Re: [xslt] Troubles with the EXSLT date extensions Date: Tue, 17 Sep 2002 16:32:14 +0200 Organization: UAS Frankfurt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 510057364475-0001@t-dialin.net Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: Igor Zlatkovic List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: > err... that's a bit extreme. Maybe log that as an issue in the comment > in the source and if someone really wants to play and fix this he will know > why and possibly how, but I don't think there is an use for it ATM. Extreme it is, aye :-) Critical apps will not suffer and it won't really matter if we miscalculate some gloomy Nostradamus' prophecy by few days :-) > A side question is that the EXSLT date and the date XML Schemas type > have somewhat similar code coming from the same source, and I'm wondering > if some of your finding shouldn't have to be reflected in schemastype.c > in libxml2 code... If the Schemas code contains the same error, it must be equally fixed. I'll check that as well. Ciao Igor From cbozeman@hiwaay.net Tue Sep 17 12:18:40 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from mail.hiwaay.net (fly.hiwaay.net [208.147.154.56]) by mail.gnome.org (Postfix) with ESMTP id 7F3E518416 for ; Tue, 17 Sep 2002 12:18:40 -0400 (EDT) Received: from mail.hiwaay.net (localhost [127.0.0.1]) by mail.hiwaay.net (8.12.5/8.12.5) with ESMTP id g8HGIcrO104395 for ; Tue, 17 Sep 2002 11:18:39 -0500 (CDT) Received: (from httpd@localhost) by mail.hiwaay.net (8.12.5/8.12.5/flySubmit) id g8HGIccM112282 for xslt@gnome.org; Tue, 17 Sep 2002 11:18:38 -0500 (CDT) To: xslt@gnome.org Subject: Re: [xslt] Troubles with the EXSLT date extensions Message-ID: <1032279518.3d8755de32688@mail.hiwaay.net> Date: Tue, 17 Sep 2002 11:18:38 -0500 (CDT) From: cbozeman@hiwaay.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-MOQ1032279518ba10b7a1764291bd4f94e99179c4174e" User-Agent: IMP/PHP IMAP webmail program 2.2.8 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: This message is in MIME format. ---MOQ1032279518ba10b7a1764291bd4f94e99179c4174e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit The main source of the problem is in _exsltDateDifference where the calculations of the days and seconds are performed independently. My attatched patch fixes that problem but it may not be particularly elegant. Igor you are correct about the formatting code not taking into account that both seconds and days are negative but I don't know that it is worth fixing; the plan was to incorporate the schema date/duration code once it becomes fully integrated into libxml and that will mean a lot of other changes. As far as there being a similar problem in the schema code, I doubt it. The closest thing to a difference function is adding two dates which uses a very different alogorithm. I have attached patches for date.c and difference.1.xml (to incorporate the bugs) but I don't know if I did the patch correctly. I don't have CVS access at work and my monitor at home died. Feel free to make any changes you feel are necessary and I'll keep monitoring my email if you have any questions. Charlie B. PS. I haven't seen anything on the EXSLT web site concerning the odd September month so I agree with Daniel that we should ignore it. Quoting Igor Zlatkovic : > Hi there, > > > > I'll now check where the wrong numbers, that is those which differ > from > the > > > correct result by more than d * -1, come from. I suspect the problem > to > be > > > some odd double->long conversion, or similar. > > > > Okay, you're in control, feel free to commit of course ! > > A second glance has revealed that not the datatype conversion plagues > us, > but that the conversion of the duration to string is somewhat wrong, > now > that we corrected the xy order :-) Look: > > Given these arguments: > x = 2002-01-01T23:59:59 > y = 2002-01-02T00:00:00 > we can see that the difference is exactly one second. The relevant code > in > libexslt computes the difference between the two dates and two times > separately, then it builds a sum of those differences. When it compares > the > dates, it discovers that there is one day difference. When it compares > the > times, it discovers the difference of -86339 sec. Adding these to each > other, 1 day + (-86339 sec) = 86340 sec + (-86339 sec), yields a > duration of > one second. Still: > d = -P1DT23H59M59S > which is wrong. The formatting function, exsltDateFormatDuration, > wrongly > assumes that the duration is negative if any one of the components > (secs, > days, months, years) is negative, then it makes all negative > components > positive and combines them. The truth is that these components must be > combined with regard to their sign, so that one year and negative > twelve > months yield zero, for example. I'll fix that and hope all else will > remain > unbroken.. Charlie? :-) > > The old cal utility on any Unix tells another story: > > [spell:~]$ cal 9 1752 > September 1752 > Su Mo Tu We Th Fr Sa > 1 2 14 15 16 > 17 18 19 20 21 22 23 > 24 25 26 27 28 29 30 > > We can see that September 1752 in the gregorian calendar had few days > less > than it normally does. If the x and y lay on different sides of that > year, > our date:difference(x,y) will compute a wrong duration. Am I severly > misguided in my understanding of the gregorian calendar and if I am > not, > shouldn't something be done here? > > Ciao > Igor > > > > _______________________________________________ > xslt mailing list, project page http://xmlsoft.org/XSLT/ > xslt@gnome.org > http://mail.gnome.org/mailman/listinfo/xslt > ---MOQ1032279518ba10b7a1764291bd4f94e99179c4174e Content-Type: application/octet-stream; name="date.c-pat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="date.c-pat" KioqIGRhdGUuYy1zYXYJVGh1IE1heSAzMCAyMTo1NToxMyAyMDAyCi0tLSBkYXRlLmMJVHVlI FNlcCAxNyAxMDoyOTo1MyAyMDAyCioqKioqKioqKioqKioqKgoqKiogMTU5MCwxNTk5ICoqKi oKICAgICAgICAgIHJldC0+dmFsdWUuZHVyLm1vbiA9ICgoeC0+dmFsdWUuZGF0ZS55ZWFyICo gMTIpICsgeC0+dmFsdWUuZGF0ZS5tb24pIC0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICgoeS0+dmFsdWUuZGF0ZS55ZWFyICogMTIpICsgeS0+dmFsdWUuZGF0ZS5tb24pOwogI CAgICB9IGVsc2UgewohICAgICAgICAgcmV0LT52YWx1ZS5kdXIuZGF5ICA9IF9leHNsdERhdG VDYXN0WU1Ub0RheXMoeCkgLQohICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9leHN sdERhdGVDYXN0WU1Ub0RheXMoeSk7CiEgICAgICAgICByZXQtPnZhbHVlLmR1ci5kYXkgKz0g eC0+dmFsdWUuZGF0ZS5kYXkgLSB5LT52YWx1ZS5kYXRlLmRheTsKISAgICAgICAgIHJldC0+d mFsdWUuZHVyLnNlYyAgPSBUSU1FX1RPX05VTUJFUih4KSAtIFRJTUVfVE9fTlVNQkVSKHkpOw ogICAgICB9CiAgCiAgICAgIHJldHVybiByZXQ7Ci0tLSAxNTkwLDE2MjIgLS0tLQogICAgICA gICAgcmV0LT52YWx1ZS5kdXIubW9uID0gKCh4LT52YWx1ZS5kYXRlLnllYXIgKiAxMikgKyB4 LT52YWx1ZS5kYXRlLm1vbikgLQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCh5L T52YWx1ZS5kYXRlLnllYXIgKiAxMikgKyB5LT52YWx1ZS5kYXRlLm1vbik7CiAgICAgIH0gZW xzZSB7CiEgCWxvbmcgdG1wZGF5ID0gX2V4c2x0RGF0ZUNhc3RZTVRvRGF5cyh4KSAtIF9leHN sdERhdGVDYXN0WU1Ub0RheXMoeSk7CiEgCWRvdWJsZSB0bXBzZWM7CiEgCWRvdWJsZSB4c2Vj ID0gVElNRV9UT19OVU1CRVIoeCk7CS8qIGNvbnZlcnQgdGltZSB0byBzZWNvbmRzICovCiEgC WRvdWJsZSB5c2VjID0gVElNRV9UT19OVU1CRVIoeSk7CS8qIGNvbnZlcnQgdGltZSB0byBzZW NvbmRzICovCiEgCiEgCS8qIGNvbXB1dGUgdGhlIGRpZmZlcmVuY2UgaW4gZGF5cyAqLwohIAl 0bXBkYXkgKz0geC0+dmFsdWUuZGF0ZS5kYXkgLSB5LT52YWx1ZS5kYXRlLmRheTsKISAKISAJ LyoKISAJICogY29tcHV0ZSB0aGUgZGlmZmVyZW5jZSBpbiBzZWNvbmRzIGFuZCBhZGp1c3QgZ GF5cyBpZiBuZWNlc3NhcnkKISAJICovCiEgCWlmICgodG1wZGF5ID4gMCkgJiYgKHhzZWMgPC B5c2VjKSkgewohIAkgICAgdG1wc2VjID0gKHhzZWMgKyBTRUNTX1BFUl9EQVkpIC0geXNlYzs KISAJICAgIHRtcGRheS0tOwohIAl9IGVsc2UgaWYgKCh0bXBkYXkgPCAwKSAmJiAoeHNlYyA+ IHlzZWMpKSB7CiEgCSAgICB0bXBzZWMgPSB4c2VjIC0gKHlzZWMgKyBTRUNTX1BFUl9EQVkpO wohIAkgICAgdG1wZGF5Kys7CiEgCX0gZWxzZSB7CiEgCSAgICB0bXBzZWMgPSB4c2VjIC0geX NlYzsKISAJfQohIAohIAkvKiBkb24ndCB3YW50IGJvdGggZGF5cyBhbmQgc2VjcyB0byBiZSB uZWdhdGl2ZSAqLwohICAgICAgICAgaWYgKCh0bXBzZWMgPCAwLjApICYmICh0bXBkYXkgPCAw KSkKISAJICAgIHRtcGRheSA9IC10bXBkYXk7CiEgCiEgCXJldC0+dmFsdWUuZHVyLmRheSA9I HRtcGRheTsKISAJcmV0LT52YWx1ZS5kdXIuc2VjID0gdG1wc2VjOwogICAgICB9CiAgCiAgIC AgIHJldHVybiByZXQ7Cg== ---MOQ1032279518ba10b7a1764291bd4f94e99179c4174e Content-Type: application/octet-stream; name="difference.1.xml-pat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="difference.1.xml-pat" KioqIGRpZmZlcmVuY2UuMS54bWwtc2F2CUZyaSBBcHIgMjYgMDE6MTc6NTEgMjAwMgotLS0gZGlm ZmVyZW5jZS4xLnhtbAlUdWUgU2VwIDE3IDEwOjU0OjQzIDIwMDIKKioqKioqKioqKioqKioqCioq KiAxMiwxNiAqKioqCi0tLSAxMiwyMyAtLS0tCiAgICA8ZGF0ZSBkYXRlMT0nMTk3MC0wMS0wMVQw NTowNDowMycgZGF0ZTI9JzE5NzAtMDEtMDFUMDQ6MDM6MDInLz4KICAgIDxkYXRlIGRhdGUxPScy MDAwLTAxLTAxVDA1OjAwOjAzJyBkYXRlMj0nMjAwMC0wMS0wMVQwNDowMzowMicvPgogICAgPGRh dGUgZGF0ZTE9JzIwMDAtMDEtMDFUMDU6MDA6MDMnIGRhdGUyPScxOTgwLTAxLTAxVDA0OjAzOjAy Jy8+CisgICA8IS0tIGZyb20gYnVnICM5MzQ0NCAtLT4KKyAgIDxkYXRlIGRhdGUyPScxOTcwLTAx LTAxVDA1OjA0OjAzJyBkYXRlMT0nMTk3MC0wMS0wMVQwNDowMzowMicvPgorICAgPGRhdGUgZGF0 ZTI9JzIwMDAtMDEtMDFUMDU6MDA6MDMnIGRhdGUxPScyMDAwLTAxLTAxVDA0OjAzOjAyJy8+Cisg ICA8ZGF0ZSBkYXRlMj0nMjAwMC0wMS0wMVQwNTowMDowMycgZGF0ZTE9JzE5ODAtMDEtMDFUMDQ6 MDM6MDInLz4KKyAgIDwhLS0gZnJvbSBidWcgIzkyODE4IC0tPgorICAgPGRhdGUgZGF0ZTE9JzIw MDItMDUtMDJUMjM6NTk6NTknIGRhdGUyPScyMDAyLTA1LTAzVDAwOjAwOjAxJy8+CisgICA8ZGF0 ZSBkYXRlMj0nMjAwMi0wNS0wMlQyMzo1OTo1OScgZGF0ZTE9JzIwMDItMDUtMDNUMDA6MDA6MDEn Lz4KICA8L3BhZ2U+CiAgCg== ---MOQ1032279518ba10b7a1764291bd4f94e99179c4174e-- From igor@stud.fh-frankfurt.de Tue Sep 17 12:21:42 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by mail.gnome.org (Postfix) with ESMTP id 9DE7818416 for ; Tue, 17 Sep 2002 12:21:42 -0400 (EDT) Received: from fwd02.sul.t-online.de by mailout01.sul.t-online.com with smtp id 17rL6b-0005b6-04; Tue, 17 Sep 2002 18:21:41 +0200 Received: from spell.home.loc (510057364475-0001@[217.81.187.108]) by fmrl02.sul.t-online.com with esmtp id 17rL6R-0C1CXQC; Tue, 17 Sep 2002 18:21:31 +0200 Received: from 192.168.9.72 (ident=unknown) by spell.home.loc with smtp (MasqMail 0.1.16) id 17rL6W-63j-00 for xslt@gnome.org; Tue, 17 Sep 2002 18:21:36 +0200 Message-ID: <005901c25e66$9f1e6680$4809a8c0@raven> From: Igor Zlatkovic To: References: <20020917045533.T27778@redhat.com> <001a01c25e45$5c4e60b0$4809a8c0@raven> <20020917084230.Y27778@redhat.com> <002e01c25e54$0f5ca9b0$4809a8c0@raven> <20020917101704.E27778@redhat.com> Subject: Re: [xslt] Troubles with the EXSLT date extensions Date: Tue, 17 Sep 2002 18:23:56 +0200 Organization: UAS Frankfurt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 510057364475-0001@t-dialin.net Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: Igor Zlatkovic List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: The date:difference() bugs are now hopefully fixed. I also took the liberty to eliminate some type conversion warnings. I decided not to modify the format function, but the implementation of date:difference. That I did because a general solution in the format function would require floating point division, rounding to integer and what not. That could be avoided in the date:difference implementation, where the problem is solved by using addition and subtraction only. We always have better results when we do not involve machine-precision errors too much. So is now x = 2002-01-01T23:59:59.123456789 y = 2002-01-02T00:00:00.123456789 d = PT1S what would probably result in some weird fractional d, had we modified the format function. Modifications are limited to libexslt/date.c. The changes are commited. Ciao Igor From igor@stud.fh-frankfurt.de Tue Sep 17 12:30:32 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by mail.gnome.org (Postfix) with ESMTP id 76CE31838D for ; Tue, 17 Sep 2002 12:30:32 -0400 (EDT) Received: from fwd05.sul.t-online.de by mailout09.sul.t-online.com with smtp id 17rLF8-0003Eu-0J; Tue, 17 Sep 2002 18:30:30 +0200 Received: from spell.home.loc (510057364475-0001@[217.81.187.108]) by fmrl05.sul.t-online.com with esmtp id 17rLF0-0iVRmiC; Tue, 17 Sep 2002 18:30:22 +0200 Received: from 192.168.9.72 (ident=unknown) by spell.home.loc with smtp (MasqMail 0.1.16) id 17rLF5-63z-00 for xslt@gnome.org; Tue, 17 Sep 2002 18:30:27 +0200 Message-ID: <006201c25e67$dbce2d80$4809a8c0@raven> From: Igor Zlatkovic To: References: <1032279518.3d8755de32688@mail.hiwaay.net> Subject: Re: [xslt] Troubles with the EXSLT date extensions Date: Tue, 17 Sep 2002 18:32:48 +0200 Organization: UAS Frankfurt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 510057364475-0001@t-dialin.net Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: Igor Zlatkovic List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Damn... my server picked up your mail two seconds after I have sent my messaege :-) I did something different, but have changed exactly the same place. The diff for my changes follows this message. I basically simply adjusted the day and sec, based on the sign difference between day and sec. The thing is simple, because sec cannot contain anything greater than SECS_PER_DAY at that place. I also swapped the places of x and y, to get rid of the wrong sign problem. Have a look. You think that is somewhere near okay? Ciao Igor RCS file: /cvs/gnome/libxslt/libexslt/date.c,v retrieving revision 1.14 diff -c -r1.14 date.c *** date.c 30 May 2002 21:36:57 -0000 1.14 --- date.c 17 Sep 2002 16:11:48 -0000 *************** *** 1587,1599 **** if (((x->type == XS_GYEAR) || (x->type == XS_GYEARMONTH)) && (!flag)) { /* compute the difference in months */ ! ret->value.dur.mon = ((x->value.date.year * 12) + x->value.date.mon) - ! ((y->value.date.year * 12) + y->value.date.mon); } else { ! ret->value.dur.day = _exsltDateCastYMToDays(x) - ! _exsltDateCastYMToDays(y); ! ret->value.dur.day += x->value.date.day - y->value.date.day; ! ret->value.dur.sec = TIME_TO_NUMBER(x) - TIME_TO_NUMBER(y); } return ret; --- 1587,1608 ---- if (((x->type == XS_GYEAR) || (x->type == XS_GYEARMONTH)) && (!flag)) { /* compute the difference in months */ ! ret->value.dur.mon = ((y->value.date.year * 12) + y->value.date.mon) - ! ((x->value.date.year * 12) + x->value.date.mon); ! /* The above will give a wrong result if x and y are on different sides ! of the September 1752. Resolution is welcome :-) */ } else { ! ret->value.dur.day = _exsltDateCastYMToDays(y) - ! _exsltDateCastYMToDays(x); ! ret->value.dur.day += y->value.date.day - x->value.date.day; ! ret->value.dur.sec = TIME_TO_NUMBER(y) - TIME_TO_NUMBER(x); ! if (ret->value.dur.day > 0.0 && ret->value.dur.sec < 0.0) { ! ret->value.dur.day -= 1; ! ret->value.dur.sec = ret->value.dur.sec + SECS_PER_DAY; ! } else if (ret->value.dur.day < 0.0 && ret->value.dur.sec > 0.0) { ! ret->value.dur.day += 1; ! ret->value.dur.sec = ret->value.dur.sec - SECS_PER_DAY; ! } } return ret; From cbozeman@hiwaay.net Tue Sep 17 12:53:24 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from mail.hiwaay.net (fly.hiwaay.net [208.147.154.56]) by mail.gnome.org (Postfix) with ESMTP id 1B5D218D98 for ; Tue, 17 Sep 2002 12:53:24 -0400 (EDT) Received: from mail.hiwaay.net (localhost [127.0.0.1]) by mail.hiwaay.net (8.12.5/8.12.5) with ESMTP id g8HGrMrO097451 for ; Tue, 17 Sep 2002 11:53:22 -0500 (CDT) Received: (from httpd@localhost) by mail.hiwaay.net (8.12.5/8.12.5/flySubmit) id g8HGrMwk156333 for xslt@gnome.org; Tue, 17 Sep 2002 11:53:22 -0500 (CDT) To: xslt@gnome.org Subject: Re: [xslt] Troubles with the EXSLT date extensions Message-ID: <1032281602.3d875e020d674@mail.hiwaay.net> Date: Tue, 17 Sep 2002 11:53:22 -0500 (CDT) From: cbozeman@hiwaay.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-MOQ1032281602db1a2d4e78eb608216a4c46f1c276021" User-Agent: IMP/PHP IMAP webmail program 2.2.8 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: This message is in MIME format. ---MOQ1032281602db1a2d4e78eb608216a4c46f1c276021 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit You need to check the case of both negative days and seconds, otherwise the result will end up with a negative sign in front of days after it is formatted. I have attached a newer patch to difference.1.xml to illustrate the problem. Charlie B. Quoting Igor Zlatkovic : > Damn... my server picked up your mail two seconds after I have sent my > messaege :-) > > I did something different, but have changed exactly the same place. The > diff > for my changes follows this message. I basically simply adjusted the day > and > sec, based on the sign difference between day and sec. The thing is > simple, > because sec cannot contain anything greater than SECS_PER_DAY at that > place. > I also swapped the places of x and y, to get rid of the wrong sign > problem. > Have a look. You think that is somewhere near okay? > > Ciao > Igor > > > RCS file: /cvs/gnome/libxslt/libexslt/date.c,v > retrieving revision 1.14 > diff -c -r1.14 date.c > *** date.c 30 May 2002 21:36:57 -0000 1.14 > --- date.c 17 Sep 2002 16:11:48 -0000 > *************** > *** 1587,1599 **** > > if (((x->type == XS_GYEAR) || (x->type == XS_GYEARMONTH)) && > (!flag)) > { > /* compute the difference in months */ > ! ret->value.dur.mon = ((x->value.date.year * 12) + > x->value.date.mon) - > ! ((y->value.date.year * 12) + > y->value.date.mon); > } else { > ! ret->value.dur.day = _exsltDateCastYMToDays(x) - > ! _exsltDateCastYMToDays(y); > ! ret->value.dur.day += x->value.date.day - y->value.date.day; > ! ret->value.dur.sec = TIME_TO_NUMBER(x) - TIME_TO_NUMBER(y); > } > > return ret; > --- 1587,1608 ---- > > if (((x->type == XS_GYEAR) || (x->type == XS_GYEARMONTH)) && > (!flag)) > { > /* compute the difference in months */ > ! ret->value.dur.mon = ((y->value.date.year * 12) + > y->value.date.mon) - > ! ((x->value.date.year * 12) + > x->value.date.mon); > ! /* The above will give a wrong result if x and y are on > different > sides > ! of the September 1752. Resolution is welcome :-) */ > } else { > ! ret->value.dur.day = _exsltDateCastYMToDays(y) - > ! _exsltDateCastYMToDays(x); > ! ret->value.dur.day += y->value.date.day - x->value.date.day; > ! ret->value.dur.sec = TIME_TO_NUMBER(y) - TIME_TO_NUMBER(x); > ! if (ret->value.dur.day > 0.0 && ret->value.dur.sec < 0.0) { > ! ret->value.dur.day -= 1; > ! ret->value.dur.sec = ret->value.dur.sec + SECS_PER_DAY; > ! } else if (ret->value.dur.day < 0.0 && ret->value.dur.sec > 0.0) > { > ! ret->value.dur.day += 1; > ! ret->value.dur.sec = ret->value.dur.sec - SECS_PER_DAY; > ! } > } > > return ret; > > > > > > _______________________________________________ > xslt mailing list, project page http://xmlsoft.org/XSLT/ > xslt@gnome.org > http://mail.gnome.org/mailman/listinfo/xslt > ---MOQ1032281602db1a2d4e78eb608216a4c46f1c276021 Content-Type: application/octet-stream; name="difference.1.xml-pat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="difference.1.xml-pat" KioqIGRpZmZlcmVuY2UuMS54bWwtc2F2CUZyaSBBcHIgMjYgMDE6MTc6NTEgMjAwMgotLS0gZGlm ZmVyZW5jZS4xLnhtbAlUdWUgU2VwIDE3IDExOjUwOjM4IDIwMDIKKioqKioqKioqKioqKioqCioq KiAxMiwxNiAqKioqCi0tLSAxMiwyNSAtLS0tCiAgICA8ZGF0ZSBkYXRlMT0nMTk3MC0wMS0wMVQw NTowNDowMycgZGF0ZTI9JzE5NzAtMDEtMDFUMDQ6MDM6MDInLz4KICAgIDxkYXRlIGRhdGUxPScy MDAwLTAxLTAxVDA1OjAwOjAzJyBkYXRlMj0nMjAwMC0wMS0wMVQwNDowMzowMicvPgogICAgPGRh dGUgZGF0ZTE9JzIwMDAtMDEtMDFUMDU6MDA6MDMnIGRhdGUyPScxOTgwLTAxLTAxVDA0OjAzOjAy Jy8+CisgICA8IS0tIGZyb20gYnVnICM5MzQ0NCAtLT4KKyAgIDxkYXRlIGRhdGUyPScxOTcwLTAx LTAxVDA1OjA0OjAzJyBkYXRlMT0nMTk3MC0wMS0wMVQwNDowMzowMicvPgorICAgPGRhdGUgZGF0 ZTI9JzIwMDAtMDEtMDFUMDU6MDA6MDMnIGRhdGUxPScyMDAwLTAxLTAxVDA0OjAzOjAyJy8+Cisg ICA8ZGF0ZSBkYXRlMj0nMjAwMC0wMS0wMVQwNTowMDowMycgZGF0ZTE9JzE5ODAtMDEtMDFUMDQ6 MDM6MDInLz4KKyAgIDwhLS0gZnJvbSBidWcgIzkyODE4IC0tPgorICAgPGRhdGUgZGF0ZTE9JzIw MDItMDUtMDJUMjM6NTk6NTknIGRhdGUyPScyMDAyLTA1LTAzVDAwOjAwOjAxJy8+CisgICA8ZGF0 ZSBkYXRlMj0nMjAwMi0wNS0wMlQyMzo1OTo1OScgZGF0ZTE9JzIwMDItMDUtMDNUMDA6MDA6MDEn Lz4KKyAgIDwhLS0gcmVzdWx0IHNob3VsZCBiZSBuZWdhdGl2ZSAtLT4KKyAgIDxkYXRlIGRhdGUx PScyMDAwLTAxLTAxVDA0OjAzOjAyJyBkYXRlMj0nMjAwMC0wMS0wMlQwNTowMDowMycvPgogIDwv cGFnZT4KICAK ---MOQ1032281602db1a2d4e78eb608216a4c46f1c276021-- From paul@localdomain.net Tue Sep 17 13:05:47 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by mail.gnome.org (Postfix) with ESMTP id 943D0182C1 for ; Tue, 17 Sep 2002 13:05:47 -0400 (EDT) Received: from 1cust216.tnt3.lexington.ky.da.uu.net ([65.238.105.216] helo=localhost.localdomain.net) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 17rLnF-0000nU-00 for xslt@gnome.org; Tue, 17 Sep 2002 10:05:46 -0700 Received: by localhost.localdomain.net (Postfix, from userid 500) id 9F3EE350C6; Tue, 17 Sep 2002 13:05:43 -0400 (EDT) Date: Tue, 17 Sep 2002 13:05:43 -0400 From: Paul Tremblay To: xslt@gnome.org Message-ID: <20020917130543.B12450@localhost.localdomain> Mail-Followup-To: xslt@gnome.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.21i Subject: [xslt] Bug when declaring entities? Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: I think I have found a bug in xsltproc. If I put the follwing in my stylesheet: &nbsp;"> ]> I get the following error: compilation error: file /home/paul/Documents/data/xsl_style_sheets/finalConvertTei.xsl line 2 element text Namespaces prefix used for multiple namespaces The code in my stylesheet is taken directly from a book on xslt. If I run the same code with xalan, I don't get an error. If I type xsltproc --version Then I get this output: Using libxml 20403, libxslt 10003 and libexslt 301 xsltproc was compiled against libxml 20403, libxslt 10003 and libexslt 301 libxslt 10003 was compiled against libxml 20403 libexslt 301 was compiled against libxml 20403 Thanks Paul -- ************************ *Paul Tremblay * *phthenry@earthlink.net* ************************ From veillard@redhat.com Tue Sep 17 13:43:51 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 5C306182C1 for ; Tue, 17 Sep 2002 13:43:51 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8HHhoq26720 for xslt@gnome.org; Tue, 17 Sep 2002 13:43:50 -0400 Date: Tue, 17 Sep 2002 13:43:50 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] Bug when declaring entities? Message-ID: <20020917134350.L27778@redhat.com> References: <20020917130543.B12450@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020917130543.B12450@localhost.localdomain>; from phthenry@earthlink.net on Tue, Sep 17, 2002 at 01:05:43PM -0400 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Tue, Sep 17, 2002 at 01:05:43PM -0400, Paul Tremblay wrote: > I think I have found a bug in xsltproc. > > If I put the follwing in my stylesheet: > > disable-output-escaping='yes'>&nbsp;"> > ]> > > I get the following error: > > compilation error: file /home/paul/Documents/data/xsl_style_sheets/finalConvertTei.xsl line 2 element text > Namespaces prefix used for multiple namespaces I don't think it's what you actually have in your stylesheet. but : &nbsp;"> otherwise your entity declaration makes no sense and libxslt would not generate an error since there is no namespace used in the entity ! > The code in my stylesheet is taken directly from a book on xslt. If I that's theorically fine but if you do     your   reference would lead to different namespaces for the element text and in 99% of the case you don't want this so my parser complain about it. Simply define the namespace in the entity: &nbsp;"> then it becomes context insensitive and libxml2 won't complain. Anyway using "disable-output-escaping" is bad practice in general... > run the same code with xalan, I don't get an error. They are just a bunch of losers :-) More seriously we have different appreciation of some of those suble issues. 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/ From igor@stud.fh-frankfurt.de Tue Sep 17 14:46:54 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by mail.gnome.org (Postfix) with ESMTP id C07CF1863F for ; Tue, 17 Sep 2002 14:46:53 -0400 (EDT) Received: from fwd07.sul.t-online.de by mailout08.sul.t-online.com with smtp id 17rNN6-0004nN-04; Tue, 17 Sep 2002 20:46:52 +0200 Received: from spell.home.loc (510057364475-0001@[217.81.185.51]) by fmrl07.sul.t-online.com with esmtp id 17rNN2-1s5wCOC; Tue, 17 Sep 2002 20:46:48 +0200 Received: from 192.168.9.72 (ident=unknown) by spell.home.loc with smtp (MasqMail 0.1.16) id 17rNN7-66h-00 for xslt@gnome.org; Tue, 17 Sep 2002 20:46:53 +0200 Message-ID: <007e01c25e7a$eb464ff0$4809a8c0@raven> From: Igor Zlatkovic To: References: <1032281602.3d875e020d674@mail.hiwaay.net> Subject: Re: [xslt] Troubles with the EXSLT date extensions Date: Tue, 17 Sep 2002 20:49:14 +0200 Organization: UAS Frankfurt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 510057364475-0001@t-dialin.net Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: Igor Zlatkovic List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Hi there, > You need to check the case of both negative days and seconds, otherwise the > result will end up with a negative sign in front of days after it is formatted. > I have attached a newer patch to difference.1.xml to illustrate the problem. Hmm... if both days and seconds are negative, then the result should be negative, not true? Here is the current result with my code and the data from your patch: 1970-01-01T04:03:02 - 1970-01-01T05:04:03 = PT1H1M1S 2000-01-01T04:03:02 - 2000-01-01T05:00:03 = PT57M1S 1980-01-01T04:03:02 - 2000-01-01T05:00:03 = P7305DT57M1S 2002-05-02T23:59:59 - 2002-05-03T00:00:01 = PT2S 2002-05-03T00:00:01 - 2002-05-02T23:59:59 = -PT2S 2000-01-01T04:03:02 - 2000-01-02T05:00:03 = P1DT57M1S The last example is okay. It should not be negative, as the comment suggests, because the first date occurs before the second and http://exslt.org/date/functions/difference/index.html indicates that the resulting duration is positive in that case. Other results are okay as well. Am I missing something? Ciao Igor From cbozeman@hiwaay.net Tue Sep 17 16:08:59 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from mail.hiwaay.net (fly.hiwaay.net [208.147.154.56]) by mail.gnome.org (Postfix) with ESMTP id A12021818E for ; Tue, 17 Sep 2002 16:08:59 -0400 (EDT) Received: from mail.hiwaay.net (localhost [127.0.0.1]) by mail.hiwaay.net (8.12.5/8.12.5) with ESMTP id g8HK8vrO119974 for ; Tue, 17 Sep 2002 15:08:57 -0500 (CDT) Received: (from httpd@localhost) by mail.hiwaay.net (8.12.5/8.12.5/flySubmit) id g8HK8ugH022254 for xslt@gnome.org; Tue, 17 Sep 2002 15:08:56 -0500 (CDT) To: xslt@gnome.org Subject: Re: [xslt] Troubles with the EXSLT date extensions Message-ID: <1032293336.3d878bd8453af@mail.hiwaay.net> Date: Tue, 17 Sep 2002 15:08:56 -0500 (CDT) From: cbozeman@hiwaay.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-MOQ1032293336706cbf77ac07bcc39ba45d9fe707aa3d" User-Agent: IMP/PHP IMAP webmail program 2.2.8 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: This message is in MIME format. ---MOQ1032293336706cbf77ac07bcc39ba45d9fe707aa3d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Doh! I implemented difference backwards. I should have been subtracting y - x (like you did). This means that the seconds function is also wrong. However, I was trying to show that it is still possible for multiple items in the duration object to have negative values which the format function will not handle correctly (i.e. embedded '-' in the output string). See the new patch for an example. I'll start making changes. Charlie B. Quoting Igor Zlatkovic : > Hi there, > > > You need to check the case of both negative days and seconds, > otherwise > the > > result will end up with a negative sign in front of days after it is > formatted. > > I have attached a newer patch to difference.1.xml to illustrate the > problem. > > Hmm... if both days and seconds are negative, then the result should > be > negative, not true? Here is the current result with my code and the > data > from your patch: > > > 1970-01-01T04:03:02 - 1970-01-01T05:04:03 = PT1H1M1S > 2000-01-01T04:03:02 - 2000-01-01T05:00:03 = PT57M1S > 1980-01-01T04:03:02 - 2000-01-01T05:00:03 = P7305DT57M1S > > 2002-05-02T23:59:59 - 2002-05-03T00:00:01 = PT2S > 2002-05-03T00:00:01 - 2002-05-02T23:59:59 = -PT2S > > 2000-01-01T04:03:02 - 2000-01-02T05:00:03 = P1DT57M1S > > The last example is okay. It should not be negative, as the comment > suggests, because the first date occurs before the second and > http://exslt.org/date/functions/difference/index.html indicates that > the > resulting duration is positive in that case. Other results are okay as > well. > > Am I missing something? > > Ciao > Igor > > _______________________________________________ > xslt mailing list, project page http://xmlsoft.org/XSLT/ > xslt@gnome.org > http://mail.gnome.org/mailman/listinfo/xslt > ---MOQ1032293336706cbf77ac07bcc39ba45d9fe707aa3d Content-Type: application/octet-stream; name="difference.1.xml-pat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="difference.1.xml-pat" KioqIGRpZmZlcmVuY2UuMS54bWwtc2F2CUZyaSBBcHIgMjYgMDE6MTc6NTEgMjAwMgotLS0gZGlm ZmVyZW5jZS4xLnhtbAlUdWUgU2VwIDE3IDE1OjA0OjE0IDIwMDIKKioqKioqKioqKioqKioqCioq KiAxMiwxNiAqKioqCi0tLSAxMiwyNSAtLS0tCiAgICA8ZGF0ZSBkYXRlMT0nMTk3MC0wMS0wMVQw NTowNDowMycgZGF0ZTI9JzE5NzAtMDEtMDFUMDQ6MDM6MDInLz4KICAgIDxkYXRlIGRhdGUxPScy MDAwLTAxLTAxVDA1OjAwOjAzJyBkYXRlMj0nMjAwMC0wMS0wMVQwNDowMzowMicvPgogICAgPGRh dGUgZGF0ZTE9JzIwMDAtMDEtMDFUMDU6MDA6MDMnIGRhdGUyPScxOTgwLTAxLTAxVDA0OjAzOjAy Jy8+CisgICA8IS0tIGZyb20gYnVnICM5MzQ0NCAtLT4KKyAgIDxkYXRlIGRhdGUyPScxOTcwLTAx LTAxVDA1OjA0OjAzJyBkYXRlMT0nMTk3MC0wMS0wMVQwNDowMzowMicvPgorICAgPGRhdGUgZGF0 ZTI9JzIwMDAtMDEtMDFUMDU6MDA6MDMnIGRhdGUxPScyMDAwLTAxLTAxVDA0OjAzOjAyJy8+Cisg ICA8ZGF0ZSBkYXRlMj0nMjAwMC0wMS0wMVQwNTowMDowMycgZGF0ZTE9JzE5ODAtMDEtMDFUMDQ6 MDM6MDInLz4KKyAgIDwhLS0gZnJvbSBidWcgIzkyODE4IC0tPgorICAgPGRhdGUgZGF0ZTE9JzIw MDItMDUtMDJUMjM6NTk6NTknIGRhdGUyPScyMDAyLTA1LTAzVDAwOjAwOjAxJy8+CisgICA8ZGF0 ZSBkYXRlMj0nMjAwMi0wNS0wMlQyMzo1OTo1OScgZGF0ZTE9JzIwMDItMDUtMDNUMDA6MDA6MDEn Lz4KKyAgIDwhLS0gcmVzdWx0IHNob3VsZCBiZSBuZWdhdGl2ZSAtLT4KKyAgIDxkYXRlIGRhdGUx PScyMDAwLTAxLTAyVDA1OjAwOjAzJyBkYXRlMj0nMjAwMC0wMS0wMVQwNDowMzowMicvPgogIDwv cGFnZT4KICAK ---MOQ1032293336706cbf77ac07bcc39ba45d9fe707aa3d-- From paul@localdomain.net Tue Sep 17 18:09:40 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by mail.gnome.org (Postfix) with ESMTP id 406DB18162 for ; Tue, 17 Sep 2002 18:09:40 -0400 (EDT) Received: from 1cust21.tnt3.lexington.ky.da.uu.net ([65.238.105.21] helo=localhost.localdomain.net) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17rQXG-0004i7-00 for xslt@gnome.org; Tue, 17 Sep 2002 15:09:35 -0700 Received: by localhost.localdomain.net (Postfix, from userid 500) id CCF86350C6; Tue, 17 Sep 2002 18:09:32 -0400 (EDT) Date: Tue, 17 Sep 2002 18:09:32 -0400 From: Paul Tremblay To: xslt@gnome.org Subject: Re: [xslt] Bug when declaring entities? Message-ID: <20020917180932.C12450@localhost.localdomain> Mail-Followup-To: xslt@gnome.org References: <20020917130543.B12450@localhost.localdomain> <20020917134350.L27778@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020917134350.L27778@redhat.com> User-Agent: Mutt/1.3.21i Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Tue, Sep 17, 2002 at 01:43:50PM -0400, Daniel Veillard wrote: > > I don't think it's what you actually have in your stylesheet. > but : > &nbsp;"> > > otherwise your entity declaration makes no sense and libxslt would > not generate an error since there is no namespace used in the entity ! > Sorry for that mistake. I had taken out the namespaces in order to get xsltproc to work. > > The code in my stylesheet is taken directly from a book on xslt. If I > > that's theorically fine but if you do > >   >   > > your   reference would lead to different namespaces for the element > text and in 99% of the case you don't want this so my parser complain about > it. > Simply define the namespace in the entity: > > &nbsp;"> I don't follow this. I think I need to read more about namespaces to fully understand your argument. > > then it becomes context insensitive and libxml2 won't complain. > Anyway using "disable-output-escaping" is bad practice in general... I know this isn't a tutorial mailing list, but how else would I get ' ' into an html document using xsltproc? > > > run the same code with xalan, I don't get an error. > > They are just a bunch of losers :-) > More seriously we have different appreciation of some of those suble issues. There is the issue of speed in xalan versus xsltproc, but I think I'll bring this topic up in another thread. Thank you very much for your response. I am able to generate  , even if my method is perhaps wrong. Paul -- ************************ *Paul Tremblay * *phthenry@earthlink.net* ************************ From paul@localdomain.net Tue Sep 17 18:13:44 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mail.gnome.org (Postfix) with ESMTP id 5CB8A1833A for ; Tue, 17 Sep 2002 18:13:44 -0400 (EDT) Received: from 1cust21.tnt3.lexington.ky.da.uu.net ([65.238.105.21] helo=localhost.localdomain.net) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17rQbD-0006tT-00 for xslt@gnome.org; Tue, 17 Sep 2002 15:13:39 -0700 Received: by localhost.localdomain.net (Postfix, from userid 500) id 0A67F350C6; Tue, 17 Sep 2002 18:13:38 -0400 (EDT) Date: Tue, 17 Sep 2002 18:13:38 -0400 From: Paul Tremblay To: xslt@gnome.org Message-ID: <20020917181338.D12450@localhost.localdomain> Mail-Followup-To: xslt@gnome.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.21i Subject: [xslt] is xsltproc really this fast? Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: I hope this comment isn't too off topic, but is xsltproc really 25 times faster than xalan? I have a small stylesheet, which I processed firts with xsltproc and then with xalan. xsltproc took .75 seconds to process. xalan took 26 seconds! Other tests have yielded similar results. I should point out that I have a pentium one box, so maybe java just can't run efficiently on a machine this slow. Paul -- ************************ *Paul Tremblay * *phthenry@earthlink.net* ************************ From veillard@redhat.com Tue Sep 17 19:03:26 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D9663183A8 for ; Tue, 17 Sep 2002 19:03:25 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8HN3Pe27949 for xslt@gnome.org; Tue, 17 Sep 2002 19:03:25 -0400 Date: Tue, 17 Sep 2002 19:03:25 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] Bug when declaring entities? Message-ID: <20020917190325.V27778@redhat.com> References: <20020917130543.B12450@localhost.localdomain> <20020917134350.L27778@redhat.com> <20020917180932.C12450@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020917180932.C12450@localhost.localdomain>; from phthenry@earthlink.net on Tue, Sep 17, 2002 at 06:09:32PM -0400 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Tue, Sep 17, 2002 at 06:09:32PM -0400, Paul Tremblay wrote: > On Tue, Sep 17, 2002 at 01:43:50PM -0400, Daniel Veillard wrote: > > Simply define the namespace in the entity: > > > > &nbsp;"> > > > I don't follow this. I think I need to read more about namespaces to > fully understand your argument. it's a bit complex, it's also related to where entities replacement and namespace detection occur in an XML processor. > I know this isn't a tutorial mailing list, but how else would I get > ' ' into an html document using xsltproc?   is another way to put it in the stylesheet, and then the same character will be generated in the output and depending on the output encoding it may be generated as  ,   (or the hexadecimal one) or directly the caracter with that code point in the given encoding. This should be completely equivalent for the HTML client. 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/ From paul@localdomain.net Tue Sep 17 19:56:42 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mail.gnome.org (Postfix) with ESMTP id 550A518111 for ; Tue, 17 Sep 2002 19:56:42 -0400 (EDT) Received: from 1cust21.tnt3.lexington.ky.da.uu.net ([65.238.105.21] helo=localhost.localdomain.net) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17rSCu-0005vL-00 for xslt@gnome.org; Tue, 17 Sep 2002 16:56:41 -0700 Received: by localhost.localdomain.net (Postfix, from userid 500) id 81E94350C6; Tue, 17 Sep 2002 19:56:40 -0400 (EDT) Date: Tue, 17 Sep 2002 19:56:39 -0400 From: Paul Tremblay To: xslt@gnome.org Subject: Re: [xslt] Bug when declaring entities? Message-ID: <20020917195639.G12450@localhost.localdomain> Mail-Followup-To: xslt@gnome.org References: <20020917130543.B12450@localhost.localdomain> <20020917134350.L27778@redhat.com> <20020917180932.C12450@localhost.localdomain> <20020917190325.V27778@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020917190325.V27778@redhat.com> User-Agent: Mutt/1.3.21i Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Tue, Sep 17, 2002 at 07:03:25PM -0400, Daniel Veillard wrote: > > I know this isn't a tutorial mailing list, but how else would I get > > ' ' into an html document using xsltproc? > >   is another way to put it in the stylesheet, and then the same > character will be generated in the output and depending on the output > encoding it may be generated as  ,   (or the hexadecimal one) > or directly the caracter with that code point in the given encoding. > This should be completely equivalent for the HTML client. > Ah, that is much better than escaping output! It didn't even occurr to me to use unicode for spaces. Probably any html entity has a unicode equivalent, so I'll have to think along those lines. Thanks! Paul -- ************************ *Paul Tremblay * *phthenry@earthlink.net* ************************ From veillard@redhat.com Wed Sep 18 05:03:43 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 631D918E2B for ; Wed, 18 Sep 2002 05:03:43 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8I93hX03937 for xslt@gnome.org; Wed, 18 Sep 2002 05:03:43 -0400 Date: Wed, 18 Sep 2002 05:03:43 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] is xsltproc really this fast? Message-ID: <20020918050343.X27778@redhat.com> References: <20020917181338.D12450@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020917181338.D12450@localhost.localdomain>; from phthenry@earthlink.net on Tue, Sep 17, 2002 at 06:13:38PM -0400 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Tue, Sep 17, 2002 at 06:13:38PM -0400, Paul Tremblay wrote: > I hope this comment isn't too off topic, but is xsltproc really 25 times > faster than xalan? Honnestly I don't think so... Faster in average, yes but not by such a margin. I don't try to do benchmark, but I try to keep libxml2/libxslt relatively fast and lightweight. > I have a small stylesheet, which I processed firts with xsltproc and > then with xalan. xsltproc took .75 seconds to process. xalan took 26 > seconds! Other tests have yielded similar results. > > I should point out that I have a pentium one box, so maybe java just > can't run efficiently on a machine this slow. Well running a single processing possibly small document really defavor a Java based processor since it has to set-up the Java environment, and a single execution doesn't allow to take the benefits of JIT or HotSpot optimizations. That said, I think Java is a pig ressource wise, and in cases like yours C - while being harder to program - really really make a difference, and it shows. 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/ From mdev@ardvark.idg.nl Wed Sep 18 05:08:15 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from ardvark.idg.nl (ardvark.idg.nl [62.250.13.24]) by mail.gnome.org (Postfix) with ESMTP id 26FA0184D9 for ; Wed, 18 Sep 2002 05:08:15 -0400 (EDT) Received: from ardvark.idg.nl (localhost [127.0.0.1]) by ardvark.idg.nl (8.12.3/8.11.1) with ESMTP id g8I99QoB008092 for ; Wed, 18 Sep 2002 11:09:26 +0200 (CEST) (envelope-from mdev@ardvark.idg.nl) Received: (from mdev@localhost) by ardvark.idg.nl (8.12.3/8.12.3/Submit) id g8I99Q39008090 for xslt@gnome.org; Wed, 18 Sep 2002 11:09:26 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: Melvyn Sopacua Organization: IDG.nl To: xslt@gnome.org Date: Wed, 18 Sep 2002 11:09:25 +0200 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200209181109.25967.mdev@idg.nl> Subject: [xslt] Testkit Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: Hi, I get quite a few diffs when running make check. Is this a work in progress, and/or are you interested in the results? Since the output is not sent to STDERR I'd like to clean it up first. Is there a list of 'known issues' with the testkit? --=20 Best regards, IDG.nl Melvyn Sopacua WebMaster From veillard@redhat.com Wed Sep 18 05:41:05 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 2966E18E77 for ; Wed, 18 Sep 2002 05:41:05 -0400 (EDT) Received: (from veillard@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g8I9f1v12292 for xslt@gnome.org; Wed, 18 Sep 2002 05:41:01 -0400 Date: Wed, 18 Sep 2002 05:41:01 -0400 From: Daniel Veillard To: xslt@gnome.org Subject: Re: [xslt] Testkit Message-ID: <20020918054101.Z27778@redhat.com> References: <200209181109.25967.mdev@idg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200209181109.25967.mdev@idg.nl>; from mdev@idg.nl on Wed, Sep 18, 2002 at 11:09:25AM +0200 Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: veillard@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Wed, Sep 18, 2002 at 11:09:25AM +0200, Melvyn Sopacua wrote: > Hi, > > I get quite a few diffs when running make check. No for me. Only diffs are on DocBook FO generation tests for me. > Is this a work in progress, and/or are you interested in the results? > > Since the output is not sent to STDERR I'd like to clean it up first. > > Is there a list of 'known issues' with the testkit? not really it should be clean. Make sure you have the latests versions of libxml2/libxslt, check your platform versions of make, diff and other tools too for difference in behaviour from the Linux or Gnu version. 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/ From igor@stud.fh-frankfurt.de Wed Sep 18 06:25:49 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by mail.gnome.org (Postfix) with ESMTP id 082CE18E94 for ; Wed, 18 Sep 2002 06:25:49 -0400 (EDT) Received: from fwd11.sul.t-online.de by mailout08.sul.t-online.com with smtp id 17rc1j-0006aP-04; Wed, 18 Sep 2002 12:25:47 +0200 Received: from spell.home.loc (510057364475-0001@[217.81.190.209]) by fmrl11.sul.t-online.com with esmtp id 17rc1X-0BLg9YC; Wed, 18 Sep 2002 12:25:35 +0200 Received: from 192.168.9.72 (ident=unknown) by spell.home.loc with smtp (MasqMail 0.1.16) id 17rc1e-6K3-00 for xslt@gnome.org; Wed, 18 Sep 2002 12:25:42 +0200 Message-ID: <002a01c25efe$08c15fb0$4809a8c0@raven> From: Igor Zlatkovic To: References: <1032293336.3d878bd8453af@mail.hiwaay.net> Subject: Re: [xslt] Troubles with the EXSLT date extensions Date: Wed, 18 Sep 2002 12:27:48 +0200 Organization: UAS Frankfurt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 510057364475-0001@t-dialin.net Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org X-Reply-To: Igor Zlatkovic List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: > Doh! I implemented difference backwards. I should have been subtracting y - x > (like you did). This means that the seconds function is also wrong. > However, I was trying to show that it is still possible for multiple items in > the duration object to have negative values which the format function will not > handle correctly (i.e. embedded '-' in the output string). See the new patch for > an example. Aaaaaaa... aaa... may the Lord strike me awake, that embedded '-' has escaped my attention. No, embedding a '-' is not an acceptable act, not for a duration format function :-) > I'll start making changes. Eh? Does that mean you wish to fix the format function? Okay with me. I have also done so, but yours is the baby :-) I saw just after realising the existence of that embedded '-' that the format function calls xmlXPathCastNumberToString(), and that means that it may never pass it a negative argument. I then thought about ensuring that all possible arguments to the XPath function are positive. You think this is okay? Ciao Igor RCS file: /cvs/gnome/libxslt/libexslt/date.c,v retrieving revision 1.15 diff -c -r1.15 date.c *** date.c 17 Sep 2002 16:13:44 -0000 1.15 --- date.c 18 Sep 2002 10:15:25 -0000 *************** *** 1058,1076 **** years = (double)(dt->mon / 12); months = (double)(dt->mon % 12); if (secs < 0.0) { secs = -secs; ! *cur++ = '-'; ! } else if (days < 0) { days = -days; ! *cur++ = '-'; ! } else if (years < 0) { years = -years; ! *cur++ = '-'; ! } else if (months < 0) { months = -months; ! *cur++ = '-'; } *cur++ = 'P'; --- 1058,1082 ---- years = (double)(dt->mon / 12); months = (double)(dt->mon % 12); + *cur = '\0'; if (secs < 0.0) { secs = -secs; ! *cur = '-'; ! } ! if (days < 0) { days = -days; ! *cur = '-'; ! } ! if (years < 0) { years = -years; ! *cur = '-'; ! } ! if (months < 0) { months = -months; ! *cur = '-'; } + if (*cur == '-') + cur++; *cur++ = 'P'; From mdev@ardvark.idg.nl Wed Sep 18 06:22:29 2002 Return-Path: Delivered-To: xslt@gnome.org Received: from ardvark.idg.nl (ardvark.idg.nl [62.250.13.24]) by mail.gnome.org (Postfix) with ESMTP id 9434018E95 for ; Wed, 18 Sep 2002 06:22:28 -0400 (EDT) Received: from ardvark.idg.nl (localhost [127.0.0.1]) by ardvark.idg.nl (8.12.3/8.11.1) with ESMTP id g8IANdoB008255 for ; Wed, 18 Sep 2002 12:23:39 +0200 (CEST) (envelope-from mdev@ardvark.idg.nl) Received: (from mdev@localhost) by ardvark.idg.nl (8.12.3/8.12.3/Submit) id g8IANd3M008254 for xslt@gnome.org; Wed, 18 Sep 2002 12:23:39 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: Melvyn Sopacua Organization: IDG.nl To: xslt@gnome.org Subject: Re: [xslt] Testkit Date: Wed, 18 Sep 2002 12:23:39 +0200 X-Mailer: KMail [version 1.4] References: <200209181109.25967.mdev@idg.nl> <20020918054101.Z27778@redhat.com> In-Reply-To: <20020918054101.Z27778@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200209181223.39316.mdev@idg.nl> Sender: xslt-admin@gnome.org Errors-To: xslt-admin@gnome.org X-BeenThere: xslt@gnome.org X-Loop: xslt@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: xslt@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: The Gnome XSLT library mailing-list List-Unsubscribe: , List-Archive: On Wednesday 18 September 2002 11:41, Daniel Veillard wrote: > On Wed, Sep 18, 2002 at 11:09:25AM +0200, Melvyn Sopacua wrote: > > Hi, > > > > I get quite a few diffs when running make check. > > No for me. Only diffs are on DocBook FO generation tests for me. DocBook/FO is indeed one of them. The other one, seems to be an ordering difference in the attributes for t= he=20 META tag, that is consistent throughout the tests. > > Is there a list of 'known issues' with the testkit? > > not really it should be clean. Make sure you have > the latests versions of libxml2/libxslt, check your platform I'm seeing this with libxml2-2.4.23 and libxslt-1.0.20. I assume these are the latest, since there is no md5 or alternate formats= for=20 the libxml2.4.24 file. > versions of make, diff and other tools too for difference in behaviour > from the Linux or Gnu version. Make =3D gmake Difftools are GNU as well. Below is the output inline. If you need it as a file or other files, let = me=20 know. OS: BSD/OS 4.2 --=20 Best regards, IDG.nl Melvyn Sopacua WebMaster First issue: gmake check-local gmake[2]: Entering directory `/home/mdev/_src/libxslt-1.0.20' gmake[3]: Entering directory `/home/mdev/_src/libxslt-1.0.20/tests' gmake[4]: Entering directory `/home/mdev/_src/libxslt-1.0.20/tests/docs' gmake[4]: *** No rule to make target `tests'. Stop. gmake[4]: Leaving directory `/home/mdev/_src/libxslt-1.0.20/tests/docs' gmake[4]: Entering directory `/home/mdev/_src/libxslt-1.0.20/tests/REC1' gmake[4]: Leaving directory `/home/mdev/_src/libxslt-1.0.20/tests/REC1' This ordering difference of the attributes happens a few times: gmake[4]: Entering directory `/home/mdev/_src/libxslt-1.0.20/tests/REC2' 3c3 < --- > =2E.. test-2.5-1.xml compilation error: file ./test-2.5-1.xsl line 6 element=20 exciting-new-1.8-feature xsltStylePreCompute: unknown xsl:exciting-new-1.8-feature compilation error: file ./test-2.5-1.xsl line 2 element stylesheet xsl:version: only 1.0 features are supported 3c3 < --- > test-8-1.xml 3c3 < --- > Running ./bug-33-.xsl on ./../docs/bug-33-.xml 3c3 < --- > Running ./bug-5-.xsl on ./../docs/bug-5-.xml 3c3 < --- > Running ./bug-60.xsl on ./../docs/bug-60.xml compilation error: file ./bug-60.xsl line 6 element foo-of xsltStylePreCompute: unknown xsl:foo-of gmake[4]: Entering directory `/home/mdev/_src/libxslt-1.0.20/tests/xmlspe= c' 2c2 < Extensible Markup Language (XML) 1.0 (Second= =20 Edition)