5.5.2. <format>

[Baltasar García Perez-Schofield]

Hi, there,

This is about the format label. The treaty of Babel says that it can have the following values:

zcode, glulx, tads2, tads3, hugo, alan, adrift, level9, agt,
	magscrolls, advsys, executable

Among these values there is no place for a new piece of IF written in Twine, Undum or ChoiceScript, to put an example. It is also not possible for games written in fi.js (an authoring system of my own, for instance http://www.caad.es/baltasarq/if/montecristo/ ) to include bibliographic information.

This tag is mandatory, so there is no escape.

I also wrote a little app that makes it possible to generate a small XML file with bibliographic information such as the IFID, title, subtitle, description and some other (the minimal) fields: http://www.caad.es/baltasarq/prys/babble/

An example of such small XML file could be this one (it is also bundled in the blorb of this Glulx game):

http://www.caad.es/baltasarq/if/survive/survive.ifiction

It would be great to be able to include this kind of bibliographic info with this HTML kind of IF pieces. The treaty of Babel says that if a piece of IF does not fit in any clause, then you can just use an UUID (or its MD5 hash). This is great for identification, but does not provide any other info about the game itself.

My proposals are simple (and mutually exclusive):

1. Make the format tag optional. The info provided in this format tag is not so important.

2. Add the value "HTML" to the format tag. Or maybe just "other". Or maybe both.

What do you think?

[Andrew Plotkin]

On Wed, 1 Oct 2014, Baltasar García Perez-Schofield wrote:

> Hi, there,

Hi -- welcome to the list.

> This is about the format label. The treaty of Babel says that it can have
> the following values:
>
> zcode, glulx, tads2, tads3, hugo, alan, adrift, level9, agt,
> magscrolls, advsys, executable
>
>
> Among these values there is no place for a new piece of IF written in
> Twine, Undum or ChoiceScript, to put an example. It is also not possible
> for games written in fi.js (an authoring system of my own, for instance
> http://www.caad.es/baltasarq/if/montecristo/ ) to include bibliographic
> information.

True.

I think it would be best to treat this as an open tag. (But still
mandatory.) If you have a new IF system, pick a format value and post it
here; I'll update the Babel document. Or, if I'm lazy about the Babel
document, people can still agree on format values by reading the list.

> 2. Add the value "HTML" to the format tag. Or maybe just "other". Or maybe
> both.

Using "html" would certainly make sense in these modern times.
(Lower-case, to match the others.)

This doesn't distinguish Twine from other HTML-generating systems. But the
format is more about distinguishing the game file and what tool you need
to play it. (This is why "zcode" and "glulx" are on the list but not
"inform6" or "inform7".) So I'd say "html" for anything which runs in an
ordinary web browser.

(Avoiding the question of Parchment packages...)

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

[Brandon Invergo]

> I think it would be best to treat this as an open tag. (But still
> mandatory.) If you have a new IF system, pick a format value and post
> it here; I'll update the Babel document. Or, if I'm lazy about the
> Babel document, people can still agree on format values by reading the
> list.

What about putting the document in a repo and allowing people to submit
patches? It would make your job easier I think (not that very many
patches would be rolling in). It's not just the format tag, but also
format-specific tags (sec. 5.10) that might need updating when a new
format is added.

Also, sec 2.3.2 asks for maintainers of new systems to contribute C code
for babel; this might also be more easily handled via a public
repository.

Thoughts?



--
Brandon Invergo
http://brandon.invergo.net

[Baltasar García Perez-Schofield]

Hi,

>> I think it would be best to treat this as an open tag. (But still
>> mandatory.) If you have a new IF system, pick a format value and post
>> it here; I'll update the Babel document. Or, if I'm lazy about the
>> Babel document, people can still agree on format values by reading the
>> list.

Okay, then I assume the html value for the 5.5.2 format tag is now valid. I'll also update Babble.

--
Baltasar (balt...@gmail.com http://baltasarq.info/)

[Baltasar García Perez-Schofield]

Hi,

I've updated Babble

https://github.com/Baltasarq/Babble/

...in order to give support for the html value in the format tag.

[Andrew Plotkin]

Sorry about the delay in replying. I've been shipping a game. :)

I've added a document http://babel.ifarchive.org/babel_rev9.txt
with these additions:

-----------------
Discussion of Treaty issues, including questions and proposals, may
be sent to the Babel mailing list:

babe...@googlegroups.com
http://groups.google.com/group/babel-if
-----------------
The value of <format> may therefore be one of the following:
[instead of "...should therefore be..."]
[and added "html" as a possible value for the format, and a
format-specific <html> tag]
-----------------
The format "html" means that this is an HTML file, perhaps collected
with associated files such as CSS and Javascript. The intended
interpreter is a standard web browser.
-----------------
Other format values may be added in future revisions. A value not
listed above may be assumed to be in informal use by the users of an
IF system not yet part of the Treaty. We expect that such systems
will be added to this document in due course.

(New format values must not collide with tag names already defined by
this document. This ensures that format-specific tags can be used
without confusion.)
-----------------

Does this sound sensible? If there are no objections, I'll update the
front page to make this official.

On Wed, 1 Oct 2014, Brandon Invergo wrote:

> What about putting the document in a repo and allowing people to submit
> patches? It would make your job easier I think (not that very many
> patches would be rolling in). It's not just the format tag, but also
> format-specific tags (sec. 5.10) that might need updating when a new
> format is added.
>
> Also, sec 2.3.2 asks for maintainers of new systems to contribute C code
> for babel; this might also be more easily handled via a public
> repository.

I agree that a (distributed version-control) repository would make sense,
but I would rather do it lazily. That is, not start until more revisions
come in. :)

[Baltasar García Perez-Schofield]

Works for me!

--

-- Baltasar

[Brandon Invergo]

> Sorry about the delay in replying. I've been shipping a game. :)

Understood, and looking forward to it :)

> Does this sound sensible? If there are no objections, I'll update the
> front page to make this official.

That all looked fine to me.

> I agree that a (distributed version-control) repository would make
> sense, but I would rather do it lazily. That is, not start until more
> revisions come in. :)

