Textual Editing

[rokke-git]

Currently, the best way I can find to edit a model textually is to download a model, make the edits, re-upload the file, and delete the original model. Would it be possible to create a directory on disk which is linked to a project?

ie, you make a directory for a project; and whenever you edit the model it overwrites that .sysml file, and whenever you edit the .sysml file it overwrites the model.

[gdaniel]

Hi,

Thanks for your interest in SysON.
You are right, it is not possible to textually update a model in SysON yet.
I see a few issues with the solution you propose:

SysON is a web application, you cannot create a directory on your machine and link it on the server. We could create this directory on the server-side, but this is quite far from what SysON does to store models, and it wouldn't be practical to use for you.

At the moment SysON does not store SysML models as textual SysML files. SysML models are serialized in JSON based on the Ecore metamodel we have for SysML. JSON documents are stored in our database, and updated when the models evolve. Note that the JSON serialization is way faster (and more complete) than the textual SysML import/export features.

In the future (no commitment here, just an insight on the roadmap), SysON should provide a way to textually edit model within the application. Would that solve your issue?

In the meantime the solution you found (download the model, update it on your side, then re-upload it) is the only way I can think about doing what you want to do.

[rokke-git]

I was more hoping to have files that could be opened in vim/emacs/vscode/etc, as these make many kinds of edits much easier than manually changing each individual thing.

to me, this would be much nicer than an in-application text editor. personally, the main draw of sysmlv2 over v1 for me was the fact that you can edit in vim.

from what I understand about containers, couldn't you create a directory on the server-side and still be able to access it from the base system? or at least be able to mount it as a network drive? if it's a problem of the time it takes to translate the model back and forth, having buttons to sync up and down from the model directory would still keep it clear to the user that it's a non-native format

[gdaniel]

The Dockerfile provided with SysON is a convenient way to start SysON on your machine for testing purposes.
SysON is designed to be deployed on a server, and accessed by multiple users simultaneously via the web interface.
Docker cannot help in this context: mounting directories works when SysON runs on the host machine, but this is not an assumption we want to make, because this is not how SysON is deployed in practice.

I hope this clarifies SysON's infrastructure

[rokke-git]

yes, but even when the server and client are different machines, you should still be able to mount it as a network drive, right? if the server is already hosting syson as a website, it should be able to use the same setup for a network drive as well.

once the directory is exposed to the server, it can be the server's job to expose that to the end user; it doesn't even have to be a service that you provide.

[gdaniel]

Thanks for the clarification, I understand better what you want now.

I am personally not convinced this solution would be better/easier to use than an in-application editor for the general audience of SysON. But I'll bring up your suggestion when we'll discuss how we want to support textuel editing.
Again, just to be clear, support for textual editing is not planned yet.

Anyways, regardless of the solution we chose, it will probably have to deal with similar concerns as the feature you want (e.g. sync the textual representation with the SysON model). If the result doesn't suit you, you can build on top of our services a solution that works better for you.

[rokke-git]

at least from what I can see, it seems like this should be much simpler than creating a full in-application text editor, since you already have import/export for single files/models; theoretically this could just be a loop that calls this function on each file in a directory/model in a project. the most annoying part of the current setup is the download/import selection popup and deleting the old model; this is mostly a suggestion for creating a button which streamlines this process.

additionally, this could act as a stopgap for the textual editor; as even people who aren't using vim/emacs/vscode will still usually have some sort of text editor installed on their system. that is not to say it goes the other direction though; once you have gotten used to an editor, using that editor is much faster than any other editor. for example; I had a model with a bunch of parts where the type names (different in capitalization) were left out, so I just typed qa/part^Mwyiw/def ^R"^Mwyiw``f;i : ^]pq30Q to bring the types in.

made a sample image of what I was thinking of, if it helps you

[Epictetusx]

I am really looking forward to a textual editor within the application. I would like to have the textual and graphical views side-by-side with 1-to-1 correspondence... which was one of the major promises of v2. I can see now how quick edits would be much faster if we could make small changes to the text. Right now I'm creating and editing text in VS Code with the SysIDE editor... but it's always gonna be out-of-sync with the model. To integrate a textual editor with SysON would be a game changer...

[stephanelacrampe]

Thank you, Jay, I also saw your comment on the discord server. I agree with you. I believe this is not likely to happen in the next couple of months, for various technical and not technical reasons that I cannot really expand on here. But this is definitely something we have in mind, and I am confident this will come one day...

[dgvalde]

While I understand the technical limitations based on how the model is internally stored I have to admit I am very dissapointed that SysML2 tools do not provide a code-first experience. This is what makes SysMLv2 so attractive and cannot comprehend why this is not a priority for SysON.
A future sysml practicioner should become fluent on the textual notation and be able to understand that textual notation in parallel to modeling regardless if a graphical representation is also used. Downloading a complete sysml file for the complete model from time to time is not the way to go. Jumping between graphical and text representations back and forth continuosly is the only way I see adoption (and power) of sysml v2 lies on.

I think SysON/Obeo shall reconsider the strategy here and prioritize this over any other feature they might be working on.

[mbats]

Thanks for the feedback. We actually agree with the core point: textual notation is an important part of SysML v2, and being able to move naturally between textual and graphical representations is part of the experience we want SysON to provide.

The question for us is less whether SysON should support textual editing, and more how to integrate it properly with the rest of the modeling environment.

SysON maintains a shared semantic model that can be edited concurrently and represented through diagrams, tables, forms, and other views. A textual representation therefore needs to behave as another synchronized view of that same model, rather than as a separate representation that users have to manually import/export and keep in sync.

This raises several challenges around synchronization, partial model editing, validation, concurrent editing, and maintaining a consistent user experience across representations.

So I would not interpret the current situation as SysON considering textual modeling unimportant. On the contrary, we see a synchronized textual/graphical experience as an important direction for SysON.

At the same time, we have to balance this with the other capabilities required to make SysON a complete collaborative SysML v2 modeling environment, so we cannot currently commit to prioritizing textual editing over every other feature.

As an open source project, contributions and sponsorship are also ways to help shape and accelerate the roadmap. If textual editing is particularly important for your organization or use cases, we would be very happy to discuss how sponsoring this development could help us prioritize and deliver it sooner.

In any case, the workflow you describe, continuously navigating and editing the same semantic model through both textual and graphical representations, is definitely a use case we want to address.