Date   : Tue, 21 Aug 2001 23:33:19 +0200
From   : Isabel Cisternas & Robert Schmidt <rschmidt@...>
Subject: Re: ANNOUNCE : UEF Specification 0.9

Thomas Harte wrote:
> Wouter seems to be the king of ASCII packaging! For my money, if ASCII is
> the aim could we stick with something that can be Yacc/Lex'ified? 

Free XML parsers are everywhere these days!  Why even bother with
lex/yacc?
If DOS is a concern, can anyone honestly tell me they care?  I was
relieved to see MAME and MESS dropping DOS as their main platform - MESS
even dropped DOS support completely.

> With
> something as simple as that shown above development would probably take
> longer with something as simple as that shown above, but things tend to grow
> in complexity. Look at horrid, horrid INF files.

INF files are a bit simpler than XML, by a couple of magnitudes. :-) 
But I get your point.  INF was decided upon for an immediate, simple
need, and was never meant to be extendable.

> But then, if 'everything in a zip' is combined with 'ASCII file for defining
> what is present' and 'established file formats for established external
> programs' I'd rather stick with HTML and hyperlinks than XML and embedded
> meta data since the lower limit of the sort of system the prewritten
> software capable of 'doing XML' targets compared is higher than that which
> any of the emulators target, whereas with HTML that isn't the case.

That was a very long sentence, which I'm not quite sure I understood
fully, but what would you use HTML for?  How can HTML tell ElectrEm
anything about a game?  HTML is *purely* a hypertext formatting language
- using it for storing anything else but hints on how a piece of text
should be represented on a display device, is suicide.  This lack of
adaptability between domains is exactly what XML (and its plethora of
related standards) is making up for. 

We can decide on a nice, comfortable subset of XML (like suggested by
Mark, or even Mark) that would be easy to parse by hand (read:
C/lex/yacc), but would also require only a DTD for those of our
utilities using a standard XML parser.

[Back to UEF mode here]
> Personally I'd keep at least 'origin information' and maybe switch 'game
> instructions' to 'controls summary' (for quick reference - really useful for
> flight sims!) with respect to ASCII data. Then the only thing UEF contains
> which anyone could possibly object to is the inlay scan chunk, which it
> seems is universally agreed should go.

This makes sense.
 
> At the minute I oppose any suggestion that the 'target platform' and 'ROM
> hint' chunks should go, but if anyone has a convincing argument . . .

I also agree with this.  This is vital information for which there is no
existing alternative format (insofar that hints can be vital).
 
> Although this thread has already seen 'I thought binary chunk based formats
> had gone out by now' (a paraphrase from Robert Schmidt) so even the
> implementation of that isn't universally popular! Personally I think that
> type of thing when the chunk header has complete continuity works very well.

My point was that with our modern storage and bandwidth capacities, it
doesn't make sense to muddle information up into tightly compressed,
human-unreadable files, enforcing proprietary formatting onto something
where dozens of perfectly acceptable formatting options exist (text,
images).

XML is beautiful in that sense, in that information is freely available
to anyone who (or any computer program which) can read ASCII text.  I'm
sure Microsoft will manage to muddle things enough in their "XML", but
that doesn't really concern our purposes.  That's the second beauty of
XML - that for simple uses like this, far away from the bleeding edge,
standard changes etc. won't affect us.  Third, like HTML, linking to
external resources is encouraged.

I picture an XML tag (sub-tree) for each game (in one file or separate
files - that's really irrelevant).  This XML tag has sub-tags for name,
copyright info, platform, and other simple stuff, then links for info
like scans and documentation.
In terms of Mark de Weger's DTD, I'd expect something like this for that
last part:

...
<doclinks>
  <doclink>
    <doc-name>Documentation (PDF)</doc-name>
    <doc-url>file://arcadians-doc.pdf</doc-url>
  </doclink>
  <doclink>
    <doc-name>Tape sleeve front scan</doc-name>
    <doc-url>file://arcadians-front.jpg</doc-url>
  </doclink>
</doclinks>
...

We could cater for Thomas' wish for inline quick dox by simplifying, and
allowing a "href" attribute like we're used to in HTML:

...
<docentries>
  <docentry>Quick dox: CTRL=left, SHIFT=right, RETURN=fire.  Of course,
this text could be as long as hell.</docentry>
  <docentry href="file://arcadians-doc.pdf">Documentation
(PDF)</docentry>
  <docentry href="file://arcadians-front.jpg">Tape sleeve front
scan</docentry>
</docentries>
...

A similar structure can be defined for linking to the UEF file(s),
though in such cases the href can't be optional.

I'm sure those of you unfamiliar with XML will cringe at the waste of
space these examples seem to represent, but try to imagine all the
benefits we would get with XML, beyond the fact that you can read it
with your own eyes.  Given a proper DTD, practically any XML compliant
program will be able to make some sort of sense from our XML files,
ranging from displaying a simple tree of nodes (Internet Explorer does
this already), to database interface layers that will make it possible
for any SQL application to perform queries on our XML files, to
translation utlities that can transform external data to or from our XML
schema.  All this with a minimum of effort from our side!

It would probably be beneficial to see if other emulator front-ends have
started using XML.  It'd be nice if the entire emulation "scene" slowly
converged on a standard.

Disclaimer: I am *not* an XML expert, hardly even a user.  Some things I
say may be plain wrong, but I hope some illuminated soul will then
correct me.

Just my thoughts before midnight...

Cheers,
Robert