Need to update last paragraph on page 6 to reflect existence of version 2.2 of SACM and describe it.

Need to update copyrights and list of submitters too.

Update items in spec to reflect new version

Added sentence about the content of SACM 2.3 and revised previous SACM 2.2 content sentence to be past tense and update Figures 8.1, 9.1, 11.1 and 12.1 to reflect different modeling tool used to generate figures.

The original proposal of an informative uml profile needs to be made normative and covered by a compliance point.

Change of Annex F to Normative and add compliance point

Changing Annex F to be Normative and describe it in section 2 as part of a new compliance point.

The emof file has a missing tag and uses an old version of xmi and the uml profile is not of the correct form due to the tooling used to generate it.

Regenerated SACM machine readable files using MagicDraw

The eclipse tools we had used to generate the SACM machine readable files of the SACM model and the SACM UML profile were not producing appropriate files.

Some how Figure 8.1 was relabeled with the same label as Figure 7.2

Correct label on Figure 8.1

Somehow in the revisions to SACM the figure in Section 8.1 was changed to the label used in the previous section (7.2). This needs to be fixed.

The .xml files for emof and uml were github pages in html that had the expected emof and uml information as tables within the html. Need the content by itself.

Correct content of emof and uml profile files

Pulled intended content out of html encoded material.

mistakenly created

This issue is extraneous and should be closed

This issue was accidentally created and should be removed.

SACM provides an abstract model for information on assurance cases. However, most humans normally interact with assurance cases shown as diagrams with supporting text. SACM 2.1 finally adds a standard graphical notation, and I'm happy to see it.

However, SACM currently does not provide enough information to enable sharing diagrams in this notation. For example, there's no positioning or size information for displaying each ArgumentationElement in an ArgumentPackage. Tools do not always do a great job doing automatic layout, and in any case, humans often set up a layout to maximize human understanding. I believe this inability to exchange such information is a serious weakness in SACM.

There are many ways to include such information.

One way would be to require sharing display information in a standard form (like SVG) and provide a standard way to map between the SVG display information and the metamodel.

An alternative is to extend the metamodel to include display information. Some basic constructs from SVG could be borrowed (being maximally compatible with SVG in general is recommended). An ArgumentationElement could have a new optional "location" with contents min_x, min_y, width, and height per SVG. Each ArgumentPackage would establish a viewpoint (and essentially determine portrait, landscape, or some other display is preferred).

I'm sure there are many details to work out, but the first step is to agree that display information needs to be shared somehow.

Thank you for your time.

Graphical layout formats out of scope of SACM standard

The requested functionality is out of scope of the SACM work.

To allow for more consistent and direct use of SACM concepts in tools and other environments, a SACM UML profile is needed.

Add an annex with a UML profile of SACM

Add a SACM UML profile to allow UML-based tools to work with SACM concepts by leveraging the SACM UML profile.

Having the separate explicit UML profile of SACM that is maintained as part of the SACM specification will allow others to leverage that profile. For example, the GSN team can constrain the SACM UML profile into a GSN UML profile in a similar manner to how they leverage the SACM meta-model to define their GSN meta-model, making it cleaner for external groups leveraging GSN.

To allow for capturing terminology use as it occurs in communities there is a need to support nesting of categories in SACM’s Terminology Category class.

Allow Categories to have sub-categories

Add to SACM::Terminology::Category class a field called category of type Category, with cardinality 0..* allowing composite categories to be directly definable.

For SACM 2.3 the list of companies involved, their respective copyrights, and a sentence about the scope of SACM 2.3 is needed.

This issue is extraneous and should be closed

This issue was accidentally marked as deferred and balloted. The content of the issue was addressed by resolving SACM23-12. This issue is duplicative of that issue.

Section 6.1 is referring to the wrong version of SACM.

Referring to wrong version of SACM

Update to refer to 2.1.

Typo in 11.7 ArguementAsset (abstract) first line of section.

Typo in text of 11.7

Replace "bsse" with "base".

Typo first line of OCL, there is an extra space.

Typo in OCL

Typo first line of OCL, there is an extra space in the word AssuranceCasePackage.

In Section 3.1 Normative References, 3 of the references have been updated and the new versions should be cited.

Section 3.1 Normative References

3 of the references have been updated and the new versions should be cited.

