>> Here, as Chris has already suggested, we could keep both wikitexts as >> text/x-tiddlywiki, and make it a per-space setting to control which >> parser is used. > > This actually isn't my preferred solution. A preferred solution is > that each space declares which mime type they want their (new) tiddlers > to default to.
Well I was underlining my key point, which is that for me it's not yet clear that having two different content types is necessarily the best solution. Or at least, that I acknowledge that it is the prima facie obvious solution, but am keen to explore the ramifications on end users. I return to my analogy with HTML4 vs HTML5, which are incompatible but served with the same content type: one of the things we might explore is simple heuristics to allow the parser to determine which syntactic variant to use, allowing us to use a single content type. Right now, after all, everything in TW5 is entirely mutable. Being far from an expert on content types, I've wondered about using parameters like `text/x-tiddlywiki; newlines=old`. Presumably that's evil? Your second sentence about the preferred solution being that each space declares a default content type for new tiddlers would still hold true for me. > The global view on tiddyspace is that it just has tiddlers and a > tiddler can be _anything_. How they are presented is dependent on their > type. Agreed. > That those tiddlers that currently exist which have no type are treated > as tiddlywiki2text is an accident of history. Yes, although conceivably it may help us, in that there is little material out there that is yet explicitly tagged with a TiddlyWiki wikitext content type. On the TiddlyWiki side there is none. > To avoid continuing that accident in the future, when a new syntax is > introduced, tiddlers using that syntax should get a mime type and be > handled explicitly. That the change from tw2 to tw5 syntax is small > doesn't much matter: it still will require a transform and that > transform process can (and should) set the mime type. Yes, and that was my starting position too. My concern when we kicked off this discussion was just about the best names for the content types, and trying to focus things so that the clearest user experience is for users who arrive after the TW5 transition. > This is all in alignment with tiddlyweb raising the tiddler to the > primary entity. It's not the application (tiddlywiki etc) that > matters, it's the tiddler.[1] Yes, agreed. > This means, effectively, that a user can come along and say "I'm going > to start creating my textual tiddlers using tw5 syntax" _and_ they can > say "I'm going to use this app to do a one time transform of my > existing tiddlers to the new syntax" _and_ they can say "For these > tiddlers I'm going to use markdown". Yes, agreed. > And from an administrative side there is a time when we _could_ say > "The default app for new spaces creates tiddlywiki5 syntax tiddlers > (because it _is_ tiddywiki5)". Yes, agreed. > This seems at least spritually aligned with what I'm saying above. Yes, I think so. > If we treat a tiddler as a thing with a type, this doesn't seem all > that hard to me. The details are in how we present to the existing > tiddler keepers that they have the option to change if they want. Exactly. Best wishes jeremy > [1] http://cdent.tiddlyspace.com/Evolution > > > -- > Chris Dent http://burningchrome.com/ > [...] > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWikiDev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/tiddlywikidev?hl=en. > -- Jeremy Ruston mailto:[email protected] -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