Also understandable!

I'll update pyifbabel once the treaty is updated. I have a new release
to make soon anyway.

-brandon

[Andrew Plotkin]

On Fri, 24 Oct 2014, Andrew Plotkin wrote:

> If there are no objections, I'll update the front page to make this
> official.

Someone on the web forum
(http://www.intfiction.org/forum/viewtopic.php?f=38&t=16949) brought up
the idea of a tag for "what development tool was used to create this?"
I.e. "Inform 6", "Inform 7", "Twine". (As opposed to the <format> tag,
which is "zcode", "glulx", "html".)

I don't remember any discussion of this back when Babel was originally set
up. But my memory is poor for these matters.

(The document mentions that Inform 7 sets the <group> tag to "Inform", but
it also says that the user is expected to set up their own groups and
change that tag as desired.)

I'm okay with this idea. I'd name it <devtool>; it would be optional, and
live in the <bibliographic> section. Content intended to be human-
readable, and left up to the development tool to generate. (I lean towards
verbose version numbers -- "Inform 7 build 6L38" -- but I don't want to
mandate that.)

[Baltasar García Perez-Schofield]

Hi,

I'm glad that this tag will be optional. In many aspects, I find the treaty of babel too comprehensive for no reason at all: at last, the important aspects are those like author, title, and what the story is about.

Some technical info for how to trigger the execution of the story is okay, but for example, I don't really get what this "group" section is for.

Also, it seems to be too related to Inform 7, I know it is the development tool of choice for many people, but...

Anyway: yes, an optional devtool tag will not harm anyone.

--

-- Baltasar

[Brandon Invergo]

> I'm okay with this idea. I'd name it <devtool>; it would be optional,
> and live in the <bibliographic> section. Content intended to be human-
> readable, and left up to the development tool to generate. (I lean
> towards verbose version numbers -- "Inform 7 build 6L38" -- but I
> don't want to mandate that.)

If it's left up to the development tool to generate, isn't that already
covered in the <release><compiler> and/or <colophon><generator>
sections?

-brandon

[Brandon Invergo]

Brandon Invergo <bra...@invergo.net> writes:

>> I'm okay with this idea. I'd name it <devtool>; it would be optional,
>> and live in the <bibliographic> section. Content intended to be human-
>> readable, and left up to the development tool to generate. (I lean
>> towards verbose version numbers -- "Inform 7 build 6L38" -- but I
>> don't want to mandate that.)
>
> If it's left up to the development tool to generate, isn't that already
> covered in the <release><compiler> and/or <colophon><generator>
> sections?

Another comment is that, since IFiction allows multiple IFIDs, it is
potentially (although admittedly not likely) describing files generated
by different dev tools. I'm thinking mainly of ports of old games and
the like, rare though they may be. This, again, is amply covered by the
<releases> section.

[Andrew Plotkin]

On Wed, 29 Oct 2014, Brandon Invergo wrote:

>> I'm okay with this idea. I'd name it <devtool>; it would be optional,
>> and live in the <bibliographic> section. Content intended to be human-
>> readable, and left up to the development tool to generate. (I lean
>> towards verbose version numbers -- "Inform 7 build 6L38" -- but I
>> don't want to mandate that.)
>
> If it's left up to the development tool to generate, isn't that already
> covered in the <release><compiler> and/or <colophon><generator>
> sections?

<release><compiler> covers it, yeah. Never mind. I didn't read before
posting.

(<colophon><generator> is the generator of the iFiction record, not the
game.)