Resolution: Shown in pdf, described below.
Replace:
ISO/IEC 15026-1:2013 Systems and software engineering - Systems and software assurance - Part 1: Concepts and vocabulary, 2013. <https://www.iso.org/iso/catalogue_detail.htm?csnumber=62526>
With:
ISO/IEC 15026-1:2019 Systems and software engineering - Systems and software assurance - Part 1: Concepts and vocabulary, 2019. <https://www.iso.org/standard/73567.html>
Replace:
OMG UML 2.5 Infrastructure Specification formal/15-03-01. <https://www.omg.org/spec/UML/>
With:
OMG UML 2.5.1 Infrastructure Specification formal/17-12-05. <https://www.omg.org/spec/UML/>
Replace:
OMG Meta-Object Facility (MOF) version 2.5 formal/2015-06-05. <https://www.omg.org/spec/MOF/>
With:
OMG Meta-Object Facility (MOF) version 2.5.1 formal/19-10-01. <https://www.omg.org/spec/MOF/>

Annex C repeatedly refers to an "ID". However, nowhere is an "ID" defined.

Section 8.1 page 17, figure 8.1, show that every SACMElement has an optional "gid", and that is subclass ModelElement has an optional "name". Either might be an ID, but I can't find any specific statement making that clear. I'm guessing that the gid is the ID, since otherwise you'd have to match all the possible language strings. However, that should be made clear.

Even more confusingly, an asCited Claim must state a package as well as the claim ID, so it appears that an ID is unique within a package but not between packages. A gid must be unique across the whole model. If IDs are unique across entire model, then in annex C it should made clear that package names are optional in an asCited Claim since they aren't needed to make it unique.

ID for graphical elements - should be name not ID

The figures mistakenly labelled with ID are revised to use name.

The "dot" in SACM 2.1's graphical notations is too small for tool implementation

Graphical Notation Dot too small to work in tools.

Increase "dot" size and update Figures.

The last sentence of the last paragraph of section 12.1 does not look right (not counting the misspelling of the second occurrence of “Artifacts”).

Typo - phrase accidentally repeated.

Remove duplicate text

Typo - phrase accidentally repeated.

Missing "or counter argument" after "counter evidence" in 11.11 Semantics, last line of page.

Missing words in 11.11

Insert missing “or counter argument" after "counter evidence" in 11.11.

Missing line break before "needsSupport" in Enumeration Litterals of 11.8.

Missing line break in 11.8

Add line break before "needsSupport" to separate terms.

In “Enumeration Litterals” of 11.8

“Litterals” mis-spelled.

Typo in text of 11.8

“Litterals” mis-spelled.

In 11.9 Semantics, misspelling – “with in” should be “within”

Typo in 11.9

Replace “with in” with “within”

Wrong package name used in second sentence of 9.3.

Wrong package name used in second sentence of 9.3.

Need to correct package name

Several terms are used in the specification without definition. Specifically: package binding, package interface, participant package, attribute and property. Defining these terms early in the specification will make it much easier for readers to understand the material.

Defining terms used in SACM

Add the following to section 4.

Attribute
A feature of a meta-element with a primitive type, such as integer, real, text, boolean, or date.

Feature
Super class of attribute and reference.

Participant Package
A Participant Package is any Package or Package Interface referenced by a Package Binding.

Package Binding
A Package that has references to at least two Participant Packages and to elements of those Participant Packages and defines the relationships among those elements.

Package Interface
A Package that is used to specify the elements of one Package that are declared “public” and available for use by other Packages.

Reference
A feature of a meta-element whose type is of another meta-element, such as +ParticipantPackage for AssuranceCasePackage

Section 3.2 Non-normative References, 1 of the references have been updated and there is one new reference to add.

Section 3.2 Non-normative References

Shown in pdf, described below.

Replace:
Goal Structuring Notation (GSN) Community Standard, Nov 2011. <http://www.goalstructuringnotation.info/documents/GSN_Standard.pdf>

With:
Assurance Case Working Group. Goal Structuring Notation Community Standard. Technical Report
SCSC‐141BA v2.0, Safety Critical Systems Club, 2018. <https://scsc.uk/SCSC-141B>.

Add to end of list of references:
Model Based System Assurance Using the Structured Assurance Case Metamodel. R. Wei, TP. Kelly*, X. Dai, S. Zhao, R. Hawkins. Elsevier Journal of Systems and Software (JSS), 154, 211-233, 2019.

The relationships discussed in 9.4 should be more flexible – any sub-packages in any AssuranceCasePackage can be used by any other AssuranceCasePackage if the appropriate interfaces and bindings are defined/available.

Flexibility in relationships

