Re: [hfdb] SQL db and XML

[Till Kamppeter]

Zenaan Harkness wrote:
> Till and James (and everyone reading), I seek your comments on these
> assertions/ thoughts:
>
> * I would be very surprised if it is not close to trivial to generate
> XML output from an SQL database.

I think it is no problem to convert from SQL to XML and vice versa. Each 
record in a data table will be one XML file. All links between different 
data tables must be somehow described in XML (for example list of 
supported printers in every driver's XML file). So one could run an SQL 
database on the server and for a local database (for example used by the 
distro's setup tool) one downloads the set of XML files.

> * Any flat file format is easy to version control.

Yes, it is like the files of a source tarball, so one easily use a 
version control system for source code, like CVS or Subversion.

> * We should be version controlling our data.

That is important. On linuxprinting.org this is done for example.

> * It would be nice for our team to be able to enter data into flat (XML)
> files.

On linuxprinting.org this is the usual way to enter data. But I am 
thinking about implementing also a web interface for visitors to be able 
to enter data easily. Naturally such data has to be checked by the team 
before being added to the official database. A web interface can either 
produce XML files or enter the data into an SQL database.

> * XML files can be easily imported into an SQL database.

That seems to be true. If the XML is the correct structure a program 
simply puts the contents of each data field in the XML file into the 
appropriate field of the SQL data record.

> * We will get higher quality reports from an SQL db than from a "bunch
> of XML files" (unless we first import those files into a RDBMS).

You mean that one can get statistics more easily from an SQL database?

> * Whether we use an SQL db or XML files for storage, we will be defining
> "fields", "types", etc.
>
> * Without an XML schema to validate XML data or 'content' files against,
> at some point down the line we will have to reconcile what should be
> indentical field entries in different records, but are actually
> different/ unique entries due to spelling and even perhaps even ordering
> differences (eg. Matrox Millenium vs Millenium, Matrox - although
> perhaps spelling will be our only issue?).
>
> * An XML schema and an SQL schema serve a similar purpose (at least for
> us).
>
> * We don't need an XML schema to start creating "device entries" as XML
> files.
>
> * If we start creating XML files, we will pretty quickly need to start
> discussing what field names to use, etc;
> and this is essentially the same as defining an implicit schema, or a
> normalized SQL db table structure.
>
>
> QUESTION:
> * Does anyone here know much about XML processing yet?
>
>
> I'll try to find out about Postgres and importing XML files this week.


   Till