There are 94 uses of the word 'however' in the specification, usually starting a sentence. In many cases, the word injects unnecessary text that further confuses and obfuscates the intent. In most cases, what follows is not an exception, rather just another option of the language. In many cases the word can be replaced with ‘if’ or ‘when’ but I also found many cases where a rewrite is necessary.
Here are the first 45ish specific examples and rewrites. I stopped at page 119 as there is enough evidence to show simple rewriting of the offending test can greatly improved the text. I have also added comments to point to the issue and any further wordsmithing that seems to be required.
This seems like a minor or even a style issue, ‘however’ the point of this issue is that the use of the word muddles the descriptive intent of the text when it should be precise as possible.
2. conformance:
Original:
However, a tool demonstrating Concrete Syntax Conformance need not represent a model internally in exactly the form modeled for the abstract syntax in this specification.
Replacement:
A tool demonstrating Concrete Syntax Conformance need not represent a model internally in exactly the form modeled for the abstract syntax in this specification.
6.2 Document Organization
Original:
However, this clause does not cover details of the Kernel metamodel, which are included by normative reference to the KerML specification [KerML].
Replacement:
This clause does not cover details of the Kernel metamodel, which are included by normative reference to the KerML specification [KerML].
Comment:
Optionally delete the sentence as it is already assumed that KerML is where the reader finds the details of the details.
6.3 Acknowlegements
Original:
However, work on the specification was also supported by over 200 people in over 80 organizations that participated in the SysML v2 Submission Team (SST), by contributing use cases, providing critical review and comment, and validating the language design.
Replacement:
Over 200 people from over 80 organizations participated in the SysML v2 Submission Team (SST), contributing to the specifics and providing reviews and comments.
7.2.1 Elements and Relationships Overview
Original:
However, in some cases, additional shapes may be attached to relationship lines in order to present additional information.
Replacement:
Additional shapes may be attached to relationship lines in order to present additional information.
7.2.2 Elements
Original:
Various specific kinds of model elements in SysML are described in subsequent subclauses. However, there are certain concepts that apply to all model elements.
eplacement:
Key model elements in SysML are described in subsequent subclauses. Some of the concepts apply to all model elements.
comments: The opening statement like this are without value to the spec.
Original:
The SysML notation does not have any provision for specifying element or alias IDs, since these are expected to be managed by the underlying modeling tooling. Instead, an element can be given a name and/or a short name, and it can also have any number of alias names relative to one or more namespaces (see 7.5).
Replacement:
The SysML notation does not have any provision for specifying element or alias IDs because these are expected to be managed by the underlying modeling tooling. Instead of using an ID, an element has a given name and/or a short name that can also have any number of alias names relative to one or more namespaces (see 7.5).
Original:
However, unless at least one of these is given, it is not possible to reference the element using the textual notation (though it is still possible to show it in relationships on graphical diagrams).
Replacement:
It is not possible to reference the element using the textual notation unless a name or short name is given, though it is still possible to show it in relationships on graphical diagrams.
Original:
However, a reserved word may not be used as a name, even though it has the form of a basic name (see 8.2.2.1.2 for the list of the reserved words in SysML).
Replacement:
A reserved word may not be used as a name (see 8.2.2.1.2 for the list of the reserved words in SysML).
Original:
However, these characters may be included as part of the name itself through use of an escape sequence.
Replacement:
Non-printable characters may be included as part of the name itself through use of an escape sequence.
7.4.2 Comments and Documentation
Original:
However, marked up "rich text" for a comment is stored in the comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules referenced above.
Replacement:
Marked up "rich text" for a comment is stored in the comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules referenced above.
Original:
However, for any other language than "sysml", the SysML specification does not define how the body text is to be semantically interpreted as part of the model being represented
Replacement:
For any other language than "sysml", the SysML specification does not define how the body text is to be semantically interpreted as part of the model being represented
7.5.4 Import Filtering
Original:
comments. Namespaces other than packages cannot have filter conditions (except for their special use in view definitions and usages – see 7.25). However, any kind of namespaces may have filtered imports.
Replacement:
Namespaces other than packages cannot have filter conditions, except for their special use in view definitions and usages – see 7.25. All kinds of namespaces may have filtered imports.
comments: It is strange that this is a note as these are very specific semantics rather than an aside as would be described in a note.
7.6.1 Definition and Usage Overview
Original:
However, truck can instead redefine fuel to restrict its definition to DieselFuel, a subclassification of Fuel.
Replacement:
Alternatively the Truck could redefine fuel to restrict its definition to DieselFuel, a subclassification of Fuel.
comments: The paragraphs are rather confusing without a textual language or graphical examples. At least you could refer to an example in the annex. It is also odd to get into alternatives without an example of the alternative.
Original:
However, it is expected that if Vehicle is baselined in a configuration management tool, then a change to Vehicle is a new revision, and it is up to the modelers to determine whether to retain the previous version of Vehicle or move to the next revision.
Replacement:
If Vehicle is baselined in a configuration management tool, then a change to Vehicle is a new revision, and it is up to the modelers to determine whether to retain the previous version of Vehicle or move to the next revision.
7.6.3 Usages
Original:
However, a tighter default of [1..1] is implicitly declared for the usage if all of the following conditions hold
Replacement:
A tighter default of [1..1] is implicitly declared for the usage if all of the following conditions are true:
Comment: Is there a reference to where this is described in the standard?
7.6.4 Reference Usages
Original:
However, a reference usage is always, by definition, referential. A reference usage is otherwise declared like any other usage, as given above.
Replacement:
Reference usages are always referential. A reference usage is declared like any other usage, as given above.
Comment:
Once the ‘however’ was removed, the changes to the following sentence is also required to improve the explanation of the concept.
7.6.5 Effective Names
Original:
However, if neither a name or a short name are given in the declaration of a usage with an owned redefinition, then its effective name and short name are implicitly determined by the name and short name of the redefining usage of its first owned redefinition (which may itself be an implicit name, if the redefined usage is itself a redefining usage).
Replacement:
When neither a name or a short name are given in the declaration of a usage with an owned redefinition, then its effective name and short name are implicitly determined by the name and short name of the redefining usage of its first owned redefinition (which may itself be an implicit name, if the redefined usage is itself a redefining usage).
Comment:
The use of ‘however’ muddled the original explanation. Imagine Java or some other computer language with ‘however’ as a key word.
7.6.6 Feature Chains
Original:
However, their use is particularly important when specifying the related features of a connection usage that are more deeply nested than the connection usage itself (see 7.13). (See also [KerML, 7.3.4.6].)
Replacement:
Feature chains are particularly important when specifying the related features of a connection usage that are more deeply nested than the connection usage itself (see 7.13). (See also [KerML, 7.3.4.6].)
7.6.8 Implicit Specialization
Comment:
This may be a good use of however, but look at it anyway and see if it can be avoided,
7.7.1 Attributes Overview
Original:
However, the owner of an attribute usage may be an occurrence definition or usage (or a specialized kind of occurrence, such as an item, part or action). In this case, the value of the attribute usage may vary over the lifetime of its owning occurrence, in the sense that it can have different values at different points in time, reflecting the changing condition of the occurrence over time.
Replacement:
The owner of an attribute usage may be an occurrence definition or usage (or a specialized kind of occurrence, such as an item, part or action). When the attribute owner is a usage is an occurrence definition or usage, the value of the attribute usage may vary over the lifetime of its owning occurrence, in the sense that it can have different values at different points in time, reflecting the changing condition of the occurrence over time.
Comment:
This is still confusing. It again screams out for a textual/graphical language example.
7.8.1 Enumerations Overview
Original:
However, if the enumeration definition specializes an attribute definition with nested usages, then those nested usages will be inherited by the enumeration definition, and they may be bound to specific values within each enumerated value of the enumeration definition.
Replacement:
If the enumeration definition specializes an attribute definition with nested usages, then those nested usages will be inherited by the enumeration definition, and they may be bound to specific values within each enumerated value of the enumeration definition.
Original:
The enumerated values defined in an enumeration definition, however, would add to the set of enumerated values allowed by any enumeration definition it specialized, which is inconsistent with the semantics of specialization.
Replacement:
The reason for this constraint is that enumerated values defined in an enumeration definition would add to the set of enumerated values, which is inconsistent with the semantics of specialization.
Comment:
This is a definite improvement over the original text, which is very confusing. It is very strange that given you are creating a new language to get around issues with UML you have not fixed this glaring issue of the inability to specialize enumerations.
7.8.2 Enumeration Definitions and Usages
Original:
However, an enumeration definition must not subclassify another enumeration definition. An enumeration usage is declared as described in 7.6.3, using the kind keyword enum.
Replacement:
An enumeration definition must not subclassify another enumeration definition. An enumeration usage is declared as described in 7.6.3, using the kind keyword enum.
Comment:
This paragraph seems like a repeat of the previous change request. Suggest choosing one and deleting the other to reduce confusion and need to maintain both statements.
7.9.1 Occurrences Overview
Original:
However, if a composite suboccurrence is removed from its containing occurrence before the end of the lifetime of the containing occurrence, then the former suboccurrence can continue to exist.
Replacement:
If a composite suboccurrence is removed from its containing occurrence before the end of the lifetime of the containing occurrence, then the former suboccurrence can continue to exist.
Original:
However, if the wheel is removed before the car is destroyed, then the wheel can continue to exist even after the car is destroyed. (See also 7.6 on referential and composite usages.)
Replacement:
If the wheel is removed before the car is destroyed, then the wheel can continue to exist even after the car is destroyed. (See also 7.6 on referential and composite usages.)
Original:
However, it could also be realized as the start and end of an explicitly modeled flow connection (see 7.13 on flow connections and messages).
Replacement:
These events can also be realized as a modeled flow connection (see 7.13 on flow connections and messages).
Comment:
This is another statement that becomes more muddled when treating it as an exception when in fact this is not an exeption, but just realkized by another possible construct.
7.9.3 Time Slices and Snapshots
Original:
However, if such an occurrence usage has no explicitly declared definition, but is declared in the body of an occurrence definition, then it is considered to implicitly represent a portion of instances of the containing occurrence definition.
Replacement:
If an occurrence usage has no explicitly declared definition, but is declared in the body of an occurrence definition, then it is considered to implicitly represent a portion of instances of the containing occurrence definition.
7.10.1 Items Overview
Original:
However, once the engine assembly is completed, the engine can be considered to be a part that may be installed into a car, where it is expected to perform the action providing power to propel the car. But later it may be removed from the car and again be considered only an inactive item in a junkyard.
Replacement:
Once the engine assembly is completed (e.g. the engine has completed manufacturing and exists as a whole), the engine can be considered to be a part that may be installed into a car, where it is expected to perform the action providing power to propel the car. Later in time, the engine may be removed from the car and again be considered only an inactive item in a junkyard.
Comment:
This is a weird example. There are many parts to an engine that are added and removed. For example, spark plugs. A spark plug could be a better example as these are assembled of pieces that are not individually replaceable and junked as a whole.
7.13.1 Connections Overview
Original:
However, the values of connection ends (i.e., the things that are actually connected) do not change over time (though they can potentially be occurrences that themselves have features whose values change over time).
Replacement:
The values of connection ends (i.e., the things that are actually connected) do not change over time (though they can potentially be occurrences that themselves have features whose values change over time).
Original:
However, a message does not specify how the payload is to be obtained from the source or delivered to the target.
Replacement:
A message does not specify how the payload is to be obtained from the source or delivered to the target.
Comment:
So how do we specify how it obtained? This needs further clarification.
7.13.2 Connection Definitions and Usages
Original:
However, if it declares any owned end features, then each of these must redefine an end feature of the general connection definition, in order, up to the number of end features of the general connection definition.
Replacement:
If a connection definition declares any owned end features, then each of these must redefine an end feature of the general connection definition, in order, up to the number of end features of the general connection definition.
7.13.4 Feature Values
Original:
However, for a default, bound feature value, the symbol = may be elided.
Replacement:
Optionally. a default, bound feature value, the symbol = may be elided (as shown in the default ‘mass’ in the following example).
Comment:
This a capricious and confusing option. Please choose one and delete the other. This adds a complication to the reading of the language that is unnecessary.
7.13.6 Flow Connection Usages and Messages
Original:
A streaming flow is declared similarly to a message, but with the kind keyword flow. However, instead of identifying the source and target features of the flow, such a flow declaration must identify (after the keyword from) the output feature of the source from which the flow receives its payload and (after the keyword to) the input feature of the target to which the flow delivers the payload.
Replacement:
A streaming flow has the kind keyword flow and must identify, after the keyword from, the output feature of the source from which the flow receives its payload and, after the keyword to, the input feature of the target to which the flow delivers the payload.
Comment:
The use of ‘however’ has created language of no value. The streaming flow is totally different than a message in its form. The rewrite hopefully fixes the first mistake, however the sentence is still rather obtuse and still needs some wordsmithing.
7.14.2 Interface Definitions and Usages
Original:
However, if the declaration part of an interface usage is empty, then the interface keyword is still included, but the connect keyword may be omitted.
Replacement:
If the declaration part of an interface usage is empty, then the connect keyword may be omitted.
7.16.1 Actions Overview
Original:
However, if the owner of the perform action usage is an occurrence, then the referenced action performance must be carried out entirely within the lifetime of the performing occurrence.
Replacement:
If the owner of the perform action usage is an occurrence, then the referenced action performance must be carried out entirely within the lifetime of the performing occurrence.
Original:
However, a succession between action usages may, additionally, have a guard condition, represented as a Boolean expression (see 7.18).
Replacement:
A succession between action usages may have an additional guard condition, represented as a Boolean expression (see 7.18).
7.16.5 Conditional Successions
Original:
However, the target of a conditional succession must be specified as a qualified name or feature chain and cannot be a full action usage declaration, even when the shorthand notation is used.
Replacement:
The target of a conditional succession must be specified as a qualified name or feature chain and cannot be a full action usage declaration, even when the shorthand notation is used.
7.17.1 States Overview
Original:
However, if the owner of the exhibit state usage is an occurrence, then the referenced state performance must be carried out entirely within the lifetime of the performing occurrence.
Replacement:
If the owner of the exhibit state usage is an occurrence, then the referenced state performance must be carried out entirely within the lifetime of the performing occurrence.
7.17.2 State Definitions and Usages
Original:
However, if the keyword parallel is added to a state definition or usage, just before the body part, then the containing state definition or usage becomes a parallel state, and its contained state usages can be performed in parallel. (However, no transitions are allowed between concurrent states; see 7.17.3.)
Replacement:
If the keyword parallel is added to a state definition or usage, just before the body part, then the containing state definition or usage becomes a parallel state, and its contained state usages can be performed in parallel. In this case, no transitions are allowed between concurrent states; see 7.17.3.
Original:
(However, no transitions are allowed between concurrent states; see 7.17.3.)
Replacement:
No transitions are allowed between concurrent states; see 7.17.3.
7.19.1 Constraints Overview
Original:
In general, a constraint may be satisfied sometimes and violated other times. However, an assert constraint usage asserts that the result of a given constraint must be always true at all times.
Replacement:
When an assert constraint usage asserts exists, the result of that constraint must be always true at all times. This is compared to a simple constraint may be satisfied sometimes and violated other times.
Comment:
This another example of the ‘however’ causing a confusion in the semantics. The spec should say what is true before saying what is true is an exception. In this case, there is no exception, just a differing kind of constraint than one already discussed.
