From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Problems with xml-parse-string Date: Sat, 25 Sep 2010 11:00:11 -0400 Message-ID: <87iq1tg96s.fsf@stupidchicken.com> References: <87vd5x7ty2.fsf@stupidchicken.com> <87vd5wo48a.fsf@stupidchicken.com> <8739t03q2g.fsf@stupidchicken.com> <87k4mb2mfu.fsf@stupidchicken.com> <87pqw3nm4y.fsf@stupidchicken.com> <87iq1v0yi2.fsf@stupidchicken.com> <87bp7nvt9j.fsf@stupidchicken.com> <8739syls92.fsf@stupidchicken.com> <8339syrlto.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1285426829 28201 80.91.229.12 (25 Sep 2010 15:00:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 25 Sep 2010 15:00:29 +0000 (UTC) Cc: Lars Magne Ingebrigtsen , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 25 17:00:27 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OzWEj-0000eV-7l for ged-emacs-devel@m.gmane.org; Sat, 25 Sep 2010 17:00:25 +0200 Original-Received: from localhost ([127.0.0.1]:33877 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OzWEi-0000yH-MU for ged-emacs-devel@m.gmane.org; Sat, 25 Sep 2010 11:00:24 -0400 Original-Received: from [140.186.70.92] (port=44187 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OzWEc-0000xe-4f for emacs-devel@gnu.org; Sat, 25 Sep 2010 11:00:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OzWEb-00026d-4S for emacs-devel@gnu.org; Sat, 25 Sep 2010 11:00:18 -0400 Original-Received: from pantheon-po16.its.yale.edu ([130.132.50.72]:42625) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OzWEb-00026J-2p; Sat, 25 Sep 2010 11:00:17 -0400 Original-Received: from furry (adsl-99-103-105-16.dsl.wlfrct.sbcglobal.net [99.103.105.16]) (authenticated bits=0) by pantheon-po16.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o8PF0DjJ028407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 25 Sep 2010 11:00:14 -0400 Original-Received: by furry (Postfix, from userid 1000) id D324116D402; Sat, 25 Sep 2010 11:00:11 -0400 (EDT) In-Reply-To: <8339syrlto.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 25 Sep 2010 15:31:47 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:130849 Archived-At: Eli Zaretskii writes: >> > You are overselling your case. >> >> I give up. > > That's a pity. > > Chong, I'd suggest trusting Lars's instincts and experience a bit > more. OTOH, if you indeed want to see valid technical arguments for > his suggestion, you should request the same from the opposite views. > We should either judge intuition against intuition or specific > arguments vs specific arguments. I saw no practical arguments to back > up the other view, only academic ones. That's unfair, IMO. Well, I'm sorry if this is unfair, but in such a situation---there are numerous third-party packages requiring xml.el; a cursory search on emacswiki showing five or six---the onus of proof is on the proponent of the compatibility-breaking change. I've looked at the three formats, and the examples given; and maybe I'm just being dense, but I just don't see sufficient advantage. I'm open to adding a flag to the parse functions that toggles between the old xml.el format and a new format; but the trouble is that if we're going to offer a new alternative format, it becomes hard to justify making that new format yet another non-standard one (Lars'), rather than something other people are already using (sxml). That's why I think it's better to work on improving the accessor functions instead.