Lists Home |
Date Index |
- To: email@example.com
- Subject: Re: [xml-dev] Describing hierarchies with XML
- From: Frans Englich <firstname.lastname@example.org>
- Date: Wed, 3 Nov 2004 10:26:41 +0000
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org>
- User-agent: KMail/1.7
On Tuesday 26 October 2004 08:25, Frans Englich wrote:
> Hello all,
Alexander, Hunsberger, Liam, thanks for your replies.
> I have trouble determining the optimal design/format for an XML
> document. The situation is identical to if each entry in a MS
> Windows/KDE/GNOME start menu were represented by an XML document, and that
> its hierarchical position(it's category) should be described.
> An example: the program Calculator's XML document looks like this:
> And I want to describe that it should be located in
> /Menu/Programs/Utilities. One possibility is:
> But I don't find it XML-like, and it must be troublesome when it comes to
> interpreting the data for using it; it requires resorting to string parsing
> instead of using the DOM.
> Another possibility is:
> That is, the hierarchy translates directly to the XML document where each
> category is an element.
> No matter what solution, it should be described in an XML Schema, and
> should be possible to validate. Instances will be read and computed with
I was unclear when I described the problem; it was not the menu which should
be described, but each entry in the menu's position in the menu. However,
when judging from your explanations, it would be solved in a similar way;
each element mapping to a category and nested in an identically corresponding
hierarchy(linearly), and then normalize such that names, icons, and other
"data" are separated. (right?)
I have another question, related to describing hierarchies: describing files
Let's say that for each file(in a directory hierarchy) we have an XML document
representing it, and it should specify the file's location in the hierarchy,
such that one can find out where it is located by only inspecting the XML
document for the file. Would this be appropriate?
- The path is /foo/bar
- Its path can be found by traversing path.
For simplicity's sake, we can assume that path in all fileS have the same
starting point(the paths are either absolute, or have the same relative
starting point..) -- would it then still be best to go XML instead of simply
having the whole path in a string? Yes, I doubt, because it seems massively
slow and I have never seen anyone do it which makes it feel like trying to
innovate(or I'm simply failing to realize the power of XML?).
The actual purpose is reports from a regression framework, which tell in what
file a certain test failed, and then the user is supposed to be able to do
queries similar to "show failures of text X in directory foo" and then the
reports which are generated by test X, and are in directory foo, are
To paraphrase the free desktop spec; it is as if we would express the Desktop
Entry format in XML, and now are to implement the Categories directive.