OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Describing hierarchies with XML

[ Lists Home | Date Index | Thread Index ]
  • To: xml-dev@lists.xml.org
  • Subject: Re: [xml-dev] Describing hierarchies with XML
  • From: Frans Englich <frans.englich@telia.com>
  • Date: Wed, 3 Nov 2004 10:26:41 +0000
  • In-reply-to: <200410260825.54435.frans.englich@telia.com>
  • References: <200410260825.54435.frans.englich@telia.com>
  • 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:
> <program>
> 	<name>Calculator</name>
> </program>
> And I want to describe that it should be located in
> /Menu/Programs/Utilities. One possibility is:
> <program>
> 	<category>/Menu/Programs/Utilities</category>
> 	<name>Calculator</name>
> </program>
> 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:
> <program>
> 	<category>
> 			<menu>
> 				<programs>
> 					<utilities/>
> 				</programs>
> 			</menu>
> 	</category>
> 	<name>Calculator</name>
> </program>
> 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.[1] 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 
in directories.

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?

		<directory name="foo">
			<directory name="bar">
				  - 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.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS