Date   : Fri, 10 Aug 2001 22:16:32 +0100 (BST)
From   : David Boddie <davidb@...>
Subject: Re: ANNOUNCE : UEF Specification 0.9

On Fri, 10 Aug 2001, Isabel Cisternas & Robert Schmidt wrote:

> If we needed a "one file for everything" kind of format, why was XML
> considered?  With UEF, users will always be dependent on software
> written just to process the UEF format.  It's a bit like re-inventing a
> filing system within a file (with severe limitations), IMO.
>
> Besides, I thought binary "chunked" formats were "out" by now.  XML is
> basically the same idea, just ASCII'fied and standardized and formalized
> beyond all recognition.

Why not just produce an XML version of the UEF format, then? You'd only
have to agree on how non-textual data was encoded, which shouldn't be a
problem.

> No, store each logical chunk of information in separate files, each file
> in a format widely accepted and created for that specific use.  Often,
> as for images or text, there are *many* potential format.  Pick one
> today, pick another tomorrow, as long as they're widely used, you'll
> hardly notice the difference, ever.
>
> Notice how UEF (currently) supports only ASCII text and raw image
> files.  I wouldn't want to put the PDFs, DOCs, JPEGs and GIFs strewn
> around TBL! archive into UEFs.

I think that this is where the UEF format specification needs tighter
definition. I suppose that simply specifying that a particular chunk
contains a cover scan leaves the decoding of the type of information to
relevant tools, but it's always helpful to give the tools hints on what
to expect.

> Thomas, I think the most useful kind of data you could put in a
> "instructions", "inlay scans" or "cheats" chunk would be an URL.
>
> I agree that BBC emulators need a *proper* disk and tape imaging format,
> and also state snapshots to some degree.  UEF seem to be great,
> especially if the disk part will be at least as comprehensive as FDI.
>
> But leave the other data where it belongs, in separate files which I can
> view with a normal file viewer.  Lump everything into one directory per
> software title, or use a consistent file naming scheme, as I've
> attempted at TBL!.

Or put it all in a zip archive.

> Do we need the extra UEF layer of complexity?  If I want to edit some
> text in a game's instructions, can I simply double click the UEF icon,
> as I can with a DOC file?

I'm not completely happy with requiring Word files for instructions. It
might be a contraversial area, but can't we settle on some open format for
documentation? Is HTML out of the question for files with simple
formatting?

> If I want to replace a cover scan with a higher resolution one, or I'd
> like to add scans of ads or reviews, will it be as simply as dragging
> and dropping in Windows Explorer?

It's as simple as your favourite command line:

    UEFtrans.py EMBA.uef insert c0 inlay

which puts the cover scan (a JPEG) into the Escape From Moonbase Alpha UEF
file. Then

    UEFtrans.py EMBA.uef wwwinfo EMBAWeb

creates a directory with some relevant files for publishing on the web.
Here's one I made earlier with some resources I found on various sites
(mainly TBL!):

    http://www-solar.mcs.st-and.ac.uk/~davidb/EMBAWeb/

David - looking forward to writing UEF2XML ;-)
-- 
David Boddie
Solar MHD Theory Group, St Andrews
http://www-solar.mcs.st-and.ac.uk/~davidb/index2.html