After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 578465 - Glade catalog DTD needs update
Glade catalog DTD needs update
Status: RESOLVED OBSOLETE
Product: glade
Classification: Applications
Component: documentation
git master
Other Linux
: Normal normal
: ---
Assigned To: Glade 3 Maintainers
Glade 3 Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-04-09 09:56 UTC by David King
Modified: 2018-03-26 15:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix documentation of glade-catalog element (938 bytes, patch)
2009-04-09 09:57 UTC, David King
none Details | Review
Adds depends element to DTD (831 bytes, patch)
2009-04-09 15:38 UTC, David King
none Details | Review
Updated patch, so that gtk+ catalog successfully validates (37.45 KB, patch)
2009-04-10 15:45 UTC, David King
none Details | Review

Description David King 2009-04-09 09:56:36 UTC
http://glade.gnome.org/docs/catalogintro.html (and the corresponding file in the latest SVN) contains an incorrect attribute in the "glade-catalog" element. It should be "requires" but is currently "depends".
Comment 1 David King 2009-04-09 09:57:44 UTC
Created attachment 132396 [details] [review]
Fix documentation of glade-catalog element
Comment 2 Tristan Van Berkom 2009-04-09 15:01:22 UTC
Actually its "depends", look at gnome.xml.in for an example
of how its used (the gnome catalog depends on the gtk+ catalog
being loaded in Glade 3 first, so that the gnome plugin can
derive adaptors from the gtk+ plugin).

Requires is when a project uses an object that is in another
catalog besides the gtk+ catalog - "requires" should be
written out (in the Glade file) for ever plugin that is 
used by the resulting Glade file.
Comment 3 David King 2009-04-09 15:38:47 UTC
Created attachment 132412 [details] [review]
Adds depends element to DTD

Hmm, so the DTD needs fixing then? I tried to use it to validate a simple catalog and xmllint complained about the missing attribute without the addition of the "depends" element.
Comment 4 Tristan Van Berkom 2009-04-09 15:58:03 UTC
The DTD for the Glade catalog definitely needs fixing, sorry
for having completely neglected its importance.

We should actually add a rule to the plugin directories to
check that catalog file valid with the DTD (thus forcing
us to update our DTD when expanding on the format)... 

For now I'm renaming the bug for easy reference.
Comment 5 Tristan Van Berkom 2009-04-09 16:05:29 UTC
The DTD for the Glade catalog definitely needs fixing, sorry
for having completely neglected its importance.

We should actually add a rule to the plugin directories to
check that catalog file valid with the DTD (thus forcing
us to update our DTD when expanding on the format)... 

For now I'm renaming the bug for easy reference.

As for the patch, would you mind trying for a complete
update (i.e. validate it against gtk+.xml) ?

If I would include your patch as is you would just
hit a wall on the next unrecognized tag...
Comment 6 David King 2009-04-09 17:03:11 UTC
(In reply to comment #5)
> As for the patch, would you mind trying for a complete
> update (i.e. validate it against gtk+.xml) ?

No problem, I will do this over the weekend.

> If I would include your patch as is you would just
> hit a wall on the next unrecognized tag...

Yeah, I realised after I submitted the patch that this may be the case. Thanks for your comments.
Comment 7 David King 2009-04-10 15:45:20 UTC
Created attachment 132476 [details] [review]
Updated patch, so that gtk+ catalog successfully validates

I updated the DTD (and gtk+ catalog), and xmllint reports no errors. Glade seems to run with no problems, although I haven't tested it extensively.
Comment 8 Tristan Van Berkom 2009-04-10 16:28:59 UTC
Curiously, is there a reason why functions in <glade-widget-class>
need to have a specific order ? currently the core doesnt need
any specific order here... 
Comment 9 David King 2009-04-11 13:14:51 UTC
(In reply to comment #8)
> Curiously, is there a reason why functions in <glade-widget-class>
> need to have a specific order ? currently the core doesnt need
> any specific order here... 

In order to validate against the DTD, the XML elements must be declared in the order that they were declared in the DTD. As you say, there is no need for the specific order, other than to get the validation to complete without errors.
Comment 10 Tristan Van Berkom 2009-04-11 14:11:02 UTC
Did some quick googling, because I wont just believe that
DTD is so lame its not usable for us.

 - We dont require tags to be in a specified order (only
   widget groups should come after classes, afaics, thats
   the only constriction)
 - The DTD should fail only on unrecognized tags or properties,
   or if widget classes come after widget groups

I found this old email, which may or may not be helpful at
the moment:
  http://www.stylusstudio.com/xsllist/200107/post21060.html

Comment 11 David King 2009-04-11 16:53:40 UTC
(In reply to comment #10)
> Did some quick googling, because I wont just believe that
> DTD is so lame its not usable for us.
> 
>  - We dont require tags to be in a specified order (only
>    widget groups should come after classes, afaics, thats
>    the only constriction)

That's already handled by the glade-widget-classes definition, which is good.

>  - The DTD should fail only on unrecognized tags or properties,
>    or if widget classes come after widget groups
> 
> I found this old email, which may or may not be helpful at
> the moment:
>   http://www.stylusstudio.com/xsllist/200107/post21060.html

There are only two options covered in the XML specification: http://www.w3.org/TR/REC-xml/#sec-element-content
We can either use the ',' separator between elements, which specifies an order, or we can use the '|' which specifies "either ... or ..." behaviour. If we go for unordered behaviour, as detailed in the link that you posted, we lose the ability to constrain, for example, the number of subelements, which seems worse than constraining the order, even though the constraint is imposed by the XML specification and not by Glade.

I'm no XML expert though, the above comes purely from reading the specification and doing a bit of googling, like yourself.
Comment 12 GNOME Infrastructure Team 2018-03-26 15:07:57 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glade/issues/36.