[
Lists Home |
Date Index |
Thread Index
]
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?
>>>
>>>
>><snip/>
>>
>>
>>
>>>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 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
>ignorable).
>
>
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.
cheers,
Burak Emir
http://lamp.epfl.ch/~buraq
|
