Martijn van Beers wrote: > > Hi, > > first bits of my DTD are at > http://www.il.fontys.nl/~sauron/glade.dtd > > comments welcome :) Hi Martijn, I am not very experienced with XML so please excuse any comments that are making wrong assumptions, inaccurate or missing the point :-) 1) You have written a DTD that specifies all properties as attributes, at the moment they are all elements. Is it your aim to change the XML structure this drastically? If not, I reckon that the ATTLIST entries should be defined as sub elements. 2) If you do mean to change to using attributes, shouldn't all the 'name' attributes be of type ID so that they are unique and IDREFable? 3) There is no PI mentioning an 'encoding' which is probably necessary for any non-english languages. 4) You have defined all the numeric attributes as NMTOKEN and all string attributes as CDATA even if they could be defined more restrictively as NMTOKENs (eg widget class or signal handler). Is there a reason for this? 5) You don't use IDs and IDREFs at all even though they could provide a great deal of xref validation. 6) There is no mention of white-space handling which I reckon is needed if the .glade files are to be easily human-readable. 7) I like the modular principle but wouldn't it be easier if widget properties were grouped in the same way that Gtk does. What I mean is that window/widget/misc properties could effectively be inherited. 8) There are no attribute enumerations so that validation of say widget classes is not possible. I guess that these should be modular and congruent with the Gtk/Gnome enums. 9) There is still no differentiation between the <signal> element and the <signal_to_emit> property of <accelerator>. These should be probably also be ID/IDREFs in any case. 10) Do you have plans to define some <!ENTITY>s, I reckon that they'd be vital to ensure a valid XML structure. 11) Have you thought about using an XML-DATA schema? The w3c NOTE at http://www.w3.org/TR/1998/NOTE-XML-data offers most of what (I think) that you want with validation and so on. I don't know what status the submission has but it may be worth hanging on for a better solution. I am worried that you are aiming to change the document structure radically. If this is your intention, please would you explain exactly what it is that you are suggesting. Glade is supported by many third-party packages and IMO owes some of its success to the wide choice of languages and libraries that would all need to change. The present structure is understood and works and I reckon that Glade would lose a lot of support especially if the new data structure and DTD aren't right first time. Apart from the clash between the two types of <signal> elements, I don't see any real problems with the present structure. I _could_ list every single thing that I own, down to the last piece of paper, and there are systems and standard ways to do it but, hey, life is too short. There are some improvements to Glade that would be more useful to me than a super-rigourous XML structure, working styles would be great. I don't mean to carp, these are just some initial thoughts and in no particular order. I can hear the buzzing of hornets already :-) Regards, Dermot +---------------------------------------------------------------------+ To unsubscribe from this list, send a message to [EMAIL PROTECTED] with the line "unsubscribe glade-devel" in the body of the message.
