Re: [hfdb] Re: Grand Unified Hardware Database

[Zenaan Harkness]

On Fri, 2004-07-23 at 07:36, Richard Stallman wrote:
>     You have a few placeholders there.  FOOBAR is really Vendor+Device. 
>     "driver" is really driver+revision.  It cries out for a Vendor table, at
>     least.  
> 
> I was thinking of FOOBAR as just the manufacturer, and 33 is the model number.
> 
>     The real question is: how will we learn that mumble supports FOOBAR?  Is
>     someone going to enumerate all the driver-device pairs?  I don't think so.
>      I think driver writers will state what chipsets (or similar) they
>     support, and manufacturers will state what chipsets they use (sometimes,
>     or driver writers will discover it).  Only by relating though the shared
>     information will it be possible to derive the the driver-device pairs.  
> 
> If including chipset info in each entry helps us do the work, by all
> means let's include it.  I'm not drawing a line in the sand and saying
> "Don't add any other info whatsoever".  What I'm saying is that we
> have to include only the essential minimum.  Otherwise we will never
> really get it started.  Please don't think about what would be nice to
> add--at least, not now.

There are two issues here - making sure we have enough data do actually
produce the reports and have a useful database. There's no disagreement
on making sure we have enough,

> In a year, if things are going well, then you
> can suggest things to add, and maybe we will be able to add them.

however I imagine that "I as end user" submitting data about my
particular modem, will be in the best position to submit all the
information that I know about it right then.

James, I don't imagine you're suggesting to try and maximise the data we
collect - I see that you are trying to maximize the utility of the data,
and if we enter data, it should cross reference (as much as practicable)
with other data already, or "obviously will be coming" into the
database. Would that be a fair assessment?

So then the only remaining question is what storage format to use.

XML has certain syntactic overhead. I don't see that as particularly
significant though.

XML does not have built in data validation facilities. This can however
be "mostly" implemented with validating schemas and the like.

However, James has experience - in fact it's his profession, his
expertise - in implementing the various constraints, data normalization,
etc, in an RDBMS.

I believe that, today at least, the (free even) tools available for such
work are far superior when working with an RDBMS that with XML files.

So there is significant leverage to be gained, in schema design, data
validation and constraints checking, etc, when we utilize James' skills
in this regard.

Alternatively, if someone equivelantly skilled in XML can step forward
and offer the equivalent, that would be feasible, although I actually
suspect would require more effort.

James I do have one remaining question though, which is why I asked
about how to enter some data on my "Microsoft Natural Keyboard":

how do I as a data entry team member, enter data into this database?

Right now, this is a little too ephemeral for me. With Richard and
Till's suggestion of using XML files, I can jump straight into an
editor, throw some suitable tags around the data, and put it straight
into CVS. I can visualize exactly the steps involved, and I don't have
to go through any single point, such as yourself, which would be a
potential scalability problem as we grow.

There is something very appealing about "everything is a file", which
you must understand?

Unfortunately I personally don't have the skills to match anywhere near
the simplicity of constraints implementation/ declaration, and of data
normalization, that an RDBMS offers (which I have personally experienced
in the db design and implementation work I have done).

ta
zen