From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D0094138216 for ; Sun, 1 May 2016 22:43:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A761522402E; Sun, 1 May 2016 22:43:10 +0000 (UTC) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AC458E0850 for ; Sun, 1 May 2016 22:43:09 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id DADBE20E6B for ; Sun, 1 May 2016 18:43:08 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 01 May 2016 18:43:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=yRvqSRHD3Q/LEo3 1kpOoTPCT/zM=; b=G+5/kbUBAB3GO/ZjFHrqYQMM36HBSNNepVpUSffrShKKOfp eDON7HDH1U4+WQAGb41QhL44loTlVwmIfACh9hnf6DzHWbYFi/a2YoiCoXt6ZpEr OSOg1PZ2Gumx4BP1s1YOGyKfKdTWVfe4CiEv9p3EqfoTmaHNRxOEJVv/9I78= X-Sasl-enc: Hl4BbCx00yqJM/W2nE12ldEtp10ieHOE5tcpKuShD8UB 1462142588 Received: from 127.0.0.1 (unknown [198.50.200.139]) by mail.messagingengine.com (Postfix) with ESMTPA id B8CAE680120; Sun, 1 May 2016 18:43:06 -0400 (EDT) Subject: Re: [gentoo-dev] [PATCH] metadata.dtd: Remove obsolete element per GLEP 68 To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= References: <1461872345-5590-1-git-send-email-gokturk@binghamton.edu> <20160428140411.350d6e3d.dolsen@gentoo.org> <57229F92.8040608@binghamton.edu> <20160429145753.3b43a1b9.mgorny@gentoo.org> <57245262.7090902@binghamton.edu> <20160430133408.14c4b900.mgorny@gentoo.org> Cc: gentoo-dev@lists.gentoo.org From: =?UTF-8?B?R8O2a3TDvHJrIFnDvGtzZWs=?= X-Enigmail-Draft-Status: N1110 Message-ID: <5726866E.7000205@binghamton.edu> Date: Sun, 1 May 2016 18:42:54 -0400 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <20160430133408.14c4b900.mgorny@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 84e92e81-01f4-4e34-9747-65d9cee726fb X-Archives-Hash: 4672d3eed054aab6e03fe1d52b3593ef -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Michał Górny: > On Sat, 30 Apr 2016 02:36:18 -0400 Göktürk Yüksek > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> Michał Górny: >>> On Thu, 28 Apr 2016 19:41:06 -0400 Göktürk Yüksek >>> wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >>>> >>>> Brian Dolbec: >>>>> On Thu, 28 Apr 2016 15:39:05 -0400 Göktürk Yüksek >>>>> wrote: >>>>> >>>>>> --- metadata.dtd | 5 +---- 1 file changed, 1 >>>>>> insertion(+), 4 deletions(-) >>>>>> >>>>>> diff --git a/metadata.dtd b/metadata.dtd index >>>>>> 7626a57..b608852 100644 --- a/metadata.dtd +++ >>>>>> b/metadata.dtd @@ -3,7 +3,7 @@ >>>>> pkgname CDATA ""> >>>>>> >>>>>> ->>>>> >>>>>> (maintainer|natural-name|longdescription|slots|use|upstream)* >>>>>> )> +>>>>> (maintainer|longdescription|slots|use|upstream)* )> >>>>>> @@ >>>>>> -13,9 +13,6 @@ explicit type) for Gentoo maintainers is >>>>>> prohibited. --> >>>>> (person|project|unknown) "unknown"> >>>>>> >>>>>> - - >>>>> natural-name (#PCDATA) >>>>>>> - >>>>>>> >>>>>> >>>>> >>>>> Isn't this almost obsolete? it's now xmlschema... And I >>>>> hope to have the new repoman with it out this weekend :) >>>> >>>> Does GLEP 68 explicitly declare metadata.dtd obsolete? I see >>>> that the example metadata.xml on the GLEP is missing DOCTYPE, >>>> are we getting rid of those too? >>> >>> No, and I don't know. >>> >>> metadata.dtd is still required by many tools, and as such it >>> makes sense to keep it. However, we may want to put some >>> warning that it's not very strict, and allows major structural >>> violations due to technical limitations. >>> >> After a discussion with ulm on IRC, we agreed that the following >> makes sense: "the format of the metadata is defined in GLEP 68. >> the syntax is defined in metadata.dtd. The xml-schema can be used >> for stricter validation checks." If you have no objections, I >> will update devmanual based on this description. > > What is the precise difference between 'format' and 'syntax' here? > I'm no native English speaker, and I don't see any obvious split > of responsibility between the two here, and I'm pretty sure this > will be quite confusing for other people as well. > I admit that it is hard to make a clear distinction. When I look at the GLEPs replaced by GLEP68, I see that they propose a change for metadata.xml and explain how that affects metadata.dtd. GLEP34 has "The DTD file would need to be updated to include the element.", GLEP46 explicitly says "metadata.dtd should allow the use of a upstream tag in metadata.xml.", GLEP56 points to #199788 which required DTD to be patched. GLEP68 is rather vague as to how metadata.dtd is affected. It doesn't say whether it should be updated or if it has any role at all. GLEP68 provides a single human readable specification for the metadata format. In that respect, however, the DTD along with the comments in it is just as expressive, if not better: a developer can read through the DTD and learn all the information contained in the GLEP, plus the remote-id values which are not part of the specification for reasons you stated earlier. And that was the reason why I used the term "syntax": the DTD lists all the allowed elements, attributes, and values for the metadata that should be used in conformance with the GLEP . In the end, the DTD isn't much better than the GLEP as a human readable document and does a worse job than the xsd as a machine readable document for validation purposes. Once repoman switches to the xml-schema, there would be no good use for it and I don't know what should be done about the DTD. I think that until we figure it out, we should keep it in sync with the GLEP and xsd. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJXJoZnAAoJEIT4AuXAiM4z1tsIAKj7/dBAQcsttsMxJbOlM4Ew GMiS4LK3/QZqlEM8ixL3otKptbWDhyJiB+c7cafyAamgFKGprWYnk2X+zFEfgmRw adjWjH4fwtS/AW/VFU4aeE4cYVOGF0ju0dh6ZO6bAYl4MJtcS5xVtRdDkIm3eacX OMjdzvuKgwYKiYxRu2AmCLS2+jExEj48mDEa9jPZMOb14xEljsRNjF76kPr6o8eG /XJ6t5o4+Ckkpwx4kckBUDtSj6ipuPz0SqwVrYLxhogwDas6E0h9BovGuaeLmgVM GYCXJzsetuWIvbRxJJhH9cTADjCwAt7SYGfdA72fknnmf0QZgScPjBnLUQSn2G4= =/CcU -----END PGP SIGNATURE-----