The relationships discussed in 9.4 should be more flexible – any sub-packages in any AssuranceCasePackage can be used by any other AssuranceCasePackage if the appropriate interfaces and bindings are defined/available.

The relationship and use of bindings and interfaces are not well described for packages.

Clarify bindings and interfaces

The relationship and use of bindings and interfaces are not well described for packages - propose to add clarifying text for package interface and package binding elements and add an annex with examples.

Sections 8.5 & 10.10 the Constraints sections and for 101.10 the Semantics section too, use the word “property”, which is already defined as another part of the model – need to change to another word to avoid confusion.

Confusing use of the term property

On pages 19 and 30, change the word “property” to “feature”.

Definition of 11.5 ArgumentPackageBinding is unclear. More details needed to make it understandable and the constraints need enhancement to convey model details.

Definition is unclear

Revised to expand description and fixed label in constraints as well as added constrain language.

Need to revise this section to reflect the new version.

Need to update last paragraph on page 6 to reflect existence of version 2.2 of SACM and describe it.

Added sentence about the content of SACM 2.2 and revised previous SACM 2.1 content sentence to be past tense. Proposed change in attached pdf.

SACM provides an abstract model for information on assurance cases. However, most humans normally interact with assurance cases shown as diagrams with supporting text. SACM 2.1 finally adds a standard graphical notation, and I'm happy to see it.

However, SACM currently does not provide enough information to enable sharing diagrams in this notation. For example, there's no positioning or size information for displaying each ArgumentationElement in an ArgumentPackage. Tools do not always do a great job doing automatic layout, and in any case, humans often set up a layout to maximize human understanding. I believe this inability to exchange such information is a serious weakness in SACM.

There are many ways to include such information.

One way would be to require sharing display information in a standard form (like SVG) and provide a standard way to map between the SVG display information and the metamodel.

An alternative is to extend the metamodel to include display information. Some basic constructs from SVG could be borrowed (being maximally compatible with SVG in general is recommended). An ArgumentationElement could have a new optional "location" with contents min_x, min_y, width, and height per SVG. Each ArgumentPackage would establish a viewpoint (and essentially determine portrait, landscape, or some other display is preferred).

I'm sure there are many details to work out, but the first step is to agree that display information needs to be shared somehow.

Thank you for your time.

Defer for further discussion

Exchangeable graphic notations are an interesting addition to the SACM exchange standard for assurance cases but need more discussion.

I hope that this is not an erroneously reported issue. I am still very new to reading through OMG specifications and UML diagrams. Forgive me if this is a waste of your time.

It appears that the EMOF and the description of ArgumentAsset in section 11.7 on page 38 list a content composition but that composition is not shown in Figure 11.1.

I hope that this is useful. Thank you for all the great work on standardizing SACM 2.1. It's great to see the version out of Beta!

Figure 11.1 is correct but EMOF and text in 11.7 Associations are incorrect

Updating EMOF file to reflect change and deleting the Associations section from section 11.7 of the SACM specification.

The description and semantics of AssertedContext are confusing in their discussion of interpretation and scoping.

Clarification of use of AssertedContext

The description and semantics of AssertedContext are confusing in their discussion of interpretation and scoping.

Corrections for clarity and readability.

The notation previously selected for these concepts could cause confusion when viewed by those familiar with UML notations or when viewing UML notations in proximity to these SACM concepts.

New notations for asserted context and asserted artifact context

Replace diamond line heads with squares with small line at end to distinguish them from UML notations in the 19 figures that used diamond line heads.

JS18 - http -> https throughout for omg.org (all URIs)

http -> https in MOF file

https is not supported in MOF 2.0 and we can not generate MOF 2.5.1 from the version of MagicDraw we have available.

JS19 - Why MOF 2.0, and not 2.5.1?  If no technical reason, update to 2.5.1.

Why MOF 2.0

The MagicDraw version University of York has does not support exporting to MOF any more. We are trying to find any alternatives, but in the meantime we are stuck to this version.

JS17 - The PNG images are less than optimal, and fuzzy throughout Section 11 and Annex C in both clean and changebar docs.  SVG preferred in general.  Can these be regenerated appropriately?

PNG images

new figures were generated for previous png figures - will be attached to the new report and used in the updated specification.

JS16 - Filename for SACM21-31/!!.14 - A2B.pdf  - I assume this should be 11.14… that’s going to wreak havoc with some filesystems.

JIRA file names for files included in Report

Passed on to Mariano for resolution - no change in specification or issue resolution materials.

JS15 - SACM21-1 through 13 were unnecessary to add to archive and muddied the waters.  One for Mariano?

