From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Fabrice BAUZAC-STEHLY Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: repology.el Date: Mon, 25 Jan 2021 13:11:35 +0100 Message-ID: <87h7n5md1k.fsf@mykolab.com> References: <6193374b-a60d-ba82-91b5-afdede18e3bb@yandex.ru> <72871d3a-3b6a-d6fd-01cc-4248f817923c@yandex.ru> <801f93f3-8c1f-5f5f-6351-e1169bc309ae@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6404"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, Ulrich Mueller , emacs-devel@gnu.org, ams@gnu.org, arthur.miller@live.com, dgutov@yandex.ru To: Jean Louis Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 25 13:12:43 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l40ja-0001Yd-U9 for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Jan 2021 13:12:43 +0100 Original-Received: from localhost ([::1]:54954 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l40jZ-0005x0-Uw for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Jan 2021 07:12:41 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50334) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l40ij-0005OX-9u for emacs-devel@gnu.org; Mon, 25 Jan 2021 07:11:49 -0500 Original-Received: from mx.kolabnow.com ([95.128.36.42]:50380) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l40if-0002cI-EG; Mon, 25 Jan 2021 07:11:48 -0500 Original-Received: from localhost (unknown [127.0.0.1]) by ext-mx-out001.mykolab.com (Postfix) with ESMTP id 00AECDD2; Mon, 25 Jan 2021 13:11:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mykolab.com; h= content-type:content-type:mime-version:message-id:in-reply-to :date:date:references:subject:subject:from:from:received :received:received:received; s=dkim20160331; t=1611576699; x= 1613391100; bh=QfZnBeZAAhnpwdd9E/INb0kAOEGReEL8ZIAa/pDDdN8=; b=5 eZra0jBIQ9wPc/QWhYuJUoLeUpnDGn5kxjvRP4MPboUEGtpeyVL/bP+QXO2hnpqw xmaShWWjSghHU1BjYV4BLnWZyd0u4ZdY9Hy8QM2vuBuc31P1aDtBKQ6kib+fXNeY MOMNDiFmwCf9zsixGOuedWc1nG8a3t03D9GDV3ol14ZGwKPmut2QGWjRhhRT/vuR KACPEAYhq6pfA+pnwBw7F15B8k0ENOMDR98mggpo6/6UUdN6fNBaM3BmA9vNF+2R x5hFWtjyWPWrGA4O+6JA/aieOBsAQapJ0bAAFiOjCaefdqJDMZE5g6cBap1d2lEw vLMHSE520RyHedGbCEF9TGlZpuphp4PJid6wnY7qtQGv5anMuSMa5MS7SuHeZxW8 OQj0NsGSmY1FEbQx53UmkPQwVhmhyo7IAlTL6CCtX0C4oEGJSxxq5ilIaiAxlLAE sZ97dyxzSQIScBElZU3vVN1swhX0Oiy1lBStLNFuAJ2i/gdEBEck8zt6qVME8igp eNpMGT/zqtkOFIhBvMDlMalbYXHdKzVmr3Uf/n+Kxmt85K5wO X-Virus-Scanned: amavisd-new at mykolab.com Original-Received: from mx.kolabnow.com ([127.0.0.1]) by localhost (ext-mx-out001.mykolab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Hh8dLwWeDji; Mon, 25 Jan 2021 13:11:39 +0100 (CET) Original-Received: from int-mx003.mykolab.com (unknown [10.9.13.3]) by ext-mx-out001.mykolab.com (Postfix) with ESMTPS id 84C3CD63; Mon, 25 Jan 2021 13:11:38 +0100 (CET) Original-Received: from ext-subm001.mykolab.com (unknown [10.9.6.1]) by int-mx003.mykolab.com (Postfix) with ESMTPS id E00DBA32; Mon, 25 Jan 2021 13:11:37 +0100 (CET) Original-Received: from noon by asus.home with local (Exim 4.94) (envelope-from ) id 1l40iV-0002U9-Lo; Mon, 25 Jan 2021 13:11:35 +0100 In-Reply-To: (Jean Louis's message of "Mon, 25 Jan 2021 06:52:46 +0000") Received-SPF: pass client-ip=95.128.36.42; envelope-from=noon@mykolab.com; helo=mx.kolabnow.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:263381 Archived-At: Jean Louis writes: > I think, but not sure, that schema is pattern on how documents should > be interpreted by software. Without it, certain functions would not > work. In my opinion it is one way of programming by pattern and this > part of software. I happen to have worked on software that works with XML and which provides an XML schema with it. I think the XML schemas (be them Relax-NG or XML Schema Definition (XSD)) only indicate constraints in a tree of XML elements. For example, we can say the following set of constraints in either Relax-NG syntax or XSD syntax: Each element must contain exactly one element, followed by at least 2 elements. Each element can have an optional attribute "name" which value must be boolean, and must contain exactly one element. Each element must contain a string. It is somewhat similar to constraints I impose on the argument of my defun, e.g. "it must be a list with any number of elements, but each element must be a number or a list of strings" So for me an XML schema is something similar to a BNF grammar definition. Why would a schema need to be modified? I think there can be a lot of reasons. There may be several ways to represent the constraints, so another way might be more readable and it would then be a good idea to change it. Or, maybe there is a new version of the schema syntax and we would like to upgrade a schema with the new features of the new version which makes the schema more straightforward to read. Or something in the schema is not sufficiently constrained, so that users using a schema-verification tool would provide values that are not understood by a program, and we would need to change the schema so that users are warned that the thing they are putting in is not right. Or, a program now has extended capabilities which were not envisioned when the schema was written, so we would like to accept more things in XML and for that we would need to change the schema. Concerning the XML-processing software I have worked on, the schema had to be changed from version to version (it was delivered with each version) to cope with new needs and extend the features. It was a schema dedicated to this tool, not a standard supposed to be unique for many tools. But I think even a standard schema should not prevent an implementation to be able to support extensions of the standard schema to add more features. The implementation should be able to not only process XML files that comply to the standard schema, but also XML files that have additions that improve the functionality of the implementation. I don't know for sure whether schemas can be written in a way that never prevent extensions, such as: "each should have one child, but it is allowed to also put any other child under ". But even if there can be such very permissive schemas, we might want the program to come with its alternative schema (with additional features and XML elements and XML attributes) to ease data editing by users, because schemas are also used by XML editors to help the user fill in the blanks. However, a schema indicates types in a (possibly recursive) data structure, but does not otherwise influence how the data are processed. -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6 old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D