[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] hivexml - Flattened vs. Expanded XML

We are interested in seeing if specific registry keys are present or not. 
The problem with the standard .reg text format is that we would then need to write a parser for it, rather than simply using our XML parser. 
However, we haven't made a decision on this. That's why I sent the query.

Yes, I can imagine several XPath queries that I might want to write as well. But I don't know if anybody is actually doing that. Hence my question. Is anyone using XML for registry entries in a production environment?

On Mar 19, 2010, at 2:34 PM, Charles Duffy wrote:

This would be very much dependent on the kind of processing desired; I can immediately see several XPath queries I might want to write which would be unwieldy to represent without the tree structure preserved.

Flattening the document removes much of the utility of XML-based toolchains, while still paying a penalty in storage size and parser complexity; at that point, why not just export to the conventional .reg text format?

On Fri, Mar 19, 2010 at 3:45 PM, Simson Garfinkel <simsong acm org> wrote:

Greetings. I am new to this mailing list.

We have been working with XML for digital forensics. One of the areas that we wish to create a schema for is the representation of registry entries.

We are interested in hivexml as a tool for extracting the registry as an XML representation.

In our discussion with possible users, we have generally come to the conclusion that it is useful to represent each XML key as a fully expanded path, rather than preserving the tree structure of the registry hive. Although this may seem verbose, it makes processing the data significantly easier.

Is working with the hivexml system in a production environment? If so, do you have any thoughts on this matter?

You can find an example of the digital forensics XML at:


Simson Garfinkel

Libguestfs mailing list
Libguestfs redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]