On Thu, 28 Apr 2016 19:41:06 -0400
Göktürk Yüksek <gokt...@binghamton.edu> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Brian Dolbec:
> > On Thu, 28 Apr 2016 15:39:05 -0400 Göktürk Yüksek
> > <gokt...@binghamton.edu> 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.

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.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

Attachment: pgpV7EOiFf6bO.pgp
Description: OpenPGP digital signature

Reply via email to