Re: [openMSX-devel] Software IDs

[Maarten t. H. <ma...@tr...>]

On Sunday 15 July 2007, Daniel Vik wrote:

(Daniel's post to openmsx-devel is helt for moderator approval because he i=
s=20
not currently subscribed to that list. This means some people will not yet=
=20
have seen Daniel's post that I am replying to. I cut away everything he=20
agreed on, so don't get the wrong impression from what is left ;)

> > From an XML perspective, these are the rules:
> > - a <software> entry can have any number of <id> tags
> > - for each <software> entry, each ID type should occur at most once
> > (otherwise it wouldn't be a unique ID)
>
> I don't think this should be a restriction. Imagine you treat different
> releases as different <software> blocks (which I think is a good idea, see
> below), some id types may have one id for all different releases, which
> means that one id may be put in multiple <software> blocks.

What I meant is that this would be invalid:

<software>
    <id type=3D"genmsx">1234-R1</id>
    <id type=3D"genmsx">1234-R2</id>
    <title xml:lang=3D"en">Catch the Anvil</title>
    ...
</software>

The situation you describe would look like this in XML:

<software>
    <id type=3D"genmsx">1234-R1</id>
    <title xml:lang=3D"en">Catch the Anvil</title>
    <company>ACME</company>
    ...
</software>
<software>
    <id type=3D"genmsx">1234-R2</id>
    <title xml:lang=3D"en">Catch the Anvil</title>
    <company>Zemina</company>
    ...
</software>

The latter is valid according to the proposed rules.

> > - storing multiple IDs will increase the data size
>
> This only makes sense if someone develops a very good database. I can see
> that being a possibility, for example if some Japanese group/organization
> wants to create a japanese database. In that case it would probably be
> interesting, at least for blueMSX to support that database since Japan has
> the biggest number of blueMSX users.
> But I'm not promoting a different type. It would be better if any new
> databases would use the genmsx ids in that case.

In any case, we should use the same ID scheme (GenMSX) for services that we=
=20
implement in our emulators, such as trainer matching, screenshot matching=20
etc. That way, for example a set of screenshots can be shared between blueM=
SX=20
and openMSX.

If other IDs are included in the software DB, they should only be used for=
=20
services that cannot be used without those IDs. For example, if a Japanese=
=20
web site like Generation MSX would use its own set of IDs, that ID scheme=20
should only be used for lookups on that web site, not for locating=20
screenshots that are stored locally.

> > Unresolved issues:
> >
> > What exactly is one piece of software? In Generation MSX some games have
> > multiple releases, for example the original Japanese version and a Kore=
an
> > version. Should we consider this as one or two entries in the software
> > DB?
>
> My opinion is that a game that has two versions, one Korean and one
> Japanese  would have two entries in the software DB. Same with the games
> that were released by different companies. The reason is that we have
> other information in the database about release year, country of origin,
> etc. so to me it makes sense to treat different releases as different
> software DB tags.

Let's list some things that would make two versions two separate software=20
entries:
=2D different packaging
=2D different title screen
=2D different hardcoded language
=2D different system requirements
Did I miss anything?

I think that things such as publisher, country and release year should not=
=20
make it a different entry; instead we should pick the data from the first=20
release.

In any case we have a technical limitation: the emulator only sees the ROM=
=20
image, not the cartridge it came from. So if the exact same ROM contents we=
re=20
sold in different ways, we cannot know which version it is. Should we pick=
=20
the initial release or would this be a reason to include more than one ID o=
f=20
the same type?

> I can see some exeptions if needed, for example the different versions of
> Universe Unknown or Sudoku, which clearly is the same game but with a few
> bug fixes.

I agree that bug fixes should be considered the same software. In GoodMSX=20
there are also [a1] ROMs with alternative versions of the same game.

> I have one other wish though and that is to change the name of the
> generated xml file from softwaredb.xml to msx.xml. Actually I feel quite
> strongly for this change because the name softwaredb.xml is too generic.
> bluemsx supports multiple databases and currently has one for each system
> (msx, coleco, svi, and sega). This is not a big deal because we can
> release blueMSX with an xml file called msx.xml and I think we'll do that
> for next release.

I think the original idea was to have a single XML file for all systems and=
=20
use the <system> tag to figure out what system the game is for. Did you=20
abandon / not adopt that approach?

openMSX ships with only the MSX part of the DB, since we do not support oth=
er=20
systems. So for us the DB splitting would only simplify things.

Is the file name actually part of the specification (and if so, should it b=
e)?=20
It would be easier for us and our users if we can just keep "softwaredb.xml=
"=20
as the name, but I see no harm in the blueMSX version being given a differe=
nt=20
file name, as long as the XML format is the same.

> I also know that there are some entries in the bluemsx softwaredb.xml that
> may not be in Vampiers database. Should be easy to find out.

Please send the differences to Patrick.

Bye,
		Maarten