On Tue, Nov 02, 1999 at 02:31:54PM +0000, Dermot Musgrove wrote:
> I am not very experienced with XML so please excuse any comments that are
> making wrong assumptions, inaccurate or missing the point :-)
Neither am I :)
>
> 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.
Yes, that's my aim. As Daniel Veillard said it, elements are to define
structure, and the structure should be as close to gtk+'s structure
as possible
> 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?
Hmm, I'll look into this. As I said, I'm pretty new to XML too, and
I didn't realize this existed
> 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?
Again my inexperience with XML :)
>
> 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.
You need to specify white space in the DTD!?!
>
> 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.
How would you do that?
> 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.
I don't understand what you're saying here.
> 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.
What do you mean there's no differentiation? The accelerator property
is an attribute, and the <signal> is an element.
> 10) Do you have plans to define some <!ENTITY>s, I reckon that they'd be
> vital to ensure a valid XML structure.
I do have some entity's, but from what I have heard, they are just a
sort of macro. I don't see how they have anything to do with validity
checking.
> 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'll take a look at that.
> 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.
I won't start on putting any support for the DTD in glade before I
have the DTD right.
> There are some improvements to Glade that would be more useful to me than
> a super-rigourous XML structure, working styles would be great.
You're free to work on those :) Although I don't think they're very
useful anymore with the theme stuff.
Martijn
--
Martijn van Beers <[EMAIL PROTECTED]>
'Don't worry if it sounds odd. Believe me, you are talking to
someone who has seen a lot of stuff that is odd. And I don't
mean biscuits.' --- Arthur Dent
+---------------------------------------------------------------------+
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the line "unsubscribe glade-devel" in the body of the message.
