At 9:16 PM +0100 on 10/31/99, M. Uli Kusterer wrote:
>>One might argue that XML allows other people to use our format and create
>>their own viewers & editors, but--um--coudn't the just use the binary
>>format, since it's public? And aren't binary formats easier--and
>>quicker--for a computer to deal with?
>
> I never said we should drop the binary format (I'm still debugging the new
>compaction code), and I'd love if this became the new standardized xCard
>file format. But XML has no byte limits, that is, XML doesn't need to be
>converted when the application's internals eventually switch to support for
>8-byte integers or whatever.
There need not be any byte limits in a binary format, either. But they are
palce there because it's sane to do so.
You don't need more than 4 billion buttons on a card. Really.
And remember: Before you even come close to exceeding the word-length
[32-bits; we're using PPC's here!] counts in the binary format, you will
have exceeded the disk capacity and processing power of the entire world in
the XML format <g>.
> I'm not an XML guru, but HTML, close in kin, only uses the international
>ASCII set and escapes the others ("ü", for example), which makes
>charset conversion unnecessary. But as I said, it's not a working format.
Charset conversions are necissary to go from ASCII to your native charset.
And HTML _does_ support multiple character sets -- from Japanese to
ISO-8859-1 (I hope I got that number right).
>
> It's a lot easier to create XML files from HyperCard, though, than it'll
>be to create our binary format.
It'd be even easier to create something along the lines of:
type id flags nameLength NameContentsLength ContentsScriptLength Script
^ ^ ^ ^ ^ ^ ^ ^ ^
where "^" indicates a new piece of data -- some
are not seperated by spaces
