11 Aug
2004
11 Aug
'04
10:41 a.m.
>XML is platform neutral because it's basically
ASCII, right?
Yes, true, but I think of XML more as a Web technology requiring a complex
parsing engine. I'm not a Web programmer so my thoughts on XML are probably
somewhat broken.
Another comment was made about the difference between what's actually on the
media versus what the CPU actually sees. We would thus need to capture the
raw data stream from the "heads" side of the controller in order to
regenerate a usable original media from the metafile.
For emulator use, we can grind this metafile through a translation program
to get the bytestream. OR, the metafile could contain both types of data
(using the container file and metadirectory idea from earlier).
What we really need is PDF for magnetic media :-)
-----Original Message-----
From: cctalk-bounces(a)classiccmp.org
[mailto:cctalk-bounces@classiccmp.org]On Behalf Of Vintage Computer
Festival
Sent: Wednesday, August 11, 2004 3:23 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: Let's develop an open-source media archive standard
On Wed, 11 Aug 2004, Cini, Richard wrote:
This example represents the block data using
metatags...I guess along the
"XML" part of the thread.
I was thinking similarly to you but not using XML metadata:
;Hardware descriptor
MFGR
MACHINE
SUBTYPE
DRIVETYPE (this of course defines what follows)
;for floppy
DRIVESIZE
ENCODING
TRACKS
SECTORS
SECTSIZE
;HexData
; Each record or group of records contains the related media data. The
address record would be used for encoding the metadata
00TTSSHH: (00-track-sector-head)
I looked to Intel Hex (or Motorola) because it had built-in CRC facilities
and it was human-readable ASCII. The drive and machine description could
be
encoded in special MOT records probably.
I like the XML style because it's more explicit; more human-readable.
XML is more a more "current" technology but
I was trying to keep with the
platform neutrality by sticking to text-only and not assuming the use of
any
other technology like XML.
XML is platform neutral because it's basically ASCII, right?
--
Sellam Ismail Vintage Computer
Festival
----------------------------------------------------------------------------
--
International Man of Intrigue and Danger
http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers
]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org
]
11 Aug
11 Aug
11:27 a.m.
On Wed, 11 Aug 2004, Cini, Richard wrote:
I was deadset against it myself until Hans pointed out its virtues
(mainly, human readability).
It's not necessarily XML, though it may eventually end up as such. Right
now I just see it has a system of tags for specifying characteristics and
segmenting data.
>XML is
platform neutral because it's basically ASCII, right?
Yes, true, but I think of XML more as a Web technology requiring a complex
parsing engine. I'm not a Web programmer so my thoughts on XML are probably
somewhat broken. Another comment was made about the difference between
what's actually on the
media versus what the CPU actually sees. We would thus need to capture the
raw data stream from the "heads" side of the controller in order to
regenerate a usable original media from the metafile.
If you're thinking in terms of having the original hardware around to
write the imagefile back to its original media (like I have), then getting
the data at a logical byte level is adequate. It depends on what your
eventual goal is for the image. Is it just to capture the data on the
medium so that it can be accessed in the future without regards to whether
the original hardware still exists? Or do you intend to be able to
reconstruct the physical medium at some point?
The spec should be able to handle either case.
For emulator use, we can grind this metafile through a
translation program
to get the bytestream. OR, the metafile could contain both types of data
(using the container file and metadirectory idea from earlier).
Or it could specify what data it contains, and then you would use it as
appropriate.
What we really need is PDF for magnetic media :-)
And other media as well (paper, plastic, etc.) That's what we're tyring
to do here. Hopefully we don't end up with something as bloated as PDF
however :)
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
12 Aug
12 Aug
2:32 a.m.
Am 11 Aug 2004 15:41 meinte Cini, Richard:
>>XML is platform neutral because it's
basically ASCII, right?
Yes, true, but I think of XML more as a Web technology
requiring a complex
parsing engine.
Naa, XML parsing is as simple as parsing any other tagged format.
You just start at the beginning of the data stream and wait for
a tag start ('<'), identify the tab, and process the following
information (until the closing tag) as needed. That's all. For
my own little XML data storage I did an XML reader and writer in
Applesoft Basic in a few dozend lines. That's all what's needed.
Shure, if you want to do super-dooper-crunch-every-thing readers,
then it get's a bit more complex, but these are not realy needed
for real world applications (aka the ones realy getting the data
from a media or putting it back).
Another comment was made about the difference between
what's actually on the
media versus what the CPU actually sees. We would thus need to capture the
raw data stream from the "heads" side of the controller in order to
regenerate a usable original media from the metafile.
Not necersarry. it depends on the level you want to do. To me, 95%
of all media are written according to the standards described for
that media. Of course, if you look at the Amiga stuff, their main
concern are games with various kinds of protection schemes and non
standard encodings.
In fact, for most stuff even a logic definition based on the concept
of directories and files is sufficient. The average disk can be
duplicated on file level, an has not necersarry be duplicated on
block level, since the applications don't care. So why storeing
such stuff as disk image that preserves blocks?
For emulator use, we can grind this metafile through a
translation program
to get the bytestream. OR, the metafile could contain both types of data
(using the container file and metadirectory idea from earlier).
What we really need is PDF for magnetic media :-)
XML is the (base for a) PDF for digital media.
Gruss
H.
--
VCF Europa 6.0 am 30.April und 01.Mai 2005 in Muenchen
http://www.vcfe.org/
2:58 a.m.
On Thu, 2004-08-12 at 11:32, Hans Franke wrote:
Am 11 Aug 2004 15:41 meinte Cini, Richard:
Absolutely. There's a few gotchas, like if the opening tag ends with />
rather than > then you don't go scanning for a closing tag, and I seem
to recall having to do some strange things with character data fields
when parsing (plus there were probably caveats about escaping quotes in
attribute fields etc. - it's been a while)
Certainly nothing too complex though; error handling of the XML format's
probably the bit that takes most of the effort (coping with malformed
data without crashing the parser or eating up memory etc.)
cheers
Jules
>>XML is platform neutral because it's
basically ASCII, right?
Yes, true, but I think of XML more as a Web
technology requiring a complex
parsing engine.
Naa, XML parsing is as simple as parsing any other tagged format.
You just start at the beginning of the data stream and wait for
a tag start ('<'), identify the tab, and process the following
information (until the closing tag) as needed. That's all. For
my own little XML data storage I did an XML reader and writer in
Applesoft Basic in a few dozend lines. That's all what's needed.
Shure, if you want to do super-dooper-crunch-every-thing readers,
then it get's a bit more complex, but these are not realy needed
for real world applications (aka the ones realy getting the data
from a media or putting it back).
3:46 a.m.
Am 12 Aug 2004 11:58 meinte Jules Richardson:
On Thu, 2004-08-12 at 11:32, Hans Franke wrote:
> Am 11 Aug 2004 15:41 meinte Cini, Richard:
> > >>XML is platform neutral because it's basically ASCII, right?
> > Yes, true, but I think of XML more as a Web
technology requiring a complex
> > parsing engine.
> Naa, XML parsing is as simple as parsing any
other tagged format.
> You just start at the beginning of the data stream and wait for
> a tag start ('<'), identify the tab, and process the following
> information (until the closing tag) as needed. That's all. For
> my own little XML data storage I did an XML reader and writer in
> Applesoft Basic in a few dozend lines. That's all what's needed.
> Shure, if you want to do
super-dooper-crunch-every-thing readers,
> then it get's a bit more complex, but these are not realy needed
> for real world applications (aka the ones realy getting the data
> from a media or putting it back).
Absolutely. There's a few gotchas, like if the
opening tag ends with />
rather than > then you don't go scanning for a closing tag, and I seem
to recall having to do some strange things with character data fields
when parsing (plus there were probably caveats about escaping quotes in
attribute fields etc. - it's been a while)
Now, /> is already a closeing tab, so if you find a / right at
the end of an opening tag, you just go for the closeing function
with an empty string as parameter - I found that way more convinient
than the behaviour of some parsers that tell you that you've found
an empty tag.
Also adding CDATA secions is only necersary if you want to include
as is data, which is not to be parsed at all. In general that is
only needed if you include tags and/or entities within which are
not supposed to be parsed. Necersary when doing binary or XML ad
data. not realy necersary here, but again, it is easy to be found
and can be handled with a few lines of code.
Certainly nothing too complex though; error handling
of the XML format's
probably the bit that takes most of the effort (coping with malformed
data without crashing the parser or eating up memory etc.)
Again, not realy an issue. As for a reader, it only needs to understand
the structure as it is used. In such a real world context, error handling
is easy - as easy as for any other format. If some identifyer comes along
that does not fit at the current position: print an error message and stop
execution. That's all needed. We don't have the need here to work like an
HTML browser, which tries to display a somewhat readable page, no matter
how destroyed the tags are, hopeing thet the user may find some sense
within. We store and retrieve data. if the data is corrupted, we allert
the user, and let him the situation (or some 'checkfile' utility - but
that's already optional).
Gruss
H.
--
VCF Europa 6.0 am 30.April und 01.Mai 2005 in Muenchen
http://www.vcfe.org/
10:44 a.m.
It was thus said that the Great Jules Richardson once stated:
Certainly nothing too complex though; error handling of the XML format's
probably the bit that takes most of the effort (coping with malformed
data without crashing the parser or eating up memory etc.)
Actually, that's the easy part---it is mandated by the XML spec that any
malformed XML will cause the XML parser to report the error to the user, and
*stop immediately* and do no further processing. It's then up to the user
to correct the XML file and start again.
-spc (See? Easy error handling 8-P
7266
days inactive
7267
days old
5 comments
5 participants
participants (5)
-
Hans.Franke＠siemens.com -
julesrichardsonuk＠yahoo.co.uk -
RCini＠congressfinancial.com -
spc＠conman.org -
vcf＠siconic.com