What's the relationship between this and ink components? about article HOT 5 CLOSED

thanks for clarifying this @rowanc1 - look forward to finding ways to standardize across these projects

from article.

iooxa.dev is a redesign/relaunch of ink-components, and helping to define where iooxa is going (interactive writing). I have split the package up into components that are easier to reuse, and on their own are not tied to iooxa indefinitely (simple names, low dependencies). I am wanting to follow (my interpretation of) some of the other examples in the community (Quantstack, Bloomberg, etc.) that incubate projects under a company and then if they become relevant/foundational (viola/bqplot, etc.) to the wider community, then they are potentially spun out on their own.

So at the moment, completely part of iooxa.

I think there is an opportunity to define some standards for interactive writing (similar concept to what JATS is like for publishing now, how do we move that towards the executional space?). That would be a project/standard I would love to help spearhead and be involved in, and something that would need it's own branding. I would love to chat through this a bit more if you want! :)

from article.

Sounds good - a couple quick responses:

I am wanting to follow (my interpretation of) some of the other examples in the community (Quantstack, Bloomberg, etc.) that incubate projects under a company and then if they become relevant/foundational (viola/bqplot, etc.) to the wider community, then they are potentially spun out on their own.

Totally makes sense to me. IMO, a big part of the success of these projects came from the authors intentionally building off of other standards in the ecosystem (as you're doing with web components) and continuing to do work with the broader community on top of their company-specific stuff (e.g. QuantStack did most of the leg-work in Voila, while also doing a lot of core work in Jupyter Lab / widgets / etc). Over time this helps build status and reputation, which can then be leveraged to get people to pay more attention to the open source tools they create. It is that interplay between a specialized and organization-driven tool, and intentional thought at how it fits in with the broader open source ecosystem, that helps these tools find their niche.

simple names, low dependencies

Ah I see - so the name of the tool is not "iooxa article", it is "article"?

similar concept to what JATS is like for publishing now, how do we move that towards the executional space?

That's a good question...what kinds of standards do you have in mind? (not the specifics, but what kinds of things do you imagine needing standards for?)

from article.

I think the components repo is probably where the bulk of the collaboration might be, as this repo gets a bit more opinionated about things. Once you import the names are simple: display, dynamic, range, var etc. that are also trying to mimic some of the other packages in the JS world (e.g. idyll).

That is where I see some of the standards starting to emerge - what are these components, and what are the attributes of them. Sketching a far off future: these are the standardized components that can be added to roles/directives (in myst), to web-components in HTML, to Jupyter markdown cells, etc. that allow you to make these explorable/reactive. I am still a bit fuzzy on how these work with/without a jupyter-like kernel. However, for "publishing" purposes, these standards are probably necessary down the road for archiving purposes.

from article.

Hopefully this is cleaned up now, had a good discussion with @choldgraf over in choldgraf/sphinx-explorable#1

from article.