1. Language = Syntax + Semantics + Vocabulary
Concrete: What you see (rectangles, lines, text).
Abstract: What you say (“block”, “item flow”)
Interchange/API: What computers read/write.
Semantics
What’s possible to conclude about the things being modeled when using the syntax.
Vocabulary (libraries)
Predefined syntactic (modeling) elements.

2. Language Specifications
Syntax
Semantics
Vocabulary / Libraries
Concrete
Abstract
Operational
Application Independent
Interchange/ API
Declarative
Application
Dependent
Graphical
Textual
Model Theoretic / Denotational

3. Interoperability Requirements
Uniform syntactic interpretation
Everyone looking at SysML diagrams should
Describe them the same way (using SysML terminology).
Agree on whether they are“legal” SysML (well-formedness).
Uniform semantic interpretation
Reach the same conclusions about the things being modeled.
Including whether it is possible to draw any conclusions at all (consistency).

4. Who’s “Everyone”? Modelers, teachers, consultants, spec writers.
They understand each others models the way the authors intended.
Modeling tool builders
Their tools instantiate abstract syntax the same way (MIWG) for all diagrams.
Analysis tool builders
Their tools produce same results for all instances of abstract syntax.

5. Syntactic Requirements (Specific)
Concrete syntax specification
Shall include syntax for diagram/text information that is not included in abstract syntax, linked to abstract syntax (eg, DD’s DI/DG).
All examples shall be accompanied by a model for them, as above.
Abstract syntax specification
Shall be notation-independent.
See semantic requirements.

6. Semantic Requirements (Specific)
Specification shall give unambiguous relationship between models and the things being modeled
Model libraries shall be included for all semantics.
Abstract syntax shall specify patterns of (automatically) using library elements with instances of abstract syntax.

7. Formalism Driving Requirements:
The next-generation modeling language must include precise semantics that avoid ambiguity and enable a concise representation of the concepts.
The language must derive from a well-specified logical formalism that can leverage the model for a broad range of analysis and model checking.
This includes the ability to validate that the model is logically consistent, and the ability to answer questions such as the impact of a requirement or design change, or assess how a failure could propagate through a system.
The language and tools must also integrate with a diverse range of equation solvers and execution environments that enable the capture of quantitative data.

8. Formalism Requirements (updated 9/10/2016):
Semantics:
The declarative semantics of SysML v2 shall be expressed in the form of mathematical logic or have a translation to an expression in mathematical logic. (Definition: Classically, mathematical logic is considered to be made up of set theory, model theory, recursion theory, proof theory, and construction mathematics (constructivism). In addition, we are also considering category theory and type theory.)
Model libraries shall be included for all semantics.
Abstract Syntax:
The SysML v2 abstract syntax shall be independent of notation.
Where the SysML v2 metamodel is extensible, the abstract syntax and semantics shall both be extensible.
Concrete Syntax:
SysML v2 shall include concrete syntax for diagram/text information that is not included in the abstract syntax, but is linked to the abstract syntax (e.g., DD’s DI/DG).
Abstract syntax shall specify patterns of (automatically) using concrete syntax elements with instances of abstract syntax, and all examples shall be accompanied by a model for them.
Formalism Feature:
SysML v2 shall enable model users to define derived properties and relationships in their models without necessarily using a constraint language.

9. From the SME Concept:
Language formalism. The language formalism defines the semantic foundation (e.g., predicate logic) and syntactic foundation (e.g. MOF abstract syntax) to ensure unambiguous expression of the key concepts (refer to Formalism WG Wiki).
Ontological and semantic/ foundation which is precise and expressive enough (i.e. computer interpretable) to support transformation (to model, to text), model query, logical inferences, and model checking
How well does the requirement for mathematical semantics satisfy this? Above mixes syntax (including graphical and textual concrete syntax) and semantics (some apply to both). Clarify “mathematical”: Operational, declarative, precise relation between model and thing being modeled.
Representation of time related properties
What requirements would we make for this? I would think that the choice of temporal logic (LTL, ITL, CTL*, etc.) would be dependent on the situation, and would not be a language wide decision. Could require particular temporal relations without specifying logic. Cover structures over time as well as behaviors. Other considerations would be a part of M2.
Support for variable formalization and enforcement levels (e.g., warnings, errors)
Part (all?) of this is on the tool vendors. But what about requirements? Should we focus on requirements for this, or instead should we use evaluation points? (“A submission that allows leniency with its formalism will be preferred.”) Layers of increasing syntactic constraint? Spec is simpler if this is left to vendors.
Supports interoperability with other modeling languages
Obviously, the UML profile implementation will have interoperability with UML. Do we intend to force the non-UML vendor implementations to have interoperability with UML/BPMN? How does UPDM do it? Does interoperability lead to any formalism requirements we don’t already have for precision? See interchange / APIs.
Interchange / APIs in SME Concept? Related to precise syntax, above.
Includes a standard extension mechanism
What will the extension mechanism for the UML profile implemention be? (Profiles) What would the extension mechanism for say, Core or Genesys be? (editing the Vitech schema(s)) Need semantic as well as syntactic extensions (syntactic/semantic formalism supports extension). Formalism itself extensible?

10. Approaches that Maintain Connection to UML:
Consider these potential approaches to the SysML v2 metamodel foundations:
Approaches that Maintain Connection to UML:
Use UML without replacing anything -> Profile + equivalent MOF model (extension->generalization &
stereotypes->metaclasses). Potentially replace XMI with OWL or RDF (potentially via MOF2RDF).
Use UML without changing the metamodel -> Add additional representation of UML/SysML semantics as a mathematical representation (model theory/type theory/category theory/etc.) Otherwise, same as above.
Use UML without changing the concrete classes -> specialize UML metamodel from formal language (e.g., OWL, IDEAS Foundations).
Treat SysML v2 as a branch of UML -> Similar foundations, but SysML v2 metaclasses replace some UML metaclasses/SysML v1.x stereotypes and open the potential to make changes to the foundations of the UML metamodel.

11. Consider these potential approaches to the SysML v2 metamodel foundations (cont):
Approaches that completely break from UML:
Brand new everything->Go back to 1989 (‘87 if we reinvent state machine diagrams). Develop a language from the ground up that has concrete syntax that will have mappings to implementations (SysML v2 Language->UML profile, SysML v2 Language->Vitech schema, etc.)
Mostly brand new everything -> Derive SysML v2 metamodel from pre-existing non-UML foundations (e.g., OWL 2, IDEAS Foundations, etc.)
Focus on abstract syntax/semantics->Leave implementation (concrete syntax) up to vendors, e.g., UML profile, Vitech schema(s), whatever tools that don’t focus on diagrams do, etc.
And…????

12. Relationship to DD Submissions shall use DD to define
Diagram interchange, using DD’s Diagram Interchange (DI) for metamodels, and profiles of UML DI for UML profiles.
Diagram graphics, using an executable mapping language from submissions’ diagram interchange to DD’s Diagram Graphics (DG).