1. idea
- logical layer from the application: “editor.js”- “JSONSchema”
and/or - interface/interaction layer: “UISchema”
and/or - data layer: “JSONSchema”
2. concept
2.1 concept 1
Hi Eduardo
Thanks for your summary. But I’m not really sure what you try to achieve. We already use JSON as internal data store. Even if it is kind of human readable it is way to complicated for standard users.
TiddlyWiki is designed to be used by users that have no technical background. They should still be able to change components that usually only can be changed by programmers.
I’m on mobile at the moment, so I’ll reply late in more detail.
1 Like
Right. I’m one of those. And want to stay one 
.
I have got as far as understanding JSON “flat-file”. That I can understand.
I do think the internal storage in TW via JSON clever and very manipulable, if needed.
@anon5541130 Why would we need anything more complex for data interchange?
A comment, TT
1 Like
@TiddlyTweeter @pmario thank you for feedback!
1. Why is it important?
-
This reduce tiddlywiki file size - why?
Response: This separate specific data types like JSONSchema, UISchema, JSONSchemaEdit-js, plaintext - you separate configuration parts from data and application logic parts which follows my line of thought, concept I propose and result -
My idea is the following we have a template template and the text file. We can send the copy of the template template to some backup service like: google drive/dropbox etc - I’m thinking of a universal plugin for this
- Getting back to what I was saying, in the case of separating the template template from the text template
- you get it with a good chance of having more security - since you can sync the template template to a remote server and sync the text file on another remote server. The idea here would be to split the file in two, in such a way that no part of that file is lost. It’s even easier to manipulate the template part and the text part.
- A good example of what I’m talking about is the case of EDL, you can split part of the text file and synchronize with the json configuration part.
- This guarantees, for example, that if the model is modified, it does not make the text part manipulable, you guarantee greater reliability in the parts of the file without them suffering interference. A good example of this specific use is Xanadu.
-
Template file: model-layout(database: JSONSchema, UISchema, JSONSchemaEdit-js), plain text file " edl", “opendocument”, “object data linking”.
-
It is highly modular
-
Easy to use, manage
-
Makes life easier for users
-
It is aesthetically beautiful
-
Great for multiple sync
-
What I’m proposing here is the tiddlywiki file format which is made through these layers: ‘logical layer from the application’, ‘interface/interaction layer’, data layer.
2. Sample “library-js: hope.js”
0-43:h3
45-139:p
116-126:a href="http://en.wikipedia.org/wiki/Ted_Nelson"
141-368:p
205-213:a href="http://en.wikipedia.org/wiki/Project_Xanadu#Original_17_rules"
371-683:p
441-464:a href="http://blog.codinghorror.com/what-you-cant-see-you-cant-get/"
685-939:p
941-1223:p
1185-1191:em
1205-1211:em
1225-1356:p
1358-1368:h3
1370-2351:ul
1370-1468:li
1470-1622:li
1624-1698:li
1700-1759:li
1761-1925:li
1927-2072:li
2074-2350:li
2352-2453:p
2403-2428:a href="https://github.com/poef/hope"
2.1 sample: “editor.js”- “JSONSchema”+ “UISchema”+ “JSONSchema”+“hope-js” = json in tiddlywiki by standard
{
"app": {
"config": "./settings.json",
"cwd": "./",
"src": "example/content/",
"filePattern": "**/*.md",
"dist": "example/output.json",
"name": "markdown-json",
"version": "0.0.1"
},
"data": [
{
"section": "Elements",
"title": "buttons",
"device": [
"desktop",
"mobile"
],
"styles": [
"https://example.com/styles/structure.min.css",
"https://example.com/styles/app.min.css"
],
"contents": "116-126:a","reference:href", "link:"http://en.wikipedia.org/wiki/Ted_Nelson",
"id": "buttons",
"meta": {
"relativePath": "content/buttons.html",
"createdAt": "2020-10-08T16:05:30.415Z",
"lastModified": "2020-10-08T16:05:14.452Z",
"size": 2095,
"formattedSize": "2.0 KB"
}
},
]
}
4. References
1 Like
- This is responsible for customizing the text content in a specific part
- 116-126(start characters and end characters)
- Maybe in the future we can create an RFC in IEFT about the .tiddlywiki file format
TLDR;
There was a discussion about interchangeable field names with the help of Ontology definitions
IMO the linked topic above and your thread here share some common interests. … They both can help to increase interoperability. … They are not the same but imo close enough to create the connection.
But both topics are for developers only.
Not really. JSON keys and values can’t be “minified”. If we remove linebreaks and indentation we will loose human readability. So I don’t see any size related win here.
One of the biggest advantages of TW is, that it is schema-less. Our users will need to be able to store any data they want. 95% have no idea what a schema is and that’s OK. They shouldn’t need to care about it.
So is wikitext and the tiddler format, which internally is an Object store, which can easily be serialised into JSON if we need to.
100% of the TW UI is built using wikitext, that is parsed and internally translated into widgets. The advantage is, users don’t need to know about it.
Not true for non tech users. Creating a JSON structure that parses without errors in a consistent way the first time you save the tiddler, is hard. Even for experienced programmers. The most common error is missing commas and braces.
May be if you are a programmer. No if you read my last response.
If we want to make the file size smaller and minify the JSON data, then no. It’s unreadable in that form, without external help.
Internally we already us JSON as our main data format, but it doesn’t need to be exposed to our end users.
2 Likes
1. Idea\concept
This can be done using the edl concept - here is a brief example:
"contents": "116-126:a", // 116-126(start characters and end characters) to anchor 'a'
"reference":"href", // reference('a') with href
"link":"http://en.wikipedia.org/wiki/Ted_Nelson", // reference('a') with link
// <a href="http://en.wikipedia.org/wiki/Ted_Nelson"> words words .... </a>
2. other concept
<script src="https://cdnjs.cloudflare.com/.../json2html.min.js"></script>
<script>
let data = [
{"title":"Heat","year":"1995"},
{"title":"Snatch","year":"2000"},
{"title":"Up","year":"2009"},
{"title":"Unforgiven","year":"1992"},
{"title":"Amadeus","year":"1984"}
];
let template = {'<>':'div','html':'${title} ${year}'};
//render
document.write( json2html.render(data,template) );
</script>
3. References
- https:// json2html. com/
1 Like
@anon5541130 … That’s a very interesting thread. I do enjoy it.
That’s interesting, but the first paragraph catches my eye:
Note: this project is superceded by cobalt
cobalt is interesting too, but the last release was 2015 … So for me personally it may be interesting from an archaeological point of view, to study the concepts involved. But a version number 0.1.0 imo is far away from production.
I don’t know the library, but it seems to be a templating engine that can convert a JSON structure to HTML output. … That’s nice for static HTML output.
But what, if we have a templating engine that allows ordinary users to create a fully dynamic, basic task manager with 13 lines of code, that works in the “story river”, in the sidebar-tab and is part of the TOC (table of contents)
We create 2 tiddlers
- 1st TaskDraggableTemplate with the content below
- 2nd simple-task-manager with the content below
title: TaskDraggableTemplate
<$checkbox tag="done"> <$link to={{!!title}}><$view field="title"/></$link></$checkbox>
Second tiddler
title: simple-task-manager
caption: Tasks
tags: $:/tags/SideBar TableOfContents
!! Outstanding tasks
<$button>
<$action-sendmessage $message="tm-new-tiddler" title="New Task" tags="task" />New Task
</$button>
//Drag the tasks to re-order them//
<<list-tagged-draggable tag:"task" subFilter:"!has[draft.of]!tag[done]" itemTemplate:"TaskDraggableTemplate" emptyMessage:"You don't have any active tasks">>
!! Completed tasks
<$list filter="[!has[draft.of]tag[task]tag[done]sort[created]]">
<div>
<$checkbox tag="done"> ~~<$link to={{!!title}}><$view field="title"/></$link>~~</$checkbox>
</div>
</$list>
TW wikitext is very very powerful.
I need to think about this one. … But I do like the idea of the Xanadu project
I also like the idea of Hypercore which is a decentralised peer to peer protocol with security built in.
If you want to capture edits, then atJSON might be interesting to look at https://github.com/CondeNast/atjson
1 Like
This is not seen by the user but internally by the application.
example in markdown
my concept
reference
1. intro
- My concept is that the tiddlywiki file is readable by the browser - but it is a binary file like the PDF - however unlike the PDF the tiddlywiki file can be viewed, changed to create new modified tiddlywiki files - the difference from the approach with the PDF is that here tiddlywiki looks like opendocument in a structural sense - another difference is that how it opens the information in the browser - that same information can be taken elsewhere
- Think about this concept here: PDF+OpenDocument+Json+Browser+Web Bundle = tiddlywiki ;D
more note
- by technical definition any binary file is unstructured data, which by definition of the word unstructured data makes me wonder if tiddlywiki follows the idea of unstructured data or if tiddlywiki is just semi-structured data.
- See, Ted Nelson in your articles and ideas - I could be wrong, but I don’t know personally just that they speak in different it groups etc - I’ll cut to the chase… your ideas are for unstructured data, including the idea of inline markup was exactly that, an embedded markup that was binary, that is, not readable to humans and only machines
- a good example of this use case would be wysiwyg editor - you just need to mark up the text you want just by looking at the markup you’d like to do - things like Microsoft Office/Libre Office do the same thing
proof
references
benefits
- read only by machines “json in tiddlywiki by standard” is binary file
- it is highly shareable: “plugin odbc for tiddlywiki-json-by-standard”
- it is highly modular: “atjson”/“plugins tiddlywiki”
- it is highly small: “is as bson”
with your tiddlywikis you can generate other files like pdf, markdown etc
please, see this: github-com/clarkduvall/JSOL -
my idea
- my idea would be to autogenerate plugins like create-react-apps
https://tiddlywiki.com/dev/static/How%20to%20create%20plugins%20in%20the%20browser.html - https://tiddlywiki.com/dev/static/Developing%20plugins%20using%20Node.js%20and%20GitHub.html
- https://tiddlywiki.com/static/PluginMechanism.html
- Creating Plugins: Grok TiddlyWiki — Build a deep, lasting understanding of TiddlyWiki
This is still a short draft, and I’m open to new ideas, proposals, improvement or fixes
Standards(formats\apps\technologies) I’m Watching To Make This Possible
- “package.json”
- JSONSchema: “UISchema”
- JSONSchema: “DataSchema”
- JSONSchema: “Editor-js”
- EDL
- BSON
- OpenDocument
- JSON
- Wikitext
- Json2HTML
- Created-react-apps for “created-tiddywiki-plugins”
- atjson
- Web Bundle
- JSOL
concepts
- tiddlywiki → “package.json”+“EDL”, JSONSchema: “UISchema”+JSONSchema: “DataSchema”+JSONSchema: “Editor-js” → struct tiddlywiki “file format as web bundle/OpenDocument/PDF/BSON”
- Created-react-apps “created-tiddywiki-plugins” → generate plugins tiddlywiki
- tiddlywiki-app-engine: “Json2HTML”, “atjson”, “JSOL”, “Wikitext”
1. Disadvantages of the pdf file
Although there are some note-worthy benefits of using PDF files, there are also some grave disadvantages of using this type of format.
- Cost of editing. Unfortunately - it’s not possible to directly edit your PDF file for free. You would need to use a platform such as Adobe Acrobat and other costly PDF editing softwares to acquire the “editing” function. This is a great disadvantage of the PDF as it doesn’t allow for corrections to be made easily.
- Layout. Although PDF files are ideal for printing - their pages are commonly in A3 or A4 format, making it hard to see each full page at a time. This results in a lot of scrolling and zooming in, which definitely dissatisfies “user-experience”.
- Basic. Despite the fact that PDF formats facilitate some interactive elements - let’s face it - it doesn’t engage readers as much as alternative formats due to its simplistic and rigid presentation. This can be seen as one of the disadvantages of the PDF file, making newer, more modern alternatives to PDFs more desirable!
2. Advantages of the opendocument file
3. Disadvantages of the web-bundle file
- Now that I’ve piqued your interest and sold you on Web Bundles, I need to mention a couple of limitations. As with any piece of technology, Web Bundles are better suited for some situations than others.
- Anything stored on servers won’t be encapsulated so this limits the functionality of what can be bundled. Web Bundles are especially effective for static websites such as many blogs, online portfolios and games. This is because they don’t require API calls to servers.
- Another issue is Web Bundles require user awareness. If your browser automatically cached the bundle of every site or web app you use, it would quickly fill your memory. The only feasible option is the user needs to know it’s an option to right-click and save their site of interest manually.
4. Advantages of the proposed file format “.tiddlywiki new format”
- There is no editing cost, you can edit in tiddlywiki-app itself or in the browser
- It is possible to have different types of layout
- There are several types of interactive element with tiddlywiki
- Supported by multiple applications
- Separation of content, presentation, logic, interface/interaction, data, metadata
- Mixed JSONSchemas/Markup: “UISchema”, “DataSchema”, “Editor-js”, “atjson”, “wikitext”
- “what is paid are plugins to change or added some functionality in .tiddlywiki documents” - this does not change your edition, it only changes its functioning, its visualization
- Expert and community technical support
- API calls to servers
5. References
- This problem is solved, because part of the tiddlywiki information is sent to external and remote servers - as there are parts of the file that are synchronized, this prevents, for example, that a large file takes up a lot of memory or storage space. Other parts of the file are attached locally.
- Binary JSON format is a relatively small format and takes up less space than a PDF/Open Document/Web package. The idea of the tiddlywiki binary JSON format is to have some nice aspects of things in the PDF/Open Document/Web package - but without having a relatively high storage size.
- This happens because the plugins that need to be loaded are not packaged in the final file - there is a part of the json responsible for storing the corresponding plugin links that you purchased or had access to.
- As much of the data is plain text, there are no security/virus issues etc.
- The idea is to create text metadata to match the formatting