Ready.
Similar to E-nets resolution-locations, but with all-the-listings shown in the figures. The result, however, is not shown.
I discuss, when discussing page 44, and on the page no abstract data types about the vagueness, of "data-types" - if any such appendage exists, at all.
Similar to resolution-procedures [and transition-procedures] of E-nets.
In all of copycat82, there is a single example where a type-name rectangle is shown, at all - but even that, is a dummy, unstudied, type of "T." Other than that, there are a few figures that associate with a subnet, "a set-of-types," next to, but separate from, "a set-of-data." Those two sets correspond to the resolution-location of an E-net transition, and to the token-attributes, respectively.
It is not an improvement that, copycat82, in its examples, explodes/dumps the names of all those individual data-items (i.e: each token-attribute) within the graph - which only introduces useless, excessive graph-clutter.
copycat82/82 does not introduce new concepts about these, in a net context. Only, the formal listings of E-nets have been drawn with a rectangle per each name, adjacent to transition. This means "data" corresponds to the in/out token-attributes, whereas a set of types associated with a node/transition (vaguely) corresponds to a res-loc, in representation, and corresponds to a resloc/resproc, behaviorally (or, to a tran-proc, when it does not select in/out paths for token-flow).
It is left vague, because copycat82 does not discuss it, itself.
There is need for a higher level of resolution, to resolve between the decisions of a resolution procedure, and the decisions of any separately-deciding ADT(s). For example, even the rather trivial examples of divide-by-zero, or an array-out-of-bounds exception, if this is managed by an ADT, that is, if there are no "if-else" structures explicitly in the resolution/transition procedure, how does the resolution/transition procedure learn about an exception/restriction? Whose decision overrides (resproc/transproc versus ADT), and when? A token may get lost in some trans-proc, and reappear somewhere else, for example, if it would be similar to exception-handling in C. That is not what Guttag does, but that is possibly what would be, if an ADT gets inserted in the middle of a program-fragment, with its own separate program flow. What would copycat82 propose? It is mute.
Now, the problem is a double-edged sword: It cuts either way. If those ADTs are confined to individual subnets/nodes, expanding them as a macro could be easier, but that would not be anything different than what we already had, as it is a trivial switch of languages, confined within the E-net procedures.
Or otherwise, if those ADTs have their separate interconnection logic, behind the scenes, as a duality, with its own intricacies, that would need a very involved macro-processor to transform/expand those macros to make such a net correctly verifiable, as a Petri net. Please, keep in mind that, no algorithm, not even any examples exist in copycat82, for such ADT-to-net transformations.
That is copycat82's text, and we, the rest of the world, may only guess, tipped with a knowledge of the prior art.
Da80, in its section "IV.E," maps E-nets to a two-level FSA. The immediate next section is the "IV.F Programming Languages." It discusses hybrid models, combining nets, with (textual) programming languages. I would interpret it as a suggestion that an E-net, in itself, is a hybrid that is sufficiently formal. But copycat82 might have misinterpreted it as a statement of a "further need," at the end of that Da80 paper.
Although copycat82 never cites Da80, at all, some very similar patterns do exist, and the plagiarism is indicated.
In other words, it might be a misinterpretation that "something yet further may need to go with E-nets." But when we look carefully, there is no further substance about it, in copycat82. That is, in fact, where, copycat82, at first appears a bit different, it all turns out to be false (unsubstantiated) advertiement, an unstudied question - even if it were a question, at all.