fdb75017

Thanks for your feedback !

Well I'm proposing to have a workspace with everything structured indeed, where all the documents would be "programmable" and "queryable" and where unstructured data would simply be attachments of structured data.

At some point when uploading a new "file", I think the framework should systematically call a multimodal LLM to extract structured data from it, so that it can be queried from anywhere in the workspace. My main concern on this is that the LLM should stay local...

Yes you are right this is lacking a good and simple demo usecase, I'm working on it.

Yes, as you've seen, some field types have a limited set of "builtin methods" that I've added just for the demo, and List is clearly the one that should have much more ! (map, reduce, filter, sort, sum...).

And indeed, being able to call methods dynamically in "formulas" like Excel does, and not just when clicking on buttons (what excel calls "macros") is a must-have as well !

OK I see. I think exporting to JSON Schema is a feature to implement.

But again, there would be some situations where the 2 representations would not be reconcilable: you would not be able to stream out views & methods to JSON Schema, and in the other way, some weakly declared heterogeneous types of json schema like oneOf, allOf, anyOf might not always be representable in this framework.

Thanks for your feedback !

It does not rely on JSON schema at all, the idea was to build a representation that binds together data structure, views and behavior in a self-contained way (like .xlsx does).

There are a few tools that do enable to link JSON schema to views, like react-jsonschema-form (https://rjsf-team.github.io/react-jsonschema-form/) but you need to manage them separately, and they usually do not propose a way to add the fields "methods" (which was the feature I found interesting to make "dynamic" spreadsheets).

That being said, I think the framework should clearly propose an export from Schema to JSON Schema or Yaml at some point, just as you should be able to start building your Schema by importing a JSON Schema (and although there might be some gray zones between the 2).

No, sorry, it's not yet open-source, and currently there are some strong links between Document and Workspace (Links, Files...) that would need to be more "abstracted" to make the builder an independent component. But I hear you point ! (and all the comments in this thread are raising the same ! :) )

Thanks ! No, sorry, it's not yet open-source, but i think it will be at some point.

OK, thanks for your words !

By standalone web component do you mean like a React component that you can embed in your own app ? Or something more "bundled" like a VS Code extension ?

In terms of scope, you are thinking of both the "Editor" and the "Schema builder" ?

My initial intention was more to build a monolith app, like a simple version of MS Office for jsons. There are already some strong links between the notions of workspace and document: for example the Link field captures an id of another document or record that you have in your workspace, same for File and Image fields... (I guess a next step in the future would be to incorporate the notions of users & groups...). That could probably be abstracted by having something more plugin-based where you provide to the component your description for "what is another document" or "what is a file".

But I think I got your point as well that, if it is deemed to be a framework, it would be useful to let other platforms or verticalized apps use the same representation !

Many thanks for your feedback, very useful !

Yes you are right, the complexity at first sight is a problem. The onboarding journey should be clearer, and indeed there is too much jargon to digest before you can really start. That's also probably because it's more the basis of a framework than a concrete product to use as is (hence the rather detailed but probably too long documentation). All the fixes you mentioned would clearly improve this first impression. Thanks !