Ready.
An E-net token, at a specific location, is either a simple-token, or with (a fixed
amount of) token-attributes. A set of token-attributes is a vector (a
record), with its attributes (fields), and it is interpreted/modified by the associated
(resolution and/or transition) procedures. The environment variables, xi, is
a similar vector, but global. It is modifiable from anywhere.
In copycat82, the section "3.2.2. Data Types and Data Objects" claims to represent data, with types. The "set-of-locally-shared-data (LD)" corresponds to the token-attribute(s), associated with a token between two E-net transitions. The global-data correspond to the environment-variables.
note 1: When it is time to verify those nets, in copycat82, the data gets ignored - similar to the first-level of analysis in VD78. Therefore, if a data-sharing relationship is not shown as a circuit in the net (with places/locations and transitions), then the logic is lost, and the verifier is not verifying the equivalent system. In fact, copycat82, in its end-of-the-dissertation "example application," does this even with a semaphore variable. That loses all sense.
Therefore, I assume that when there is an important sharedness, prone to race-conditions, the net MUST reflect that data-sharedness as net-elements, too. Otherwise, if the "locally-shared" is a laxative term which means, that subnets may write into each other's data, without any token management to regulate their access, then the environment variables, with their uncoordinated access, fits "LD," too.
note 2: The local-sharedness corresponds to the passed-message, especially with a message-based distributed system, which copycat83 (the paper) claims to be at its introduction. i.e: With no shared memory, the local-sharedness, means the data sent from source to destination.
The clutter in the combined "single graph" that contains both the Petri net elements, and data-item-name rectangles, is trivially, same as drawing a rectangle per each attribute, associated with a token, as parallel paths to that token. For example, if there are twelve variables in that set, draw each of them as a "data-item-name" rectangle, with arcs from source subnet, to the target subnet. This is trivial. Alternatively, but equally trivially, merge the control- and data-graphs of VD78 (or, LOGOS), where a (control-)subnet (transition), and a data-operator, correspond to each other
Notice here, though, if such a correspondence is not one-to-one, the merged graph would even further explode in size. In fact, many other problems exist. The alarming point, about data, and types, is , the immense-amount-and-variety of faults, and the vagueness of copycat82, about these. That is a sign of total lack of achievement in computer science, if not a total carelessness with the dissertation work. We discuss those cases about data and types, at this site, too.
The token-attributes of an E-net token, is an array, or a record, of variables/attributes. It acquires its meaning mainly with the procedures, and macro designs. In NN73, there are examples. e.g: an RH-macro (resource-handler) interprets the inbound token-attributes in a specific way.
With macros and procedures, new abstractions are built in NN73. A Q-macro-location, is a queue/stack, and may reorder inbound tokens. There are extended versions of the E-net primitive transitions, built with macros, e.g: the Fn macro-transition is similar to F-transition, but it is not limited to two output locations. For example, this way, a fork of four processes reflects its coherence-set, more directly - instead of a net-circuit that exists in the design, as a two-level of forks. Similarly, extended versions of other E-net transitions are built.
copycat82 is not there. Although it claims even to import a full-fledged abstract-data-types system, from elsewhere, that turns out to be only an attention-diverting false-claim. The referred system, is a tutorial-paper (Guttag, 1980) on abstract-data-types, and copycat82 only publishes a page, or two, of summary about it, to mention its terms. No introduction to a net context. e.g: That tutorial paper contains examples with stacks, but it is the NN73 that presents the real thing, in the net-formalisms context, with the Q-macro example. Therefore, NN73 is the more advanced, if not the only relevant paper.
copycat82 is the typical plagiarizer: Translating work, between different computer-languages, and/or changing a few names. Trivially suggesting a switch of the computer-language used in the procedures, without doing anything new with them, is not any improvement, when such prior art, as (Macro) E-nets, SARA, etc. already existed.
In all of copycat82, there are only two example figures, both of them problematic, about any relevance to some data-type, at all. The example on page 68 includes a type-name rectangle, but it is not a studied-type. It is named "T" and it is not even inferrable whether it is associated with the input data-item, or the output-data item. The other example, on on page144 does not use any data-type-rectangles, as is the case also with the rest of the examples, but it is noticeable, as a possible-attempt to employ a non-primitive type. It is supposed to be a buffer, as with E-nets Q-macro location. But copycat82 is vague about it.
In all of copycat82, there is not even an attempt to represent any example type that E-nets had not already studied thoroughly. Except these two non-examples, in other figures, the types are mentioned as only "a set-of-types associated with a subnet," without any specific type names, let alone type studies. Therefore, three points are relevant:
That type-set corresponds to the E-nets resolution-location - when it is needed. Useless, otherwise. An E-nets resolution-location specifies a single path, when two/multiple alternatives are available. As a result, it maps a set at the input, to another set at the output.
An E-net resolution-location shows the selected-path, too, as an index. This is what copycat82 lacks. That omission, obviously, is not an improvement in abstraction. In fact, it is the vice versa. (These are further discussed, on the page about resolution locations, and copycat82 plagiarism, the page about the Myth: copycat82 data-items, and Myth: copycat82 data-types.)
copycat82, exactly claims that, when as "design" it only equates a type-set at the combined subnet as a sum of the type-sets in the splitted subnets. Nothing is discussed about it. e.g: It does not discuss anything about identifying, neither algorithmically, nor with any rules-of-thumbs, about the possible interrelatedness of the type-sets in the sliced subnets, and/or about the shared-types that relate to both subnets. If such an "as-if-sausage-slicing" was all that copycat82 would publish to "design/manipulate/manage" with ADTs, then, why bother mention it, at all? It is only false advertisement.
Those data-type-name rectangles are not discussed, for any need, at all, either. i.e: It is neither managed, nor needed. This, then, would explain why the examples also do not show them. It is only false advertisement. Period. That may only help distract your attention, when you ask "what exists in copycat82, other than what E-nets already referred to, and E-nets had thoroughly studied?" The false answer would be "abstract data types." But no such extra exists, as we notice, upon closer scrutiny.
For more about these, please read the pages: