I've been of for the hollydays, so now some comments.
I'd still favour a XML defined markup for this. Someone (John ?)
said cutting edge .. why ? XML itself is nothing, it's only aset
of rules to describe markup languages. In fact, XML is just a
simplified (and bastardised) SGML, posibly to promote the idea.
Nobody has to know anything about XML (although it helps) to use
one of these Languages. Like one can do well formed HTML without
knowing about XML, a Data Image Markup Language can be used without
XML - But defining it in XML will give a huge advantage in tool
usage. There are plenty of libraries and tool collections to handle
markup languages with a XML based definition. These tools are to
help development and not restrict.
There is no need to build a XML parser for an Apple ][ or a TRS
(Or a CoCo - Hi Bill:), unless someone likes to. The target systems
don't need any knowledge about XML either - they need to dechipher
the markup language. Read: they have to know that <TRACK LFD=0>
identifies the start of the description of track zero of said
disk. Of course the usage of a parser framework may reduce
programming, but there's no _must_ to do so. The same is true
for a system writing an image file - it doesn't need to know
XML - if the programm produces a well formed output (and that's
a basic must for every format) all will work fine.
XML changes nothing at first - like any other general standard.
The benefit is in the long term when people are able to build
advanced tools based on this standards without knowing about
every specific single usage - My most favoured example is still
the ordinary screw and bolt. Standardizeing this simple thing
has allowed toolmakers to produce a wide variety of tools handeling
them , from simple manual wrenches over prneumatic or electric
to 100% robotic devices ... and these tools work (almost) in
every situation ... we don't need a special wrench for Atari
screws or Commodore ... Of course I prefer the metric screw
system, but when looking closer it could be different, maybe
better in some aspects for different situations ... but that's
no real issue, the fact of having one system offers more
benefit than anything else. BTW: Did I already mention that
I _personaly_ think XML is a poor design ?
And If I sound like a old XML freak, I'm not, until some
8 Month ago I did ignore XML (and I did even fight it), then
I had to define some markup and tried XML ... no big deal
(exept the real crapy standard document) - and an instant
gain thru independant structure checking and problem reporting,
without writing my own tools to check everything.
Well, back to our theme:
Pete, I realy agree to your idea about a sensible editor, just
we are living in a real world, where real software is to be used.
And since this is supposed to be an open standard, a sensible
editior can't be assumed... Even if we would try, I doubt that
such a thing is available on every obscure home computer system.
Even chances for a simple text editor can be bad. So including
binary as default is a bad idea - I would even go further and
restrict all markup specific parts for only using the characters
A-Z, 0-9 and some well defined (read only the absolute necersary
minimum) characters. Remember, not every Computer system offers
lower case or ASCII at all (This is also the reason why my
definition did only include uper case tags, while XML encurages
lower case).
I can't stretch this fact far enough: Don't assume that binary
data transfer is possible between two systems - as soon as
you do, you will exclude possible usages. A format to be choosen
shouls at least allow to transport the neto data in non binary
form - a better way would be to allow different encodings, so
_neutral_ converters may change the data representation without
interpreting the content. Example: to save disk space data
chunks (sektors) are stored binary - but since the encoding
is just another parameter of the data tag, it may be convertetd
to a base64 encoding _without_ interpreting the content other than
converting the encoding. This may be done by a third party tool
(remember about the advantages of standards for tool variety?)
After all, we are talking about puting _yesterdays_ data
on _todays_ storage (and not the other way around).
Let'S just assume we would need three times - oh, well lets
say four times the space to encode so an Apple Disk will
need a whooping 600 kb ... Boy, we are talking about 2000s
storage, thats the year then 40 gig drives droped below
250 USD including taxes. The equivalent of 10 Gig markup
coded data, or about 70,000 Apple disks (143 k each).
Somehow I doubt that someone will ever collect that amount.
And even Windows is now able to compress data on the fly.
This may reduce it close to the original size, maybe even
less (in our example we store now something like a quater
million of disks on one 250 Dollar IDE drive...)
As far as I see this call, it's to define a format for more
than just a specific system or format - so reducing it to a hard
coded thing with just a few numbers would turn away most possible
usage. Even further, restricting it to floppy disk like structures
would render it non usable. Of course I may describe a CBM
disk written on a 4040 drive - but what about the same data
stored on tape drives ? Also, looking on Sallams definition
even some floppy structures are excluded - where is variable
speed, where are possible tracks of more than 64k, and how
to encode spiral tracks (no, I'm not talking about Apple copy
protection schemes, but rather flopy drives writing only one
big track, like on a CD - In fact, medias like these micro
drives (as used by some sharp machines) are in more danger than
some Apple disk ... you still get enough drives and disks to
replicate them. The same is true for other once common medias,
which fall in similar categories. just remember the Sinclair
micro drives. Maybe never common in the US, but for shure on
the Island and within Europe.
Defining only a standard for FD data means closing the eyes
about all the fast fading data storage history. One may define
one ore maybe two standars, but soon you'll loose - and the
forgotten medias will loose. If there'S some effort to invest,
it should be spend on a standard to cover as many as possible
medias, and it should be extensible to add missing medias on
the fly.
A format to be choosen should be able of the 10 following
things (with no special order):
- Be able to handle all kinds of stuff from Card Storages and
paper tapes, over real tapes and audio cassettes, spiral
floppies and micro drives to FDs, HDs and CDs... and what
ever is coming (althoug I belive that the number of new
concepts is shrinking).
- Define an abstract view (like tracks and sectors)
- Allow the addition of physical descriptions when needed
- (Possibly) Allow the definition of 'hardwaredependant' structures
(ALthough this now crosses into the path of emulator definitions)
- Expandable in several ways (including content encoding)
- Transportable between machines, codes and OSes
- Allow robust encoding
- Able to be integrated into other definitions
(like being integrated in a storage situation description)
- simple encodable / simple decodable
- Allow the encoding of multiple media within a single transfer
unit (aka file).
(Especialy nuber 8 and 10 is important when going to do more
than just storing a disk image)
I still think a XML based markup language is a good choice.
I would suggest a multiple level design:
- Level one is a language to describe the logical
content of a media.
- Level two would define 'physical' descriptions, like disk
encoding etc.
- Level three defines a storage landscape
In the end these 3 levels should be interoperating.
For example: One would encode the logical content of a disk
using the Level 1 tags. A top level tag (like 'MEDIA' may
include a reference to a Level 2 description telling that
the disk is MFM encoded but Track 0 side 0 is FM. This will
be good for 99,99% of all encoded data disks - but for special
situations, like a copy protection scheme, where track 17 is
also FM the reevant tags will cary override informations
to tell the difference. Level 3 may be used to define a
situation where a computer has 4 disk drives and tells
which media (disks) are mounted in which drive. Or define
a set of medias belonging to one situation (like puting
all 23 OS/2 2.0 disks into one image).
Anyway, I'm geting tired ...
Gruss
H.
P.S.: still nobody to decode my disk example ?
--
VCF Europa 2.0 am 28./29. April 2001 in Muenchen
http://www.vintage.org/vcfe
http://www.homecomputer.de/vcfe
Received on Mon Jun 05 2000 - 13:55:36 BST