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 A8A1E138216 for ; Mon, 2 May 2016 07:05:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E508E21C012; Mon, 2 May 2016 07:05:35 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 E80A021C002 for ; Mon, 2 May 2016 07:05:34 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id BA1FC34099A; Mon, 2 May 2016 07:05:32 +0000 (UTC) Date: Mon, 2 May 2016 09:05:26 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: =?UTF-8?B?R8O2a3TDvHJrIFnDvGtzZWs=?= Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH] metadata.dtd: Remove obsolete element per GLEP 68 Message-ID: <20160502090526.0f272759.mgorny@gentoo.org> In-Reply-To: <5726866E.7000205@binghamton.edu> 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> <5726866E.7000205@binghamton.edu> Organization: Gentoo X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/w0R3zc=8LFs7zTayElhMRyM"; protocol="application/pgp-signature" X-Archives-Salt: 5a3404de-3a61-44ec-9a11-477b1dea0e0f X-Archives-Hash: 0df599b42b31e846996bc2b2ec65c669 --Sig_/w0R3zc=8LFs7zTayElhMRyM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 1 May 2016 18:42:54 -0400 G=C3=B6kt=C3=BCrk Y=C3=BCksek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Micha=C5=82 G=C3=B3rny: > > On Sat, 30 Apr 2016 02:36:18 -0400 G=C3=B6kt=C3=BCrk Y=C3=BCksek > > wrote: > > =20 > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > >>=20 > >> Micha=C5=82 G=C3=B3rny: =20 > >>> On Thu, 28 Apr 2016 19:41:06 -0400 G=C3=B6kt=C3=BCrk Y=C3=BCksek=20 > >>> wrote: > >>> =20 > >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > >>>>=20 > >>>> Brian Dolbec: =20 > >>>>> On Thu, 28 Apr 2016 15:39:05 -0400 G=C3=B6kt=C3=BCrk Y=C3=BCksek=20 > >>>>> wrote: > >>>>> =20 > >>>>>> --- metadata.dtd | 5 +---- 1 file changed, 1 > >>>>>> insertion(+), 4 deletions(-) > >>>>>>=20 > >>>>>> diff --git a/metadata.dtd b/metadata.dtd index=20 > >>>>>> 7626a57..b608852 100644 --- a/metadata.dtd +++ > >>>>>> b/metadata.dtd @@ -3,7 +3,7 @@ >>>>>> pkgname CDATA ""> > >>>>>>=20 > >>>>>> - >>>>>> =20 > >>>>>> (maintainer|natural-name|longdescription|slots|use|upstream)* =20 > >>>>>> )> + >>>>>> (maintainer|longdescription|slots|use|upstream)* )> > >>>>>> @@ > >>>>>> -13,9 +13,6 @@ explicit type) for Gentoo maintainers is > >>>>>> prohibited. --> >>>>>> (person|project|unknown) "unknown"> > >>>>>>=20 > >>>>>> - - >>>>>> natural-name (#PCDATA) =20 > >>>>>>> - > >>>>>>> =20 > >>>>>> =20 > >>>>>=20 > >>>>> Isn't this almost obsolete? it's now xmlschema... And I > >>>>> hope to have the new repoman with it out this weekend :) =20 > >>>>=20 > >>>> 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? =20 > >>>=20 > >>> No, and I don't know. > >>>=20 > >>> 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. > >>> =20 > >> 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. =20 > >=20 > > 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. > > =20 > 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. >=20 > 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 It's not better. As you can have seen, numerous developers were adding incorrect attributes and sub-elements to downstream and upstream s based on DTD. The comments there didn't help. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/w0R3zc=8LFs7zTayElhMRyM Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXJvw2XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOTqwP/R1aKVNLb4u3VYugw0Wac+ey O9kqwGBbkDOrqJtUsttkzjQ4rDJ5KFzyf7DYO8sStI8MEgXI8hn7HgpjKuhHeCQa qV57W7cy3YmEIt6A6/6sDt6NHekoXIpwk1amz2an14TYx9a/bF03tnY1fMogxScL 0SP2pjXfayQrJ2bW0nuu7uN7V4mP+TS9483FxW4kcZ61mhWvhWO5buJvN/OcNCHu ftaoQDJXc4WHSPxAkHSrPsqRaQsyrGcW9eQgZpyW+A4YBo3rljA0eRuNEx89vD55 vYqbP2lJk0nZOFuSijq5sP1Wc3wFHh1DVcr9i+JsKwEJVKwPW6azRPZBnO80TR6B 1Tm2OW05iFslxwPlKBNOeYXHZ0ANo78hZMiIgqP/3B1E2eYeWz/c1Uor4zT/sqgf e7E6sg9pHT/oOf9ynIe9PIitB0h14FztEPC3IGaonc/ezD+8TTCMszWFeBtUtpFR VY92puv7g1S/j6C/LEWySoKF9G7NClgsbCGsdhhF4IPU7SeCx6VbPWWyKbaho4E7 ZWOlaJ+yIhOx58HFsRTa1ja+Ef12BjEzVqWE9tpJG2ErOzW1RzELXTIF8UPRiDDt KdWb/O0lkCALlm3R8tsVsLdZ38V92e2fMfP9o2HTkF6UrzRAMkX93vG2qAs/+gz2 7LZbINnBiFbSlCKSCUi+ =WUmv -----END PGP SIGNATURE----- --Sig_/w0R3zc=8LFs7zTayElhMRyM--