-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Michał Górny: > On Thu, 28 Apr 2016 19:41:06 -0400 Göktürk Yüksek > <[email protected]> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> Brian Dolbec: >>> On Thu, 28 Apr 2016 15:39:05 -0400 Göktürk Yüksek >>> <[email protected]> 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 @@ <!ATTLIST catmetadata pkgname CDATA ""> >>>> >>>> <!-- Metadata for a package --> -<!ELEMENT pkgmetadata ( >>>> (maintainer|natural-name|longdescription|slots|use|upstream)* >>>> )> +<!ELEMENT pkgmetadata ( >>>> (maintainer|longdescription|slots|use|upstream)* )> <!ATTLIST >>>> pkgmetadata pkgname CDATA ""> <!-- One tag for each >>>> maintainer of a package, multiple allowed--> @@ -13,9 +13,6 >>>> @@ explicit type) for Gentoo maintainers is prohibited. --> >>>> <!ATTLIST maintainer type (person|project|unknown) >>>> "unknown"> >>>> >>>> - <!-- Natural name for package, example: LibreOffice (for >>>> app-office/libreoffice) --> - <!ELEMENT natural-name >>>> (#PCDATA) >>>>> - <!-- A long description of the package in freetext--> >>>> <!ELEMENT longdescription (#PCDATA|pkg|cat)* > >>> >>> 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.
> As for DOCTYPE, there was no formal decision on that. It's not > technically required, so the GLEP doesn't enforce it. However, I > don't expect it being gone anytime soon. One of the reasons behind > it is that repoman enforces it as part of metadata.xml validation. > If it is to be gone, stable repoman needs to accept it missing at > least for some time. > > There was a proposal to link new/additional schemas in > metadata.xml files. However, I personally don't think we should go > this way. DOCTYPE already proved troublesome (when we switched to > https), and maintaining any kind of schema reference in XML files > doesn't give us any real benefit (we don't enforce any hard > defaults besides languages there, and I don't think many XML > parsers would respect that anyway). > >> I understand that the DTD is more like a super-set, so anything >> that complies with GLEP 68 will comply with the DTD as well. >> However, there is a caveat here: for example the GLEP dismisses >> the list of possible values for <remote-id/> by saying "The list >> of available trackers and their specific identifiers are outside >> scope of this specification." but does not mention where these >> values shall be kept either. The moment we add a new remote-id, >> the xmlschema diverges from the DTD and stops being a subset. > > Well, there is good reason for not hardcoding the list in the > GLEP, and this obviously is to avoid updating the GLEP for every > single change. And yes, as you can see, I didn't point out a > specific location where remote-ids are to be defined to avoid > problems like the one noted below. > > As I see it, we can defer it to some project / wiki page, or > simply keep it in either of the schemas. Either way, we should keep > both schemas reasonably up-to-date. > >> Besides, the PMS says the format of metadata.xml is described in >> DTD. Even if we move to something else, doesn't metadata.dtd need >> to be kept around until the PMS is amended? > > The key point PMS is making is 'outside the scope'. The specific > location is just a minor problem, and it should be updated. I'll > take a look at it. > > Oh, and +1 for the patch. If nobody complains and nobody beats me > up to it, I'll commit it this weekend. > Please hold off the merge. I have found a few more things that require fixing. I'll send a new patch series for review. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJXJFJcAAoJEIT4AuXAiM4zcTMH+wcmYptb9MPo+7oSRx9ViS22 RVwUKiwdb55JmMHLXWu7ATQS+X1Jb5LqlNxIdpUz77zfP9+WFJJagJI9F1oi7a4s e9wi7a1J3H812Xo2JcRZGnp95OX2O/c7dyXCcG5VMwB8kqW8JMykb+QmI0opm9s7 ePX0e1lQ3mhaMy8thTRBZK9a1cA+B86PWBtQRtQtb3leotD06DDnO0sZchLYsDYZ A0qTDOZ+V5t9qJ0EtNJ8jb9T/7dz971noZUwdUDgkveU1Q+3o/IWBzZD765WaPYs dSlWhn8linRLk3UhHe95+vCL0NAuLLdEEPIiNNrLRG3orz/gfbz7kl0E8+JNW58= =DLlT -----END PGP SIGNATURE-----
