Open danielwilms opened 4 years ago
The idea so far was to draw the line between VSSo and extensions:
I would go with the second option, but keep version aligned with future VSS and VSS tool releases.
I would go with the second option, but keep version aligned with future VSS and VSS tool releases.
That sounds like a lot of work to keep the two in line thinking just from version to version, as there's a lot happening right now. The instances for example would make your tooling quite a lot easier. Maybe it would make sense to put it under the maintenance of the tools themselves, as they are then considered as well with every change, which is happening.
I would indeed investigate how to implement the first approach and think in putting the ttl generator as part of the vss-tools. I may have good developer resources to assign to this in December to experiment with.
Tools now available in vss-tools.
Open issue: Align to core ontology
We have a proposal for the alignment of vss-tools (vspec2ttl) that we can contribute but I think we should wait until we have agreed on the vss-core ontology.
I think we can adapt the tooling, with the discussions we have.
Otherwise I'd add now the changes to the current tooling, so that we can move forward with the docs generation for vsso which might result into double work.
would be great, if you could create a PR to the vss-tools repo. otherwise I'll patch it now and you guys have to merge in your features later.
I will create a PR as soon as possible.
The tools are now a fork from the Vehicle Signal Specification (VSS), the VSS Tools respectively. We should align it ASAP.
The question is, how we want to continue VSS and VSSo. Two suggestions:
I'd prefer the first option. Any opinion @rtroncy, @klotzbenjamin, @tguild?