SACM21-1 through 13 were unnecessary

When finishing the previous Report - 14 issues that were resolved in that Report were incorrectly passed to this RTF. Referred to Mariano to resolve.

JS14 - Issue 55 (ptc-19-02-33/SACM21-55/11.11-deletion.pdf) includes editorial ‘that’ to ‘whether’ that is listed in changebar as Issue 30.

showing changes from different issue

removed edit notations from a different issue from 11.11-deletion pdf

JS13 - Issue 58 (ptc-19-02-33/SACM21-58/11.13 multiplicity.pdf) does not include the graphic for Figure 7.2 on pg 12 and changes on pg 37 11.14 marked as Issue 31, 20 - should not have been in this file.

multiplicity change missing figures

included figures in pdf of changes

JS12 - Issue 20 (ptc-19-02-33/SACM21-20/Concrete Syntax.pdf) does not include the Concrete Syntax added to Section 11.10 Assertion (abstract) and includes an editorial change (‘that’ to ‘whether’) on page 38 Sec 11.13 under Attributes that is not in the changebar or clean documents for issue 20. 

Missing Concrete Syntax in 11.10

Added note of insertion in early pages of Concrete Syntax pdf for missing Concrete Syntax in 11.10. Change in word ”that” to “whether” is correctly marked as Issue 30 (not 20) in the clean and changebar pdfs. Removed from Issue 20’s Concrete Syntax pdf.

JS11 – In 12.11 Activity, under Attributes, startDate:Date[0..1] does not match naming of type in Figure 12.1, which is startDate:date[0..1] and under Attributes, endDate:Date[0..1] does not match naming of type in Figure 12.1, which is endDate:date[0..1]

Date or date in 12.11

resolve difference

JS7 – In 8.6 ModelElement (abstract), under Associations, need a newline between implementationConstraint and description.

missing newline

added newline to address comment

JS6 – In 8.2 SACMElement (abstract), under Attributes, isCitation and isAbstract do not match multiplicity in Figure 8.1

multiplicity in figure and text do not match

figure is correct - fix text

JS5 - In 6.2 Acknowledgements, there is an extra trailing bullet.

fix trailing bullet

line after bulleted list has an empty bullet - removed.

JS4 - In 3.2 Non-normative References, SPMS is at 1.2, update doc number to formal/17-11-01.

updating SPMS version reference

In 3.2 Non-normative References, SPMS reference updated.

JS3 - Typo on pdf pg 10: Issues: hhttp in URI -> https

hhttp to https

typo in url and need to move to https

JS2 - http -> https throughout for omg.org, please check other sites and changeover as possible for futureproofing ( on omg.org: pdf pgs 1, 3, 4, 9, 10, 16 and pdf pgs 16, 65, 67).

http -> https for document urls?

Reviewed pdf pgs 1, 3, 4, 9, 10, 16 and pdf pgs 16, 65, 67 and updated urls for https were applicable and resolved broken url for fda document.

RB2 – For SACM21-20 the changes are inconsistent with the changes specified in the associated PDF file. In Concrete Syntax.pdf, Figure 11.2 contains the title "Concrete Syntax for ArguementPackage" whereas "ArgumentPackage" is used in the actual text. The misspelled version is still present in the table of contents.

Arguement-Argument

Correct spelling now shown in the track changes and clean specifications - see RB2-Arguement-Argument.pdf

RB1 – Two of the issues, SACM21-14 and SACM21-16, referred to bad urls and were marked as “Closed; No Change,” but the resolution was not specified – what was done to resolve these two issues?

URL reactivated

The web site behind the urls had lost its registration on the University of York DSN system – that was fixed in a day or so.

There are several areas where the work packages for addressing issues 1, 2, 3, 5, 6, 7, 9, 11, or 12 missed changes, additions, and deletions to support internationalization and package simplification. Additionally, there are several style issues in the text that need to be made consistent.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

To support multiple stakeholder views and purposes a mechanism for associating SACMElements is needed.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

The ability to create patterns (e.g. AssuranceCase patterns, ArgumentPackage patterns, etc) that contain only abstract SACMElements is needed and the patterns should be re-usable.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

ArtifactAssetRelationship can be simplified by removing all its sub-classes. The purpose of an ArtifactAssetRelationship can then be recorded by the property +property:Property in the ArtifactAsset class.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

Citations can be simplified by removing them from Argumentataion, Artifact and Terminology classes and replacing them with +isCitation and +citedElement properties in SACMElement in the Base classes.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

