[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Describing hierarchies with XML

dynamically generate schema files
Frans Englich wrote:

>On Wednesday 03 November 2004 10:51, Burak Emir wrote:
>>Frans Englich wrote:
>>>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?
>>>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
>>>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 returned.
>>Data (like a path) should always be represented in a form that allows to
>>easily do what one wants to do with it.
>>If somewhere in your regression test framework, you need to make a
>>system call, you will need a string representation.
>>If that is the *only* thing for what you need the path (anticipating all
>>future extensions things of your program), then I don't see why you
>>would want to map the tree structure in your XML document.
>>On the other hand, if you have some other use for the path (which would
>>need parsing the string), it might be nice to parse it once and for all,
>>and convert it back to string just for the system calls from above.
>In this particular case a possibility could be to have both an element 
>representation, and the path in an attribute, for example.
[Singing the song of OO abstraction] "Model common things only once."

Avoid having the same thing represented twice. This will cause confusion 
(maybe not you, but the poor guy who has to maintain your code later on).

For which things does one need the string? For which should one use the 
tree nodes?

If you data model does not tell how and for what one can use the data, 
it will lead to confusion. ("show me your tables I shall not need your 
flowcharts ... they will be obvious" :-)

>Since a central use is selecting the fileS on the basis of an individual 
>directory or directory-series its path is part of, that means an element 
>representation is of interest, AFAICT. But otoh, if they all have absolute 
There may be many element representations.... like <dir name="foo"><dir 
name="bar"><testfile name="..."/></dir></dir>

>paths, then an XSLT could simply do starts-with or contains, to get the 
>node-set, but perhaps that leads to ordinary escaping issues, and 
>nevertheless is restraining(perhaps the performance differences are 
Performance is the last thing to worry about. I find code elegant and 
clear if it uses as little symbols as possible (the fewer lines of code, 
the better), but nevertheless is not cryptic. The data representation 
one chooses should support writing elegant code, but this depends of 
course on the language one codes in.

Burak Emir



Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.