[Announce]: The Treaty of Babel: Software and a Standard for Interactive Fiction Bibliography
L. Ross Raszewski
The Treaty of Babel: Software and a standard for IF bibliography
----------------------------------------------------------------
Over the last few months, informal discussions between the various
design systems for IF have been working towards a common format of
"library card" - a packet of bibliographic data in a standardised form
which each system can incorporate as an extension to its existing file
format. The aim is not to unify the various virtual machines used by
different IF design systems: these remain quite separate. Rather, the
aim is to provide a unified way to identify and describe story files
of many different internal formats.
The agreement we reached sets out a new community standard for the
identification of IF. This standard is implemented by working
reference software and by current development builds of several IF
tools, and the four most widely-used IF design systems have all agreed
to implement it: it will also greatly affect the work of the IF
Archive, another signatory to the agreement.
We are today publishing the first "beta" version of the Treaty.
The Treaty is not intended to be a solution to all possible problems
associated with the indexing of IF - it is intended to be a practical,
workable basis to go forward, giving IF the same basic support for
cover art and bibliographic data that (for instance) online retailers
of books, CDs and DVDs use. We see the Treaty as making possible a new
generation of tools for IF: the Babel API will make such tools very
much easier to write.
The Treaty is not "owned" by any individual, but by a committee of
representatives from each of the pieces of software which have signed
up. Authors of other tools who wish to implement the Treaty are
welcome to join this committee, and more generally, we would expect
future drafts of the Treaty to be influenced by responses from all
those interested in IF.
The Treaty text and the Babel software have been published at the
agreement's home page:
The following excerpt from the preamble to the Treaty gives further
details of its aims and objectives:
Since the 1980s, writers of interactive fiction ("IF") have used a
variety of programs ("design systems") to create new works. Some were
in-house tools used by commercial IF production houses, but from
around 1990 IF has been written by a diverse Internet community, using
tools written, tested and evolved within the community. The playable
works of IF produced by design systems ("story files") have in almost
all cases been programs for virtual machines, requiring the use of an
emulator in order to play them (an "interpreter"). With few
exceptions, the virtual machines used by different design systems have
been mutually incompatible. Although a number of multi-format
interpreters have been written, and the IF community prefers a
format-independent approach to reviewing and discussing works of IF,
few tools exist (as of the start of 2006) which treat all formats
equally.
One obstacle to the creation of software for playing and archiving IF
in a format-independent way is that few design systems, up to 2006,
have compiled even basic bibliographic data into their story files -
the author and title, for instance. Only one major design system has
approached this problem systematically (TADS 3), though others have
implemented partial solutions, or incorporate data into story files
which - though not intended to be read externally - can allow the
title or author's name to be found.
Most serious works of IF written since 1990 have been placed at the
IF-archive, a community project which - subject to copyright issues -
aims to preserve the whole corpus of IF, making it available to
players of the present and future. Other web-based databases of IF
exist, such as "Baf's Guide", which catalogue reviews and
bibliographic data about works of IF but do not actually archive the
story files: here copyright is not an issue. As a result, the
IF-archive is the most complete collection of actual IF known to
exist, but omits some of the most important early story files (notably
Infocom's) for copyright reasons, and is not currently a useful source
of bibliographic data. This is to be regretted, since such data should
also be preserved. Furthermore, the IF-archive must accept story files
in all formats and generate its own catalogues: the lack of any
systematic way to do this imposes considerable work on the
librarians.
The Treaty is an agreement between active design systems, the
IF-archive and other interested parties. It provides for:
- ISBN-like unique ID numbers for story files, old and new,
produced by commercial or non-commercial compilers living
and dead;
- a standard format for cover art and bibliographic data;
- a web server able to provide these for a given ID number;
- a command-line tool able to identify and extract data from
story files in any format;
- reference software providing a format-neutral API for reading
story files, and removing "wrappers".
The aim of the treaty, and of the Babel software, is to make it much
easier to write new tools for players in which the distinction of
which design system created which story file is much less visible.
27 April 2006
L. Ross Raszewski, for Babel
Andrew Plotkin, David Kinder and Paul Mazaitis, for the IF Archive
Graham Nelson, for Inform
Mike Roberts, for TADS
Kent Tessman, for Hugo
Campbell Wild, for ADRIFT
Andrew Plotkin, for the Blorb wrapper format
Andrew Hunter, for the Zoom interpreter
David Kinder, for the Windows Frotz interpreter
Mike Roberts
> Over the last few months, informal discussions between the various
> design systems for IF have been working towards a common format of
> "library card" - a packet of bibliographic data in a standardised form
> which each system can incorporate as an extension to its existing file
> format.
Most people writing games in TADS are probably already aware of the GameInfo
format - it's the TADS mechanism for attaching structured bibliographic
information to a game. If you've been using GameInfo in your games, you'll
be pleased to hear that it's fully compatible with the new Babel system Ross
just announced - it is, in fact, the way that TADS participates in that new
system. This means that the IF Archive and other systems that use Babel
will now be able to read and use the metadata you've already been storing in
your games.
If you haven't seen it, the original GameInfo documentation can be found at
http://www.tads.org/howto/gameinfo.htm.
Babel defines a number of data elements that have no corresponding elements
in the original GameInfo specification. So, I've just posted a proposed
specification for GameInfo version 2. Almost all of the changes from the
original version are in the form of new elements (that is, new Name/Value
pair definitions), to fill these gaps with respect to Babel's schema. The
new elements will let TADS authors take better advantage of the features
that Babel offers.
The new version is available at http://www.tads.org/howto/gameinfo2.htm.
This is only a proposal at this point, not even really a "beta" per se, and
I'm interested in any feedback about it. You should probably hold off on
actually using any of the new elements for a little while - hopefully a
consensus will form about the changes and the spec will solidify before too
long. Of course, the Babel spec itself is still subject to some revision,
too, and as the GameInfo v2 changes were largely driven by Babel, changes to
Babel could necessitate changes to my proposal.
I'm anticipating a couple of technical questions about how GameInfo and
Babel fit together, so I'll try to answer them preemptively here.
First, Babel's iFiction format is an XML schema, whereas GameInfo is an ad
hoc format; so how can GameInfo possibly work with Babel? Well, even though
GameInfo is an ad hoc format, it's still a highly structured format. In
addition, the information it stores is really very similar to what Babel
defines. There's enough structure in GameInfo, and enough similarity
between the formats, that translating GameInfo to iFiction XML is a simple
parsing job. And that's exactly what the TADS module for Babel does: it
reads the GameInfo name/value pairs and converts them into the corresponding
iFiction XML elements.
Second, should GameInfo v2 just actually *be* the iFiction format? That is,
should we just dump the custom name/value pair format entirely, and replace
it with the iFiction XML format, to avoid the need for the translation step
in the Babel software? Maybe so; I'm open to input on that. So far I'm
leaning against it, since it would require GameInfo readers to be able to
handle the iFiction XML formats as well as the GameInfo v1 format, for
compatibility with existing games. But it does have obvious advantages -
there'd be no need to do any format translation in Babel, and TADS authors
could always take advantage of new iFiction features without waiting for
corresponding GameInfo additions.
Have a look at the new spec and let me know what you think. I suggest
keeping the discussion here in the newsgroup for now; if it looks like it's
going to go on too long or generate too much volume, we might want to move
it somewhere else. But for the time being, I think the newsgroup is the
right place, as it probably reaches more TADS users than any other existing
forum.
--Mike
mjr underscore at hotmail dot com
Stephen Granade
> Second, should GameInfo v2 just actually *be* the iFiction format? That is,
> should we just dump the custom name/value pair format entirely, and replace
> it with the iFiction XML format, to avoid the need for the translation step
> in the Babel software? Maybe so; I'm open to input on that. So far I'm
> leaning against it, since it would require GameInfo readers to be able to
> handle the iFiction XML formats as well as the GameInfo v1 format, for
> compatibility with existing games. But it does have obvious advantages -
> there'd be no need to do any format translation in Babel, and TADS authors
> could always take advantage of new iFiction features without waiting for
> corresponding GameInfo additions.
I would lean towards making GameInfo v2 be the iFiction format, with
whatever TADS-specific tags are required such as the
HtmlByline. There's going to be a fixed cost for the translation, and
that cost will be borne by the GameInfo readers, the Babel readers, or
the games themselves (by storing both formats at once). The last I'd
throw out immediately; down that road lies madness. Plus that's the
most expensive approach, as the cost is borne by each and every TADS
game, which will certainly grow much faster than Babel or GameInfo
readers.
The Babel readers already have to do parsing of the GameInfo format,
so in one sense switching the GameInfo format to iFiction is an
additional burden: now both GameInfo readers and Babel readers have to
deal with two formats. But the gain is in not having to keep two
formats on track, with useful changes to one slowly propagating to the
other. The additional work seems minimal enough and the benefit large
enough that I'd lean towards the format switch.
I've not had time to fully digest the v2 spec, so I'll have to comment
on that later.
Stephen
--
Stephen Granade
stephen...@granades.com
Mike Roberts
> I would lean towards making GameInfo v2 be the iFiction format,
> with whatever TADS-specific tags are required such as the
> HtmlByline.
The iFiction spec already has a provision for arbitrary system-specific
extensions, so this is no problem.
(There's actually a slight complication specifically for HtmlByLine and
HtmlDesc, which is that HTML fragments can't be straightforwardly embedded
in XML due to the stricter structural requirements of XML. As a result,
I've left these out of the GameInfo-to-iFiction mapping for now. To add
them, we'd have to come up with a mapping that generates well-formed XML.
One possibility would be to write the markup-significant characters as <,
>, and & - so <i> becomes <i>. Another would be to switch
these characters to alternatives - [i] for <i>, say, and @amp; for &.
The first is awfully unreadable and the second is just kind of weird, but I
haven't come up with any better ideas.)
> There's going to be a fixed cost for the translation, and
> that cost will be borne by the GameInfo readers, the Babel readers,
> or the games themselves (by storing both formats at once). The last
> I'd throw out immediately; down that road lies madness.
Oh, definitely, but that last one's already off the table one way or the
other as far as I'm concerned - I certainly wouldn't suggest it, and I see
no reason to go that route.
Just to clarify, there's already an implementation of all this, and it
implements the GameInfo-to-iFiction translation in one place: in the TADS
plug-in for Babel. No one who's using Babel will ever see GameInfo data -
they'll only see the iFiction translation that's generated on the fly in the
TADS plug-in. No one who's writing TADS games will ever see iFiction data -
they'll just write GameInfo data as now. So there's no work multiplier: the
work is done in one place only, and that implementation is already done.
The only work remaining is to maintain the TADS plug-in for Babel as the two
schemas evolve. So if GameInfo v2 retains the proprietary format,
everyone's work is already basically done.
Now, if we were to switch to iFiction as the native GameInfo format, the
TADS plug-in for Babel would simply pass through the new-style XML contents
unchanged. It would still have to do the GameInfo-to-iFiction translation
when it detected an older game with the old format, but for the new format
there'd obviously be no translation needed. So switching to iFiction would
involve minimal work in the Babel plug-in.
Where switching would require work would be in existing GameInfo consumers
and producers. This probably amounts to just Game Chest and the tads2 and
tads3 libraries; Game Chest would have to be upgraded to parse the iFiction
XML format (it would also have to keep parsing the old format), and the
libraries would have to generate the XML format. It's these bits of work
that make me reluctant, but maybe it'd be worth it. The trade-off is that
it's a fairly large one-time job, vs a trickle of ongoing work to keep the
GameInfo schema up to date with the iFiction schema.
If we were to switch to iFiction as the native format, my proposal would be
as follows. We'd keep the GameInfo spec at v1, and that would continue to
be a supported alternative forever; the TADS Babel plug-in would continue to
recognize and translate that format to iFiction for Babel clients. We'd
then define the GameInfo v2 format as (a) an iFiction-compliant XML file (b)
embedded in a .gam/.t3 file as a multimedia resource called iFiction.xml.
Finally, we'd define any TADS-specific extensions to the schema (htmlByLine,
etc). I think that's basically the whole spec.
Shadow Wolf
news:NNs4g.21564$tN3....@newssvr27.news.prodigy.net:
> "Stephen Granade" <stephen...@granades.com> wrote:
>> I would lean towards making GameInfo v2 be the iFiction format,
>> with whatever TADS-specific tags are required such as the
>> HtmlByline.
>
> The iFiction spec already has a provision for arbitrary
> system-specific extensions, so this is no problem.
>
> (There's actually a slight complication specifically for HtmlByLine
> and HtmlDesc, which is that HTML fragments can't be straightforwardly
> embedded in XML due to the stricter structural requirements of XML.
> As a result, I've left these out of the GameInfo-to-iFiction mapping
> for now. To add them, we'd have to come up with a mapping that
> generates well-formed XML. One possibility would be to write the
> markup-significant characters as <, >, and & - so <i>
> becomes <i>. Another would be to switch these characters to
> alternatives - [i] for <i>, say, and @amp; for &. The first is
> awfully unreadable and the second is just kind of weird, but I haven't
> come up with any better ideas.)
Make the HtmlByLine and HtmlDesc elements CDATA.
--
Shadow Wolf
shadowolf3400 at yahoo dot com
Stories at http://www.asstr.org/~Shadow_Wolf
AIF at http://www.geocities.com/shadowolf3400
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Victor Gijsbers
> The Treaty of Babel: Software and a standard for IF bibliography
> ----------------------------------------------------------------
(I already tried to reply to this thread, but my post seems to have been
eaten somewhere between my PC and the newsgroup.)
Great work. Having read (a significant part of) the Treaty text, there
are two issues that concern me. One is a minor issue that has to do with
the IFID of translations, and concerns section 2.2. The other is a major
issue that has to do with the IFID of derivative works made from
OSS-licensed works and the policy of the IF-Archive, and concerns
sections 2.2 and 4.2(b). (There is also a very minor issue: you have
misquoted Hamlet! "O curse spite" should be "O cursed spite".)
MINOR ISSUE
========
Section 2.2 states clearly that re-releases with bugfixes of existing
works will be given the same IFID, while ports from one virtual machine
to another will be given different IFIDs. My question concerns
translations from one natural language to another. Will these
translations be given the same or different IFIDs? Analogy with ISBNs
seems to favour the later choice: translations from one natural language
to another should be given different IFIDs. Will this indeed be the
case? Can this be added to section 2.2?
MAJOR ISSUE
========
Section 2.2 clearly states that story files from the same project should
have identical IFIDs, and that, for instance, bug-fixes are not enough
to warrant labeling something as a new project.
At the same time, section 4.2(b) describes the to-be-followed policy of
the IF-Archive like this: if two story files have the same IFID, then
(1) if they are 'essentially different', the new story file will be
rejected, while (2) if they are not, the new story file will become the
new main file and the older story file may be removed.
Consequently, then, changing any work in a small way, such as making
bug-fixes, and releasing it will result in the new version replacing the
old version as the main file, and may result in the new version
replacing the old version entirely.
Now, this may not be much of a problem for works that are released under
traditional copyright licenses, because only the original author will be
allowed to contribute new versions to the archive. Being the author of
both the old and the new version of the work, he will at most cause one
of his own works to be removed.
However, for works released under free/open source licenses, the
situation is problematic. Suppose Graham Nelson releases his Curses
under the GPL, and I decide to fix some bugs that I have found. Given
2.2, I have to keep the same IFID. Given 4.2(b), the librarians must
either decide that my new work is 'essentially different' or that it is
not. If they decide that it is - which it is hard to find grounds for -
I will not be able to upload my piece to the IF-Archive, which cannot
have been the intent of releasing the original under the GPL. If the
librarians decide that my piece is not essentially different, it will
replace the original as the main file, and potentially entirely. But
this seems very undesirable indeed, because (1) by releasing a piece
under the GPL the author cannot have meant to allow everyone else in the
world to make the original unavailable; (2) there is no guarantee that
the new version is better than the original; (3) the new version may not
even have been meant as a straightforward improvement, but rather as an
alternative version (for instance, a version of Curses in which the
player cannot get stuck).
So, if authors comply to section 2.2 and the IF-Archive librarians
comply to section 4.2(b), authors who wish to release their work under
free/OSS licenses are in trouble. (Unless I have misread or
misunderstood the Treaty, in which case I'd live to be enlightened.)
If you perceive the same problem as I do, you may have your own ideas
about how to fix it. The following are the ideas I came up with.
1. Change section 2.2 to state that derivative works by those who do not
hold the copyright of the original are considered independent projects
and should receive a new, unique IFID.
2. Change section 4.2 to state that a work can only become the new 'main
file' of a project if it was released and uploaded by the original
author, or if he gives explicit written permission.
3. Add a new optional tag "derivative" to one of the sections - I have
no clear idea about which section would be the most appropriate - which
allows authors to state the IFIDs of the projects their project is a
derivate of. (In the sense of copy-left licenses: using source code from
the previous project.) Its format would be a number of IFIDs, separated
by semicolons or some other symbol. This optional tag can then be used
by, say, Baf's guide to show which works any given work is a derivative
of and which works are a derivative of any given work.
This solution would allow people to make changes to OSS-ed works and
upload them to the archive, while ensuring that authors will not
overwrite each other's works and allowing the user to track the links of
derivation. (This is useful. Someone who took a look at Curses might be
interested to know about my hypothetical version in which you cannot get
stuck.)
By the way, this solution would solve my minor issue at the same time,
since translations can be understood to be derivative works. (Though I
still think it is useful to make this explicit.)
Regards,
Victor
Stephen Granade
> "Stephen Granade" <stephen...@granades.com> wrote:
> > I would lean towards making GameInfo v2 be the iFiction format,
> > with whatever TADS-specific tags are required such as the
> > HtmlByline.
>
> The iFiction spec already has a provision for arbitrary system-specific
> extensions, so this is no problem.
Right, I noticed that.
> Where switching would require work would be in existing GameInfo consumers
> and producers. This probably amounts to just Game Chest and the tads2 and
> tads3 libraries; Game Chest would have to be upgraded to parse the iFiction
> XML format (it would also have to keep parsing the old format), and the
> libraries would have to generate the XML format. It's these bits of work
> that make me reluctant, but maybe it'd be worth it. The trade-off is that
> it's a fairly large one-time job, vs a trickle of ongoing work to keep the
> GameInfo schema up to date with the iFiction schema.
Would it be possible to appropriate some of the now-existing Babel
code for the Game Chest?
> If we were to switch to iFiction as the native format, my proposal would be
> as follows. We'd keep the GameInfo spec at v1, and that would continue to
> be a supported alternative forever; the TADS Babel plug-in would continue to
> recognize and translate that format to iFiction for Babel clients. We'd
> then define the GameInfo v2 format as (a) an iFiction-compliant XML file (b)
> embedded in a .gam/.t3 file as a multimedia resource called iFiction.xml.
> Finally, we'd define any TADS-specific extensions to the schema (htmlByLine,
> etc). I think that's basically the whole spec.
That seems to me to be the way to go.
Graham Nelson
Trinity box, but checking again, I find that it should indeed be
"cursed". Thanks.
Translations we regard as independent works with their own IFID. As you
say, this is quite normal for ISBNs. Indeed, we have independent
iFiction records for all four of Zork I, German Zork I, Zork I Solid
Gold edition, and Mini-Zork I: these are substantively different
editions. (With books, too, updated second editions often get new
ISBNs.)
I think reworkings by other authors also qualify for fresh IFIDs. For
instance, the Z-machine port of Dungeon - the original
mainframe-circulation Zork, during a brief interlude when the word
"Zork" was thought inappropriate - has a different IFID from any of the
above.
Tor
I've been wanting this for a long time.
Alan 2 and 3 are significantly different, enough
so that the interpreters are not compatible.
The alan2 interpreter cannot run alan3 games,
and vice versa. Doesn't this mean that alan2
and alan3 should be separate, the same way
that tads2 and tads3 are?
The section on Hugo IFID doesn't match
the implementation in hugo.c
The section on Level9 IFID doesn't match
the example iFiction entry later on in the spec.
The IFID section says that the IFID for
Dungeon Adventure is LEVEL9-006.
The IFID in the examples lists the IFID for
that game as an MD5-sum.
I have one question about the API: is there
any particular reason for passing the file
data as void* rather than char* or unsigned char*?
The code for scanning after UUID:// in glulx.c, hugo.c
and zcode.c is dangerous.
for(i=0;i<extent;i++) if (memcmp((char *)story_file+i,"UUID://",7)==0)
This accesses memory 7 bytes past the extents of the story_file buffer.
This is bound to cause a segfault sooner or later.
The code should read:
for (i = 0; i < extent - 7; i++)
if (memcmp((char*)story_file + i, "UUID://", 7) == 0)
Are there any plans or projects underway to populate the IFArchive with
data harvested from Baf's Guide?
Tor
Andrew Plotkin
>
> Are there any plans or projects underway to populate the IFArchive with
> data harvested from Baf's Guide?
It's on the list of "things we intend to work on pretty soon". :)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because you're innocent.
Andrew Plotkin
>
> Section 2.2 clearly states that story files from the same project should
> have identical IFIDs, and that, for instance, bug-fixes are not enough
> to warrant labeling something as a new project.
>
> At the same time, section 4.2(b) describes the to-be-followed policy of
> the IF-Archive like this: if two story files have the same IFID, then
> (1) if they are 'essentially different', the new story file will be
> rejected, while (2) if they are not, the new story file will become the
> new main file and the older story file may be removed.
>
> comply to section 4.2(b), authors who wish to release their work under
> free/OSS licenses are in trouble. (Unless I have misread or
> misunderstood the Treaty, in which case I'd live to be enlightened.)
The practical view, from the Archive maintainer's standpoint, is that
"essentially different" means "you accidentally submitted a completely
unrelated project with an IFID that's already in use".
When an author or a cooperating group of authors is working on a
project (and that includes OSS collaboration), then it's really going
to be up to them whether a new release gets a new IFID or keeps the
old one. What's going to wind up happening is that we'll look at the
IFID; if it hasn't changed, then this is a replacement release. If it
has changed, it goes up in parallel with the existing release. If the
IFID blatantly violates the guidelines of the treaty (different IFID
for a bug-fix release, or colliding IFID for an unrelated project)
then we'll contact the submitter and come to an understanding.
Rumors that "coming to an understanding" involves a horde of ninja
monkeys armed with elven shuriken are completely unfounded.
L. Ross Raszewski
>This is very good news! :)
>I've been wanting this for a long time.
>
>Alan 2 and 3 are significantly different, enough
>so that the interpreters are not compatible.
>The alan2 interpreter cannot run alan3 games,
>and vice versa. Doesn't this mean that alan2
>and alan3 should be separate, the same way
>that tads2 and tads3 are?
Unfortunately, Alan is not currently a signatory to the treaty. As
there weren't any alan 3 binaries available for me to study, the
question of whether Alan should be separated like this was deferred.
>
>The section on Hugo IFID doesn't match
>the implementation in hugo.c
>
You're right. At some point during the updates, we mislaid the current
version of the IFID definitions for Hugo, Level9 and Adrift. I caught
the Level9 mistake in time, but missed the other two. The next release
will include the proper text.
>The section on Level9 IFID doesn't match
>the example iFiction entry later on in the spec.
>The IFID section says that the IFID for
>Dungeon Adventure is LEVEL9-006.
>The IFID in the examples lists the IFID for
>that game as an MD5-sum.
>
Another change that will be made in the next release. That example is
indeed out of date.
>I have one question about the API: is there
>any particular reason for passing the file
>data as void* rather than char* or unsigned char*?
>
As far as I know, only nebulous philosophical reasons. There are some
interesting cases though; for example, Alan 2 internally stores the
entire game file as an array of Awords, and a hypothetical
Babel-enabled Alan terp might therefore want to pass that into the API
(Of course, this is a terrible example, because of the endianness
issue involved. My mind was kinda blown when I saw the way that Alan
chose to deal with it.)
>The code for scanning after UUID:// in glulx.c, hugo.c
>and zcode.c is dangerous.
>
>for(i=0;i<extent;i++) if (memcmp((char *)story_file+i,"UUID://",7)==0)
>
>This accesses memory 7 bytes past the extents of the story_file buffer.
>This is bound to cause a segfault sooner or later.
>The code should read:
>
>for (i = 0; i < extent - 7; i++)
>if (memcmp((char*)story_file + i, "UUID://", 7) == 0)
>
Thanks for this. I thought I had a good reason for doing it that
way when I wrote it, but since I can't recall it now, it appears you
are right.
>Are there any plans or projects underway to populate the IFArchive with
>data harvested from Baf's Guide?
>
My understanding is that, after a suitable period of discussion, there
will be a call for volunteers to help populate the if-archive.
Kevin Forchione
news:e2vv8h$pbr$1...@reader1.panix.com...
>
> The practical view, from the Archive maintainer's standpoint, is that
> "essentially different" means "you accidentally submitted a completely
> unrelated project with an IFID that's already in use".
Perhaps there ought to be some mechanism available on ifarchive to
"register" the game? Something that could either hash some portion of the
game file in return for a unique key, or at least allow it to return a
unique key for a title.
--Kevin
L. Ross Raszewski
I think that's probably overkill; the odds of two games having the
same IFID by accident is pretty small; as development systems are
updated, they'll probably start using UUID algorithms, and, unless
I've made some massive mistakes, the legacy algorithms for calculating
IFIDs should not provide collisions. Of course, it is possible to
fool the system if you're trying really hard to fool it (The default
MD5-based method for IFIDs could, obviously, be brought down by a
birthday attack). Heck, if I really wanted to, I could produce an
inform game right now which babel would identify as IFID: LEVEL9-001,
but anyone who did this would clearly be attempting some kind of abuse
and, I think, our general attitude has always been that someone
deliberately being a jerkass should be detected and dealt with "by
hand".
Victor Gijsbers
> When an author or a cooperating group of authors is working on a
> project (and that includes OSS collaboration), then it's really going
> to be up to them whether a new release gets a new IFID or keeps the
> old one. What's going to wind up happening is that we'll look at the
> IFID; if it hasn't changed, then this is a replacement release. If it
> has changed, it goes up in parallel with the existing release. If the
> IFID blatantly violates the guidelines of the treaty (different IFID
> for a bug-fix release, or colliding IFID for an unrelated project)
> then we'll contact the submitter and come to an understanding.
Yes, I am not worried about an author or a cooperating group; I am
worried about non-cooperating authors making derivatives of each other's
works. That is, I am not worried about that phenomenon - I would love to
see it happen, as a matter of a fact. But I am worried about your rule
of taking a new file with the same IFID as a replacement of the old file
by default.
If I were to release a piece under, say, the GPL (something which, in
fact, I have already done), there is one thing I would want to be sure
of: that there is not going to be some wacko who puts in an extra
softporn scene involving tentacled aliens, uploads it to the IF-Archive,
and has this automatically replace my original version!
So what I would like to see is an _explicit_ statement that the
IF-Archive will accept derivative works by authors other than the
original only under new IFIDs.
I also think it would be very useful to add a <derived from> and perhaps
also its reverse tag (<parent of> and <child of> might be less ambiguous
;) ) to the iFiction format. I realise that there is not an active scene
of people making derivative works in the IF-scene today, but I don't
think the Treaty should make the assumption that such a thing will not
happen in the future.
Regards,
Victor
Stephen Granade
That's been our approach with games before -- if you upload your own
version of "Curses," we're not going to automatically throw away
Graham's old version and put yours in its place. This won't be
completely automated; we'll still be making judgement calls. And in
the cases where it's not clear, we'll contact the authors in question.
Kevin Forchione
news:m1P4g.7$6d4.5@trnddc03...
> I think that's probably overkill; the odds of two games having the
> same IFID by accident is pretty small; as development systems are
> updated, they'll probably start using UUID algorithms, and, unless
> I've made some massive mistakes, the legacy algorithms for calculating
> IFIDs should not provide collisions. Of course, it is possible to
> fool the system if you're trying really hard to fool it (The default
> MD5-based method for IFIDs could, obviously, be brought down by a
> birthday attack). Heck, if I really wanted to, I could produce an
> inform game right now which babel would identify as IFID: LEVEL9-001,
> but anyone who did this would clearly be attempting some kind of abuse
> and, I think, our general attitude has always been that someone
> deliberately being a jerkass should be detected and dealt with "by
> hand".
And rightly so.
--Kevin
Gene Wirchenko
[snip]
>birthday attack). Heck, if I really wanted to, I could produce an
>inform game right now which babel would identify as IFID: LEVEL9-001,
>but anyone who did this would clearly be attempting some kind of abuse
>and, I think, our general attitude has always been that someone
>deliberately being a jerkass should be detected and dealt with "by
>hand".
Is Z-machine abuse abuse? What penalty do you suggest?
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Richard Bos
> On 29 Apr 2006 07:32:40 -0700, Tor <tor.an...@gmail.com> wrote:
> >This is very good news! :)
> >I've been wanting this for a long time.
> >
> >Alan 2 and 3 are significantly different, enough
> >so that the interpreters are not compatible.
> >The alan2 interpreter cannot run alan3 games,
> >and vice versa. Doesn't this mean that alan2
> >and alan3 should be separate, the same way
> >that tads2 and tads3 are?
>
> Unfortunately, Alan is not currently a signatory to the treaty. As
> there weren't any alan 3 binaries available for me to study, the
> question of whether Alan should be separated like this was deferred.
If you mean a game, there was one in the 2005 IF Comp.
Richard
Thomas Nilsson
news:%TM4g.404$t_2.209@trnddc07...
> On 29 Apr 2006 07:32:40 -0700, Tor <tor.an...@gmail.com> wrote:
>>This is very good news! :)
>>I've been wanting this for a long time.
>>
>>Alan 2 and 3 are significantly different, enough
>>so that the interpreters are not compatible.
>>The alan2 interpreter cannot run alan3 games,
>>and vice versa. Doesn't this mean that alan2
>>and alan3 should be separate, the same way
>>that tads2 and tads3 are?
>
> Unfortunately, Alan is not currently a signatory to the treaty. As
> there weren't any alan 3 binaries available for me to study, the
> question of whether Alan should be separated like this was deferred.
>
Of course Alan is interested in becoming a signatory!
I would like to raise a mild protest against the formulation in the
Treatey about "our attempts to make contact have been unsuccessful". I
am not very hard to get in contact with, a simple email to any of the
adresses in the FAQ or on the Alan Web site would work (unless written
to resemble spam, in which case it might have got caught, but
investigations failed to find any such e-mail).
Being a very sporadic reader of r.a.i-f, The Treaty was brougth to my
attention by a member on the Alan mailing list. I think it sounds like
a worthwhile project, although I am not yet fully confident in what
exactly is actually required by the game systems. But I will read up
on it, or perhaps someone could contact me and elaborate on the actual
requirements for becoming a signatory.
Alan v2 and Alan V3 are, as Tor pointed out, substantially different,
and will require two different ID:s.
/Thomas
tho...@junovagen.se
tho...@alanif.se
thomas....@progindus.se
Mike Roberts
>> [If we were to adopt iFiction as the native GameInfo v2 format,
>> then] Game Chest would have to be upgraded to parse the iFiction
>> XML format (it would also have to keep parsing the old format),
>
> Would it be possible to appropriate some of the now-existing Babel
> code for the Game Chest?
Possibly; the main new thing Game Chest would need is an XML parser. It
already does most of the other stuff that Babel has to do, particularly
parsing the .gam/.t3 file format to find the metdata packet in the first
place. Babel has a simple XML parser, but Ross built it specifically for
Babel and I'm not sure if it's fully generalized or just purpose-built for
some particular subset of the parsing he needed to do. (Ross, any opinion?)
If it's general-purpose enough that I could use it to pull out the fields
Game Chest is interested in, that would help.
On the other side - generating the XML data in the compilation process - I
don't think there's anything in Babel that could be brought to bear. But
that's the easier problem anyway; it mostly amounts to coming up with a
template and then substituting the various game-defined values into it, plus
whatever work is needed for XML escaping and so on.
L. Ross Raszewski
<thomas....@progindus.se> wrote:
>"L. Ross Raszewski" <lrasz...@loyola.edu> skrev i meddelandet
>news:%TM4g.404$t_2.209@trnddc07...
>> On 29 Apr 2006 07:32:40 -0700, Tor <tor.an...@gmail.com> wrote:
>>>This is very good news! :)
>>>I've been wanting this for a long time.
>>>
>>>Alan 2 and 3 are significantly different, enough
>>>so that the interpreters are not compatible.
>>>The alan2 interpreter cannot run alan3 games,
>>>and vice versa. Doesn't this mean that alan2
>>>and alan3 should be separate, the same way
>>>that tads2 and tads3 are?
>>
>> Unfortunately, Alan is not currently a signatory to the treaty. As
>> there weren't any alan 3 binaries available for me to study, the
>> question of whether Alan should be separated like this was deferred.
>>
>
>Of course Alan is interested in becoming a signatory!
>
>I would like to raise a mild protest against the formulation in the
>Treatey about "our attempts to make contact have been unsuccessful". I
>am not very hard to get in contact with, a simple email to any of the
>adresses in the FAQ or on the Alan Web site would work (unless written
>to resemble spam, in which case it might have got caught, but
>investigations failed to find any such e-mail).
We did try, emailing you several times at the address on the Alan home
page. If something technical prevented us from making contact, I apologize.
>
>Being a very sporadic reader of r.a.i-f, The Treaty was brougth to my
>attention by a member on the Alan mailing list. I think it sounds like
>a worthwhile project, although I am not yet fully confident in what
>exactly is actually required by the game systems. But I will read up
>on it, or perhaps someone could contact me and elaborate on the actual
>requirements for becoming a signatory.
I'll send you an email explaining what you'd need to do (not much)
>
>Alan v2 and Alan V3 are, as Tor pointed out, substantially different,
>and will require two different ID:s.
This will, of course, be open for discussion.
Mike Roberts
> Make the HtmlByLine and HtmlDesc elements CDATA.
Not a bad idea, although CDATA's a bit of a hack itself. There's a
practical drawback, though, which is that I'm not sure all XML parsers
actually support CDATA. The one in the Babel suite doesn't, I'm pretty sure
(Ross?).
L. Ross Raszewski
The main limitation of Babel's XML parser is that it doesn't support
anything in XML tha I don't have a simple and immediate understanding
of. I can't guarantee it would parse anything that isn't iFiction,
however, it *will* pull out any named field from an iFiction record.
The source for ifiction-xtract shows the simplest way to do that in
action.
Adam Thornton
Andrew Plotkin <erky...@eblong.com> wrote:
>When an author or a cooperating group of authors is working on a
>project (and that includes OSS collaboration), then it's really going
>to be up to them whether a new release gets a new IFID or keeps the
>old one. What's going to wind up happening is that we'll look at the
>IFID; if it hasn't changed, then this is a replacement release. If it
>has changed, it goes up in parallel with the existing release. If the
>IFID blatantly violates the guidelines of the treaty (different IFID
>for a bug-fix release, or colliding IFID for an unrelated project)
>then we'll contact the submitter and come to an understanding.
I may be coming a bit late to the game here, but wouldn't it make sense
to have a two-part IFID, so that the first part could uniquely identify
the work, and the second could uniquely identify the version release?
That way, when somebody reports a bug in "Stiffy Makane Goes To Oz" I
will know whether they mean the initial "L. Frank Baum" release or the
subsequent and even worse "Ruth Plumly Thompson" release.
Adam
Damian Dollahite
> "Shadow Wolf" <shadow...@NOSPAMyahoo.invalid> wrote:
>> Make the HtmlByLine and HtmlDesc elements CDATA.
>
> Not a bad idea, although CDATA's a bit of a hack itself. There's a
> practical drawback, though, which is that I'm not sure all XML parsers
> actually support CDATA. The one in the Babel suite doesn't, I'm pretty sure
> (Ross?).
>
CDATA isn't really a hack, it's a standard feature of SGML. However you
are correct that a lot of XML parsers don't support it. I'd recommend
entity-encoding, which all XML parsers will handle correctly.
Alternately, you could backport the XHTML versions from IFMES, which can
be included directly in XML documents without having to be protected at
all. Of course, they require well-formed markup, and the current TADS
HTML engine chokes on XHTML.
Speaking of IFMES, I have to say I'm kinda miffed about this whole
thing. I've spent months developing a complete, universal,
semantically-correct metadata format that can participate in the
Semantic Web [1], only to have this backwards, limited, semantically
questionable iFiction format sweep in out of the blue and trump IFMES. I
really hate wasting my time.
BTW, I'm still working on the Gameinfo 2.0 format [2]. I didn't send you
notice of the current draft because there's still some questionable
stuff that's likely to change---in particular, Andreas Sewe is reworking
the ABNF to work with LALR and LL parser generators. If you don't go to
XML, you might want to update to Gameinfo 2.0 at least.
--
Ryukage
[1]
http://www.scientificamerican.com/article.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21
[2] http://purl.org/int-fiction/ifmi/gameinfo/2.0
Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
Mike Roberts
> Mike Roberts wrote:
>> "Shadow Wolf" <shadow...@NOSPAMyahoo.invalid> wrote:
>>> Make the HtmlByLine and HtmlDesc elements CDATA.
>> Not a bad idea, although CDATA's a bit of a hack itself.
Even so, I think it's a hack. My objection is that it's not a true quoting
scheme, in that there's no way to quote the end-quote sequence if the quoted
material should happen to contain it. It's good enough for embedding most
html, but still.
Damian Dollahite
It's not supposed to be quoting scheme. It's a processor control
command, like DOCTYPE and comments. And you can include ]]> in the text,
you simply end the first CDATA block, then open a second for the next
part. When read back in, the result is a single text node.
--
Ryukage
Damian Dollahite
>
> I also think it would be very useful to add a <derived from> and perhaps
> also its reverse tag (<parent of> and <child of> might be less ambiguous
> ;) ) to the iFiction format. I realise that there is not an active scene
> of people making derivative works in the IF-scene today, but I don't
> think the Treaty should make the assumption that such a thing will not
> happen in the future.
>
That's probably out of the Treaty's scope. However, IFLink [1] provides
that capability. So if you want that sort of thing, start pressuring
Graham & co. to move toward the simpler IFMES/IFLink/IFCatalog system.
--
Ryukage
[1] http://purl.org/int-fiction/metadata/iflink/1.0
[2] http://purl.org/int-fiction/metadata/1.1
[3] http://purl.org/int-fiction/metadata/ifcatalog