If all elements in Argumentation, Terminology, Artifact and AssuranceCase can be considered as artifacts the assertion that one or more artifact provide context for another artifact; and the assertion that one or more artifact support another artifact needs to be captured.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

There are unnecessary differences between the Assurance Case, Terminology, Argument, and Artifact package definitions, interfaces, and bindings.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

Need to add internationalization of the languages used so that elements can be described using multiple languages

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

In packages (e.g. ArgumentPackage, TerminologyPackage), atomic references are too complicated.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

There is currently no direct mechanism to support internationalization in SACM content.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

In Argumentation package, AssertedRelationship should directly express if it is a counter relationship.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

In SACM, all elements in the Argumentation package, Artifact package, Terminology package, and AssuranceCase package are considered to be Artifacts.

Consequently ArtifactElement needs to be moved to the Base classes and be a direct sub-type of ModelElement. All elements in other packages then will sub-type ArtifactElement.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

Use “artifact” instead of “artefact” is needed to make incorporation of SACM into The Open Group standards more practical.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

p39:Last sentences of 11.13 and 11.14: Is A and B intentionally exchange in "the truth of" parts of the two sentences?

11.13: "An inference asserted between two claims (A � the source � and B � the target) denotes that the truth of Claim A is said to infer the truth of Claim B."

11.14: "An AssertedInference between two claims (A � the source � and B � the target) denotes that the truth of Claim B is said to infer the truth of Claim A."

I would expect that the inference of truth comes from the source and is asserted for the target so the other way than 11.14 Semantics part defines. [Remark: I am not a native English speaker so it might be strange just for me why the "said to infer" expression is used instead of "inferred from". I interpret "The truth of X is said to infer the truth of Y." as "Truth of Y can be inferred from the truth of X." or "The truth of X logically necessitates the truth of Y."- is it correct?]

A and B are mistakenly swapped in the specification text

Need to revise labels in section 11.14 to correctly describe the functionality.

p38, 11.13, Attributes: If "isCounter" seems to be set to false then stating that "a flag indicating that the AssertedRelationship counters its declared purposes" seems to be controversial, although I understand that the "false" is a default value. I think, adding "that whether the AssertedRelationship counters" is more clear. E.g. in 11.10 at a similar case, it writes "indicating the state ..." which was more clear.

Whether for that

The observation is correct - replacing "That" with "Whether" in Section 11.13

The section title "Literals" is misspelled.

Mistakenly opened issue on spelling mistake.

This is correct in specification - was looking at wrong version.

Terminology misspelled as "Termonology" in Section 2.5

Again was looking at the wrong version of the SACM file

The term is correctly spelled - no change needed.

Mistake in element name – remove “Model” from ArtifactModel::ArtifactPackage

Name of element in compliance point mistakenly has "Model" in it

Revise in specification section 2.3 - SACM 2.0 metamodel is not impacted.
ArtifactModel::ArtifactPackage should be Artifact::ArtifactPackage

Need a concrete syntax for the Argumentation metamodel that can represent the semantic definitions of the elements for semantic transparency, easing the burden of learning the elements and allowing them to be perceived directly from the notation.

Concrete Syntax and Graphical notation

As a result of the work by a graduate student at University of York - which was presented in draft at the March and September meetings we now have a proposed graphical notation for the Argumentation portions of SACM. The proposed revisions to the last part of Section 1 to add this to the history of SACM, along with a new compliance point (2.6) for those choosing to support the notation, update to section 5 on symbols, and the specific notations in many parts of section 11, as well as examples in the new Annex C are provided.

There is no discussion of the terminology model’s role in SACM.

No discussion of the role of the terminology model

In the scope of SACM we should include a discussion of vocabulary and the role of the terminology model at a high level.

The Artifact title is misleading label for this portion of the scope description, this section is actually is about Evidence.

Mistakenly opened issue on Section number name.

Thought section was named "Artifact" and wanted to change it to "Evidence" but in fact it was already named that way. Had looked at earlier version of specification.

The constraint section of the class Claims revers to two attributes ("assumed" and "toBeSupported") that are not part of the SACM 2.0 metamodel (they are replaced by the attribute "assertionDeclaration" of type "AssertionDeclaration).

Proposed fix:

Remove the constraint section. It is no longer required, as the "exclusive or"-constraint is already enforced by AssertionDeclaration being an enumeration.

Duplicative request for removal of constraint from 11.11

Addressed in ballot 3.

The multiplicity of +target should be 1 (target:ArgumentAsset[1]).