Support schema definitions

[stevespringett]

Currently, this repo consists of SVG and XMI for describing the model. Developing a SBOM schema by vector image or using XMI (an XML format that no tool understands) is a non-starter. I cannot see how this effort will be successful if we are looking at images without the ability discover, or dynamically browse the schema we're developing.

This seems to be multiple anti-patterns laid on top of each other in order to satisfy a standards body's requirements. It's actually quite crippling when you factor in that only a single individual in the working groups knows how to use the tool and has been doing all the development.

If you want increased participation in this effort, first-class support for XSD and JSON schema should be the approach. Let the community use the vast selection of tools available to understand and help develop the schema. Then use whatever conversion utility is required to generate the XMI to satisfy the standards body.

Without this capability, this project will likely never receive PRs to add corrections or other changes to the model as I don't think anyone will take the time to submit PRs against a vector image or XMI.

[kaywilliams]

Philippe-Emmanuel, I believe our proposed path is to iterate on the modeling using a UML tool (see list of UML tools here - https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools ). The tool you are using is GenMyModel (https://www.genmymodel.com/). Can you confirm?

[stevespringett]

The current xmi model (posted about 4 hours ago), cannot be imported into GenMyModel.

When importing it, the error reads:

Project cannot be created
Sorry but we couldn't detect the type of this model

The xmi also cannot be imported into StarUML (which also supports xmi 2.0 and 2.1). The issue with xmi, is that there are so many incompatibilities between the various tools it basically makes it unusable for sharing.

Of interest, I also have the same problem with SPDX which about two weeks ago published their model in xmi format, neither GenMyModel or StarUML work.

If the current model was created with GenMyModel (which I believe it was), then its export function is broken because it cannot be reimported.

So we currently have an xmi specification with tool-chain incompatibilities which prevent us from working on the model. We need to solve this issue if we are to successfully collaborate on the model.

Again, since xmi is such an issue, we should be developing with standards that are widely supported and interchangeable like XML Schema and JSON Schema. Developing to these specs first would allow us to rapidly prototype and then once we have something we think can be submitted, then worry about xmi. This xmi-first approach is inherently broken. I've wasted too many hours today dealing with it. Done.

[CASTResearchLabs]

I can provide (later, I’m connecting in London right now) the XMI from GenMyModel Philippe-Emmanuel Douziech Principal Research Scientist, CAST Research Labs M: +33 6 69 95 49 59<tel:+33%206%2069%2095%2049%2059> CAST<http://www.castsoftware.com/> | Software Intelligence for Digital Leaders | Blog<http://www.castsoftware.com/blog> | LinkedIn<https://www.linkedin.com/company/162909/> | Twitter<https://twitter.com/OnQuality> On 13 Dec 2019, at 02:53, Steve Springett <[email protected]> wrote:  The current xmi model (posted about 4 hours ago), cannot be imported into GenMyModel. When importing it, the error reads: Project cannot be created Sorry but we couldn't detect the type of this model The xmi also cannot be imported into StarUML (which also supports xmi 2.0 and 2.1). The issue with xmi, is that there are so many incompatibilities between the various tools it basically makes it unusable for sharing. Of interest, I also have the same problem with SPDX which about two weeks ago published their model in xmi format, neither GenMyModel or StarUML work. If the current model was created with GenMyModel (which I believe it was), then its export function is broken because it cannot be reimported. So we currently have an xmi specification with tool-chain incompatibilities which prevent us from working on the model. We need to solve this issue if we are to successfully collaborate on the model. Again, since xmi is such an issue, we should be developing with standards that are widely supported and interchangeable like XML Schema and JSON Schema. Developing to these specs first would allow us to rapidly prototype and then once we have something we think can be submitted, then worry about xmi. This xmi-first approach is inherently broken. I've wasted too many hours today dealing with it. Done. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#6?email_source=notifications&email_token=AFRJPERFHHJEI6T4MTYOLZLQYL2JHA5CNFSM4JTXYEU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGYXPXY#issuecomment-565278687>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFRJPERT6YGYMCBVPQPTTODQYL2JHANCNFSM4JTXYEUQ>.

[CASTResearchLabs]

I‘ll also try and share my GenMyModel project online Philippe-Emmanuel Douziech Principal Research Scientist, CAST Research Labs M: +33 6 69 95 49 59<tel:+33%206%2069%2095%2049%2059> CAST<http://www.castsoftware.com/> | Software Intelligence for Digital Leaders | Blog<http://www.castsoftware.com/blog> | LinkedIn<https://www.linkedin.com/company/162909/> | Twitter<https://twitter.com/OnQuality> On 13 Dec 2019, at 10:48, Philippe-Emmanuel Douziech <[email protected]> wrote:  I can provide (later, I’m connecting in London right now) the XMI from GenMyModel Philippe-Emmanuel Douziech Principal Research Scientist, CAST Research Labs M: +33 6 69 95 49 59<tel:+33%206%2069%2095%2049%2059> CAST<http://www.castsoftware.com/> | Software Intelligence for Digital Leaders | Blog<http://www.castsoftware.com/blog> | LinkedIn<https://www.linkedin.com/company/162909/> | Twitter<https://twitter.com/OnQuality> On 13 Dec 2019, at 02:53, Steve Springett <[email protected]> wrote:  The current xmi model (posted about 4 hours ago), cannot be imported into GenMyModel. When importing it, the error reads: Project cannot be created Sorry but we couldn't detect the type of this model The xmi also cannot be imported into StarUML (which also supports xmi 2.0 and 2.1). The issue with xmi, is that there are so many incompatibilities between the various tools it basically makes it unusable for sharing. Of interest, I also have the same problem with SPDX which about two weeks ago published their model in xmi format, neither GenMyModel or StarUML work. If the current model was created with GenMyModel (which I believe it was), then its export function is broken because it cannot be reimported. So we currently have an xmi specification with tool-chain incompatibilities which prevent us from working on the model. We need to solve this issue if we are to successfully collaborate on the model. Again, since xmi is such an issue, we should be developing with standards that are widely supported and interchangeable like XML Schema and JSON Schema. Developing to these specs first would allow us to rapidly prototype and then once we have something we think can be submitted, then worry about xmi. This xmi-first approach is inherently broken. I've wasted too many hours today dealing with it. Done. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#6?email_source=notifications&email_token=AFRJPERFHHJEI6T4MTYOLZLQYL2JHA5CNFSM4JTXYEU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGYXPXY#issuecomment-565278687>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFRJPERT6YGYMCBVPQPTTODQYL2JHANCNFSM4JTXYEUQ>.

[stevespringett]

The XMI that was shared cannot be opened in StarUML, but can be opened in GenMyModel. So it appears that in order to look at the model, we'll always need to be online, and we'll always need to use this single tool.

The exported XMI does not contain a diagram. So there's no way to visualize the relationships between the various objects without having to resort to images. This is so frustrating. Seriously, if we were modeling in XSD, anyone could use virtually any XML authoring tool and visualize the model while they author it.

These are logistics that should have been worked out back in Nashville prior to inviting myself and a host of others to join, only to find out we actually cannot contribute.

If the standards body requires essentially broken standards with tools containing broken implementations of those standards, then I don't see a path forward. I certainly don't see a way for me to contribute to this specification.

[CASTResearchLabs]

Hello @stevespringett
I appologize for this.
The way I worked with CISQ workgroups in the past was about sharing illustrations and text document explaining the model to submit to the OMG. I would then collect feedback from work group members in any form, then update the model, generate new illustrations and text document, share them, and iterate.
People were not so interested in co-developping the model, only about reviewing and commenting.
That is the process I proposed in Nashville. But I understand you would like to interact with the model itself, and that raises the issues you've faced.
Again, sorry about this.
I'll work on generating an XSD you could use, but it'll take me some time.
Meanwhile, free-form comments based on illustrations and word documents to identify improvement/correction/... areas are welcome.
Would it work for you?

[stevespringett]

So, don't go out of your way for me. Take it up on the next call and decide on a path forward. If the group is fine with yourself doing all the work, then that's fine. If the group wants to jointly collaborate on it, then consider this ticket.

Simply supplying an XSD however, doesn't provide the necessary transparency or traceability necessary for collaboration as there's no way to trace pull requests or other changes made to the XSD back to the XMI master model. This is ironic since the SBOM specification we're developing is suppose to facilitate transparency and traceability, yet, we're unable to do it ourselves.

If you look at specs like JSON Schema for example, the entire spec was designed and collaborated on GitHub, where changes, issues, and pull requests to the XML and JSON sources are fully tracked. In this way, it's possible to review every change made to find out why something is designed the way it is.

[kaywilliams]

Philippe-Emmanuel made his generation tool available. See comments below:

---

My generation tool is an R script now available in GitHub buildDocxAndXmi.R. It needs only be executed.
I run it with R version 3.6.0 from within Rstudio (either Rstudio desktop on Windows and Mac OS X, either Rstudio Server on a Centos 7 linux server).
The model JSON files are the ones I shared a while ago in GitHub https://github.com/cdfoundation/sig-security-sbom/tree/master/modeling/model_configuration and in Google drive https://drive.google.com/open?id=1lt178cCqyL9_QjmJNOWUstHWqO0IAWAE .
The tool can handle multiple locations to try multiple model files. Currently, it expects files in ./model/plb/ subdirectory.

[CASTResearchLabs]

the tool has been posted in GitHub https://github.com/cdfoundation/sig-security-sbom/blob/master/modeling/buildDocxAndXmi.R

[kaywilliams]

At our SBOM WG meeting today we discussed the following.

1. Community members can make changes to the model XMI, documentation (in Word format), and graphs (note that these graphs are not formal UML class diagrams) by modifying the JSON file in the model configuration folder.
2. They can then generate updated XMI, documentation and graphs using the R script mentioned above.

This method does not allow working with a true UML model and using the UML model to export/import an XMI. The consensus was that the JSON file / R script approach is sufficient for collaboration.

[kaywilliams]

I exchanged email with @stevespringett and believe we should continue discussing. We need to work through the scenario of using a UML modeling tool export/import xml.