Mimetype ".tw - tiddlywiki" in IANA, WICG, IETF (discussions\ideas\concepts)

Developers
#1

Hi all!

1. discussion

mimetype tiddlywiki in IANA, WICG, IETF (discussions\ideas\concepts)

2. description

I would like to contribute to tiddlywiki with mimetype like this:

  • text/tw as text/html
  • mimetype text/tw registration in IANA
  • mimetype text/tw registration in WICG
  • mimetype text/tw registration in IETF “Internet_Engineering_Task_Force” as RFC

3. Why is it important?

  1. I wrote about it here, and got a lot of interesting feedback json-in-tiddlywiki-by-standard
  2. I decided to create a discussion if you guys want a formal mimetype registration in major internet bodies like IANA/IETF/WICG so browsers recognize tiddlywiki as a different format than html so these files open normally without any problem
#2

TiddlyWiki already uses a vendor tree mime type that represents files with the extension .tid. The default mimetype the TW app uses is text/vnd.tiddlywiki … Which is part of the “vendor tree”.

The problem is, that we don’t have a formal description of that format and we didn’t register it. … yet.
I think, it would be worth to be registered in the vendor-tree, because meeting the requirements is much easier.

If we want to register a text/tw it would be part of the RFC 6838 - Standards Tree. In paragraph 7 it states:

The “owner” of a media type registered in the standards tree is
assumed to be the standards-related organization itself.

So I think we can not fulfil this requirement, except you own one or work for one and they support it.

1 Like
#3

I did follow the registration procedure of RFC 7763 The text/markdown Media Type and the companion document RFC 7764 Guidance on Markdown:
Design Philosophies, Stability Strategies, and Select Registrations very closely.

Since TiddlyWiki wikitext is very similar to Markdown in many regards we would also profit, if there would be a formal description of the syntax similar to the CommonMark specification

Many elements of the specs are already described at tiddlywiki-com. … We would need an edition, that only contains the spec. … Since tiddlywiki.com is a moving target.

1 Like
#4

Hi @pmario @anon5541130 good stuff. My only concern would be that text/tw is too generic, and that it might be better to use a longer name with a lower risk of a clash. Perhaps text/tiddlywiki?

The other thing to note is that as discussed in https://github.com/Jermolene/TiddlyWiki5/issues/345 I am interested in extending the TW content type with an additional vocabulary parameter that specifies the precise wikitext rules required for a particular block of text.

2 Likes
#5

I think there are 2 ways to achieve this: MIME-types can have parameters and URI fragments

parameters state:

New parameters SHOULD NOT be defined as a way to introduce new
functionality in types registered in the standards tree, although new
parameters MAY be added to convey additional information that does
not otherwise change existing functionality. An example of this
would be a “revision” parameter to indicate a revision level of an
external specification such as JPEG. Similar behavior is encouraged
for media types registered in the vendor or personal trees, but is
not required.

So parameters are very strict, since the have to be defined “upfront”. …

Full text of “Fragment Identifier Requirements”

4.11. Fragment Identifier Requirements

Media type registrations can specify how applications should interpret fragment identifiers (specified in Section 3.5 of [RFC3986]) associated with the media type. Media Type Registration January 2013 Media types are encouraged to adopt fragment identifier schemes that are used with semantically similar media types. In particular, media types that use a named structured syntax with a registered “+suffix” MUST follow whatever fragment identifier rules are given in the structured syntax suffix registration.

I’M not sure about that one, since it is a bit vague. … But this may be the possibility to be very dynamic, since the registration only needs to specify, how the fragments are interpreted.

What the app does with the fragments should be up to the defs. …

1 Like
#6

It should be possible to use text/vnd.tiddlywiki; parser=markdown; variant=GFM … Which indicates, that a markdown parser should be used and the markdown variant is GFM GitHub flavoured markdown.

I don’t know if using a fragment text/vnd.tiddlywiki #custom:markdown&variant:GFM would do the trick too. I didn’t find any examples yet, but as written above, it seems fragments may be more flexible

1 Like
#7

RFC 7764 Guidance on Markdown and text/markdown March 2016

Section: 2. Strategies for Preserving Media Type and Parameters

§ 4 states:

[RFC7763] only defines two parameters: the charset parameter (required for all text/* media types) and the variant parameter. [RFC6657] provides guidance on character-set parameter handling. The variant parameter provides a simple identifier – nothing less or more. Variants are allowed to define additional parameters when sent with the text/markdown media type; the variant can also introduce control information into the textual content stream (such as via a metadata block). Neither [RFC7763] nor this specification recommend any particular approach. However, the philosophy behind [RFC7763] is to preserve formats rather than create new ones, since supporting existing toolchains is more realistic than creating novel ones that lack traction in the Markdown community.

Which for me means that text/vnd.tiddlywiki+markdown; variant=XXX; would be an option … Where we can reuse the existing specification. … Our variant can be variant=tiddlywiki, since we would support a limited set of markdown … extended with our own set of functions like links and transclusions.

If the above is an option then text/vnd.tiddlywiki; vocabulary=tiddlywiki-classic; is an option too.

We could borrow the parameter syntax from Pandoc: RFC 7764: Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations

eg:

Additional Parameters:

 extensions: String with an optional starting syntax token,
             followed by a "+" and "-" delimited list of extension
             tokens.  "+" preceding an extension token turns the
             extension on; "-" turns the extension off.  The
             starting syntax tokens are "markdown",
             "markdown_strict", "markdown_phpextra", and
             "markdown_github".  If no starting syntax token is
             given, "markdown" is assumed.  The extension tokens
             include:

             Extensions to turn off (on by default):

             escaped_line_breaks
             blank_before_header

eg: text/vnd.tiddlywiki vocabulary=+tiddlywiki-classic -wikitext -xxx +katex …

BUT as written above. MIME type parameters are not very flexible and since TW is still in flux this may be a limiting factor.

1 Like
#8

On the other hand it may give us better interoperability since others would know, how to deal with that content …

1 Like
#9

Ciao @jeremyruston. That is one of the few far-out tech things I actually understand!
It makes a lot of sense to me.

TT

1 Like
#10

The explicitness of that seems useful to play with?
A “short-form” of it maybe later?

I’m just glad, as a naive user, to see discussion of this!
For me liberated/differential markup is a great step!
It is more important to me than most anything else for my use cases.

A comment, TT

1 Like