I wrote this document for ZMARC format and it includes a section about interaction with Treaty of Babel. Please I will require other people who own Treaty of Babel to check this, in order that it can be operated with programs that use Treaty of Babel format (such as, apparently IF-archive does).
http://zzo38computer.org/zmachine/doc/zmarchive.txt
In case it is unclear from the above, the help I require is to confirm that it interacts correctly with Treaty of Babel.
Why do this rather than just putting a blorb in a zip?
I have already addressed that question within the document (although there are several other reasons too). However, it has nothing to do with what my questions to you are (which I have clarified above, in case it is necessary).
Like Dannii, I can’t see how this is any better than putting a blorb in a zip. It is worse in several ways (less comprehensible tagging, discarding the iFiction format which is now in common use). The bzip2 compression is less accessible than zip, which is supported natively by most languages and platforms.
You say “Interaction with Blorb is irrelevant, since an Infocom-variant story should not be distributed as a Blorb. (Only Inform-variant stories may be Blorbed.)” This is not true as far as I can tell. Original Infocom game files should not be distributed at all, legally, but there are blorb files for them (ifarchive.org/indexes/if-archive … blorb.html) and the intent is that you could add the game file and have an interpreter-ready blorb.
The Treaty says “At present the only wrapper in usage is Blorb” and I see no reason to change that.
You are correct about bzip2 but Z-machine story files don’t compress very well with DEFLATE (I know, because I have tried it). It also does not look worse to me; iFiction cannot even use FTP. (Also, a blorb is a single file and a ZIP archive contains multiple files; something like .blorb.gz is a way to compress a single file.) Distribute them as a plain story file if you don’t want to deal with these things!
That is correct, but I am not talking about the original Infocom story files (that is addressed elsewhere in the document; the sentence you quote has nothing absolutely nothing to do with it); I am talking about the variant originally used by Infocom (it also has nothing to do with whether Inform compiled the story, although this is usually the case anyways). (It is also possible to make ZMARC files for Infocom’s original games in a similar way (as ZMARC files aren’t required to contain a story, or they may optionally contain just the header); they just need be extracted into a directory with the story file and then it can go. This is also completely irrelevant to my point.)
I am not disputing that. It defines a C API, which, however, is usable with containers and story formats. Therefore, it can be interoperatable with archives and browsers which use iFiction/Treaty of Babel. (It can also be used just to extract the IFID, although my ZMARC utility program can do that too. This has nothing to do with my original question, though.)
Note that I am not intending to change or add to the Treaty of Babel document (at least not yet!); you may have misunderstood what my question was about. It hasn’t to do with changes to the Treaty of Babel, but rather to ensure the interoperatability is correct. (I know it is lossy, and this is inevitable. I also know that it specifies a different than the named block for Infocom’s original story files; it isn’t relevant to existing iFiction records or blorbs; but when interoperating iFiction with ZMARC, it seems the least bad way to get around a problem.)
Again, to be clear, nobody has to change anything that already exists; I am simply asking questions.
I don’t understand the question then. You’ve explained several things that you’re not talking about, but I don’t understand what you are talking about.
It specifies such things as what API call corresponds to what return value, what thing in ZMARC corresponds to what thing in Treaty of Babel, and so on. I want to ensure that I have not made any mistake in these specifications; some things in Treaty of Babel I am not entirely clear about knowing so I may have made some mistakes.
(Honestly, I have not only explained what my question isn’t, but also clarified some other things from this document too in my response. Hopefully I can also clarify them in the document to make it clear too, although I thought I already did.)
Please keep in mind that you’re asking people to do you a favor here. (And, taking a moment to glance at the Treaty of Babel and the ZMARC format, it looks like a pretty big favor.)
If it looks like you’re reinventing the wheel, then “Why are you trying to reinvent the wheel?” is not an unreasonable question, especially when you’re asking other people to help you do it.
You are right; it is not an unreasonable question. But I am not trying to ask other people to help me to do it; I am asking something a bit different.
The first section of this document is about the ZMARC file format, which isn’t having to do with Treaty of Babel. The third section is about interoperatability with Treaty of Babel (which is inevitably lossy in either direction). With the exception of the part about the tag when converting ZMARC data for Infocom’s original games into iFiction (this isn’t intended to invalidate anything that already exists; also, the other way around, iFiction to ZMARC, is different), they are things which are intended to try to not violate the Treaty of Babel (in order to work with programs that need it; of course individual browsers and stuff still need to know how to determine what interpreter (or possibly another “in-between-interface” which extracts files and decides the interpreter) to call). It includes iFiction XML tags, as well as the C APIs for zmarc_treaty() and zmachine_treaty() functions; it is specified there what they should do. For one thing, I am unsure that these specifications are actually in agreement with the API; I am especially unsure about what CONTAINER_GET_STORY_EXTENT_SEL does if it doesn’t contain a story, or contains only the header (which still might be useful information to extract, but isn’t a story that can be executed).
(Did you actually read this document carefully?)
Not at all. As I said, I glanced at it. I’m not qualified to help in this matter.
Ah, OK.
I’m actually not super-familiar with the treaty’s API section either. (I have not dealt with the babel tool very much, either as a command-line tool or the babel_handler API.)
If we know that your thing is imperfectly (lossily) matched to the usual babel material, then I guess that there’s no question of interoperability. You do the best job you can, is all.
That is OK. However, this is kept here in case anyone else who works with such thing finds something that is clearly wrong (whether due to typographical errors or my misunderstanding of the Treaty of Babel document or otherwise) or if better conversions exist for some of the things mentioned in otherwise.