Summary and Disposition of Comments for FCD15909

Date: 17 May 2001 

From: Editor of Project 7.19.3

Subject: Disposition Report for FCD15909

Work Item: 7.19.3 Petri net techniques  

Document: KMJ-013R4

Input Documents: 

1. SC7/N1947, FCD15909 Ballot, 26/6/1998
2. SC7/N2003 Letter Ballot Summary of FCD15909 Software Engineering - High Level Petri Net Standard, 29/10/1998 (Note: Incorrect UK comments included in this document)
3. KMJ-100 Hugh Davis Email, with Prof Dan Simpson's (UK) comments.
4. KMJ-101 Email from Prof Tad Murata (USA)
5. KMJ-013R1 Draft Summary and Disposition of Comments for FCD15909, 3 November 1998 (Editor)
6. KMJ103 Email from Dan Simpson (UK), 4/11/98.
7. KMJ104 Email from Kurt Jensen (Denmark), 5/11/98.
8. KMJ105 Re: Draft Disposition Report, FCD15909, 18/11/98 (Ekkart Kindler)
9. KMJ106 Re: Draft Disposition Report, FCD15909, 25/4/99 (Editor)
10. KMJ107 Re: Draft Disposition Report, FCD15909, 10 May 1999 (Ekkart Kindler)
11. Karsten Schmidt, 'Parameterized Reachability Trees for Algebraic Reachability Trees', LNCS Vol 935, 1995, Springer, pp 392-411.

General

In N2003, of the 21 P-members who voted, 17 approved (4 with comments), one disapproved (Germany) with comments, and three abstained (without comments). Thus the FCD has been approved. This means that the final text from the editing meeting will be the text of the standard, so long as it passes the FDIS Yes/No ballot.

There were a total of 84 comments received by the editor. The editor has processed comments that were meant to be input by National Bodies, even if they have not been included in N2003 (ie documents 3 and 4 above) as agreed at the Curitiba meeting of SC7/WG11 i May 1999.

The editing meeting was officially commenced after all the ballot responses had been received. Some preliminary discussions occurred during the WG11 meeting in Kumomoto, Japan, October 1998 via email, as the editor and several other NBs could not be present. A draft disposition of comments document was circulated by email to all representatives of NBs and WG11 experts on 3 November 1998. The editing meeting was left open till the Curitiba meeting of WG11 as part of the SC7 Plenary in Brazil, in order to finalise the disposition of comments. The UK and Denmark responded positively to the draft disposition accepting all recommendations (see inputs 8 and 9 above). The USA noted that all its comments had been accepted (see WG11 minutes - SC7 N2036). Australia confirmed it agreed with the disposition. A detailed response from Germany was received on 18 November 1998, and responded to by the editor on 25 April 1999. Comments were resolved (except for the implementation of including symbolic markings) in Germany's response of 10 May 1999. No other responses by NBs were received during this period. The disposition of Japanese comments was agreed to at the Curitiba meeting. Because no representative from the German NB was present at the meeting, the editing meeting was kept open, to allow further discussion on symbolic markings. After several rounds of discussions a final circulation of the revised FCD occurred in October 2000. Comments from that circulation have now been incorporated. The disposition is therefore final.

Taking each country in turn from N2003, the disposition of comments is as follows:

AUSTRALIA (Approve with comments)

AUS01 G

Australia considers the FCD to be at a mature stage, and ready for progression to FDIS, with a few minor changes (see below).

Noted

AUS02 E

The full title of the FCD should be:

FCD15909 Software Engineering - High-level Petri Nets - Concepts, Definitions and Graphical Notation

(The secretariat is still using an old title for the cover pages, but the new title is given on page 1)

Accept

Note: The editor advised the secretariat of this problem on 30 October 1998.

AUS03: E   Clause 0 Introduction: assemly  -->  assembly
accept

AUS04: E  Clause 3, 3.1.8 instatiated ---> instantiated
accept

AUS05: E check all clauses for consistent use of bolding for ÔnoteÕ.
accept Need to comply with directives (see JPN006E)

AUS06: TL Clause 5, 5.1 Definition, third fly dot replace

ÔD is a non-empty finite set of domains where ...Õ with

ÔD is a finite set of non-empty domains, where ...Õ

Partially Accept (see DAN1TH) if modified to retain that D is non-empty. 
Ed. This is because function Type is not defined if D is empty, except in the special case of both T and P being empty, where we would have the empty function for Type. Hence for all interesting cases where there is at least a transition or a place, D must not be empty. 

AUS07: E Clause 5, 5.1 Definition

At the end of this clause add the following explanatory note:

ÔNote: \mu PLACE is the set of multisets over the set, PLACE (see Annex A, section A.2).Õ

Accept

AUS08: E Clause 5, 5.4 Transition rule

Remove the full stop at the end of the equation.

Accept

DENMARK (Approve with Comments)

DAN1 (TH)
In section 5.1, the definition of D should be changed from
 D is a non-empty finite set of domains,.....
to
 D is a finite set of non-empty domains,......
Motivation: This is consistent with the usual definitions of Coloured Petri
Nets and Predicate/Transition Nets. It is also consistent with the
description of Place Types in the beginning of section 6.2.

Partially Accept.
See AUS06. So long as P union T is not empty, D must not be empty for Type to be defined.

DAN2 (TH)
In  section 6.4 the notation used for multi-sets should be
modified. As an example the marking of place A in Figure 1 should be
changed from
 1 + 2(3)
to
 1'1 + 2'3
Motivation: The use of an infixed operator ' (or *) in multi-sets are more
common than the use of parenthesis. Omission of 1-coefficients introduces
problems for languages that are strongly typed, since these distinguishes
between a token value (such as 34) and a multi-set with one token (such as
1'34).

Accept
Ed: See discussion on DIN23.

DAN3 (TH)
Similar changes should of course be made in all those parts of the document  where the notation is used (e.g., A.2.1 and Annex C)

Accept

GERMANY (Disapprove with Comments)

DIN ballot vote on FCD 15909, V. 4.0, June 19, 1998

DIN agrees with the FCD, provided the following comments are appropriately 
integrated into the document (in particular Comments #1, #2, and #43):

DIN1. Type:     Major technical
   Location: Clause 6, Clause 7

   Proposal: The definition of High-level Petri Net Graphs (HLPNG) should be
             defined on a more syntactical level!  Up to now, syntactical
             concepts and semantical concepts are mixed in HLPNG.

      DIN would be willing to make a technical proposal provided this
      direction is agreed on.  An outline can be found in the appendix
      of this vote.

   Rational: The standard claims that HLPNG are syntactical and High-level
             Petri Nets (HLPN, cf. Clause 5) are semantical.  Still, HLPNG
             uses concepts which are not syntactical such as sets (types) and
             markings.  Therefore, HLPNG are at most semi-syntactical.

      If HLPNG had syntactical representations of types as sorts and
      of markings, the concept of parameterized HLPNG would become
      technically more precise and would fit to a concept called Net
      Scheme.

             See also Comment #25
**
Partially accept.
This comment has been discussed at length via email (see inputs 5, 8,9 and 10 above). The outcome is as follows:
1. The main definition will continue to be in the same form as it was - ie places are typed (by sets) rather than sorted.
2. To cater for some analysis techniques, it is desirable to include the notion of symbolic markings as ground terms, as well as the present concrete marking via values from the algebra.
3. Implementation of 2, is probably cleanest if a net scheme is defined (in a similar way to the HLPNG) in a normative annex (favoured by the editor), or else some mention of the scheme, as well as the definition of symbolic marking via ground terms (favoured by Germany).
4. A compromise has been to include the schema definition in an informative annex.
5. Replace the word 'syntactical' in the last sentence of the first paragraph of clause 6.1, by 'semi-syntactical'.
Ed: I believe it would be confusing to include both symbolic markings and concrete markings (from the algebra) in the same definition. Those new to algebraic nets (most of industry) would not know which to use, or why the symbolic marking was there. Therefore it is necessary to separate these concerns. The rationale to include symbolic markings is based on the needs of analysis. However, I dont see why a HLPNG cant be analysed using algebraic net techniques, without symbolic markings being in the standard. Since the signature and variables are defined, the analyst just needs to define the appropriate ground terms to define the symbolic marking, and any other apparatus required. As discussed previously in a note in the CD, the reason for including a scheme is to allow classes of systems to be defined. 

DIN2. Type:     Major technical
   Location: Clause 7, Annex A.3.4

   Proposal: The definition of multiset terms (BTERM) should allow more
             general forms of expressions.  In particular, there should be
             a mechanism to define ones own BTERM operations.

      Again, DIN would be willing to make a technical proposal
      provided this direction is agreed on.  An outline can be found
             in the appendix of this vote.

   Rational: Up to now, there are many (practically relevant) HLPN which
      cannot be expressed as a HLPNG due to syntactical restrictions
      of BTERMs  In particular, Coloured Petri Nets according to
      Jensens book cannot be represented as a HLPNG.

Overtaken by events. It turns out that terms are powerful enough to express the flexibility we need, so long as the appropriate operators are defined in the signature. After considerable technical discussion by email (inputs 5, 8, 9 and 10 above), it has been agreed that BTERMs will be abolished, and that arcs will be annotated by terms that when evaluated for the algebra result in a multiset over the associated place's type. That is replace the definition of A with

- A : F --> TERM(O \cup V) such that for all (p,t), (t',p) \in F,
for all bindings \alpha, Val_\alpha(A(p,t)), Val_\alpha(A(t',p)) \in \mu Type(p)

This allows 'multiset' terms to be built using an appropriate signature - see input 9.

DIN3. Type:     Minor editorial
   Location: Clause 0, p. 6, l. 16

   Proposal: Replace `forms of high-level net' by `forms of high-level nets'
             (pl.)

   Rational: Plural

Accept
Ed: The original is also acceptable as high-level net is used to mean a class of nets in this context.

DIN4. Type:     Minor editorial
   Location: Throughout

   Proposal: Capitalization of High-level Petri Nets and other concepts
             should be handled in a uniform way.

   Rational: Up to now, there are different versions at different
             locations (e.g. High-level Petri nets at p. 6, l. 11,
             High-level Petri Nets at p. 6, l. -9, and
             high-level Petri nets at p. 7, l. 10)

Accept (see also JPN 001)

DIN5. Type:     Minor technical
   Location: Clause 3.1.1.3

   Proposal: Omit `(on variable substitution)'.

   Rational: Evaluation is quite a different operation than substitution;
             evaluation is semantical (a term is evaluated to some value in
             some domain);  substitution is syntactical (in a term variables
      are replaced by some terms; the result is another term which is
      still a syntactical object).

Accept
Ed: It is not term substitution that is meant, but substitution of a value for each of the variables. Probably '(for an assignment of values to variables)' would have been better, but this is probably not needed. 

DIN6. Type:     Minor technical
   Location: Clause 3.1.10

   Proposal: The clause should read: `A multiset of transitions associated
             with a mode' ...

   Rational: A mode does not have an explicit reference to its transition 
             (think of two transitions with the same set of variables, then
             it is not clear to which transition the mode refers to).
             Therefore, the transitions must be mentioned explicitly.

Reject.
Ed:  There are several difficulties. DIN point out an ambiguity, if transition modes do not include the transition in their definition. The standard currently uses the term 'transition mode' in clause 5, to mean a pair (t,m) which includes the transition, as well as a value (see 5.3). In Clause 7.4, the term 'mode' is used to mean an assignment to variables for a transition, which satisfies its guard.  Definition 3.1.26.2 seems to define transition mode to mean the same thing as mode. I believe the way over this is to tighten the definitions in clause 3.1.26.2, so that this distinction is clear, and so that the current definition (clause 3.1.10) concerning transition modes is maintained.

DIN7. Type:     Minor editorial
   Location: Clause 3.1.10

   Proposal: Replace `the demand placed on them' by `the demand imposed on them'

   Rational:  The word `place' might be misleading in the context of Petri nets

Accept
Ed: this will also be changed in 3.1.9, and any other occurrences I find!

DIN8. Type:     Minor technical
   Location: Clause 3.1.13

   Proposal: Replace `comprising a set of sets' by `comprising a sequence of
             sets' or by `comprising a list of sets'

   Rational: In an algebra, there may well be two equal sets which correspond
             to two different sorts (of a signature).  These two sets should
             be distinguished --- as usual in Algebraic Specifications.

Reject
After significant discussion (see 5, 8, 9 and 10), no technical problem was discovered with the approach taken in FCD15909, and it does appear to be simpler than the approach taken in some standard texts on algebraic specification.

DIN9. Type:     Minor editorial
   Location: Clause 3.1

   Proposal: Unify Capitalization of headings of clauses and of words
             after colon.

   Rational: Cf. Place and place in Clauses 3.1.14.2 and 3.1.14.3

Accept

DIN10. Type:    Minor editorial
   Location: Clause 3.1.15.1

   Proposal: Replace `a set element in a corresponding' by `an item in a'

   Rational: The original version is misleading due to the use of sets and
             multisets

Accept
Ed: This matches better with 3.1.15

DIN11. Type:    Minor editorial
   Location: Clause 3.1.18

   Proposal: Replace `instatiated' by `instantiated'
   Rational: Spelling

Accept - see also AUS04 and USA2

DIN12. Type:    Minor editorial
   Location: Clause 3.1.22

   Proposal: Replace `An' by `A'

   Rational: Spelling

Accept

DIN13. Type:    Minor technical
   Location: Clause 3.1.24.2

   Proposal: Omit `, and their reduction to simplest form'

   Rational: Evaluation is a semantical operation;  it need not be operated
             by reducing terms (cf. Comment #5)

Accept intent 
Ed: The idea here is expressed in the following example. For f(x) = 2x, g(y) = 5y, with
x,y:Nat, and the term 2(f(x))+3(4)+g(y), its value for the assignment (x,y)<- (2,1) is
2(f(2)) + 3(4) + g(1) (binding/assignment/substitution)
= 2(4) + 3(4) + 1(5) (function computation)
= 5(4) + 1(5) (reduction to simplest form)

It is accepted that there is not strictly a 'simplest form', and the following replacement text is offered:

'and any simplications performed (such as gathering like terms to obtain the symbolic sum representation of a multiset).'

DIN14. Type:    Minor technical
   Location: Clause 3.1.26.4

   Proposal: Replace `multiset of transition modes' by
      `multiset of transitions associated with a mode'

   Rational: See Comment #6

Reject
Ed - see comment on DIN6

DIN15. Type:    Minor technical
   Location: Clause 5.1, p. 11, l. -1

   Proposal: Replace `set' by `sequence' or `list'

   Rational: See Comment #8

Reject
Ed - see comment for DIN8

DIN16. Type:    Minor editorial
   Location: Clause 5.1, 5.2, 5.3

   Proposal: Replace TRANS by ACTION and PLACE by ITEM

   Rational: The abbreviations TRANS and PLACE are misleading and
             can be easily confused with sets P and T.

Reject
Ed - TRANS is the set of transition modes, and corresponds to P/T net transitions in an unfolding. Hence TRANS (not T) is an appropriate name. Similar argument for PLACE (not P).

DIN17. Type:    Minor technical
   Location: Clause 5.4

   Proposal: Define Post(T_\mu) explicitly and not as linear extension.

   Rational: The linear extension of an arbitrary function does not
             necessarily exist!  Think of an infinite multiset and
             a function which maps all items to the same element.

             Maybe, the non-existence of some linear extensions is a
             good reason to forbid infinite multisets. Cf. Comment #35

Reject proposal, but accept the comment and add the word 'finite' before multiset at the beginning of 5.4:
'Given that a finite multiset of transition modes, T_\mu, ...'. 

DIN18. Type:    Minor technical
   Location: Clause 5.4

   Proposal: Add parentheses in the equation defining M'

   Rational: Otherwise the equation might be interpreted in a wrong way.

Reject.
Ed. It follows the usual precedence rules, which are made clear in A.2.6. Addition of parentheses is therefore unnecessary, and clutters the rule.

DIN19. Type:    Minor editorial
   Location: Clause 5.4

   Proposal: Omit `(up to the maximum)'

   Rational: The statement could suggest that a maximum does always exists,
             which is not true.  Since only finite steps are allowed, there
             is no maximum number of transitions if there are enough tokens
             for infinite concurrency.

Accept

DIN20. Type: Minor technical
   Location: Clause 6.2

   Proposal: Replace  `The expressions are evaluated by substituting values
             for the variables' by `For each binding of variables, the
             expression evaluates to some value.'

   Rational: See Comment #5

Compromise. To avoid confusion with term substitution, the word 'substitution' will not be used.  The above sentence in clause 6.2 is replaced by:
'The expressions are evaluated by assigning values to each of the variables.' 
The editor will search for all occurrences of 'substitution', and replace it appropriately (using assignment or binding).

DIN21. Type: Minor technical
   Location: Clause  6.2

   Proposal: Replace all `collection' by `multiset';  the Note can be
             omitted

   Rational: By now, the concept of multiset should be known to the reader
             of the standard.
 
Reject. Leave as is, to promote the standard to a wider audience, and provide a link with the tutorial.          

DIN22. Type: Minor technical
   Location: Clause 6.3.1, l.4

   Proposal: Omit `or substitution'

   Rational: See Comment #5

Accept - see DIN20.

DIN23. Type: Minor technical
   Location: Clause 6.3, Clause 6.4, p.15, Fig. 1, Clause Annex A.3.4

   Proposal: Use of `[ 1, 3, 3]' as notation for a marking would be
             more readable.

   Rational: The Notation `1 + 2(3)' gives rise to many misunderstandings:
              +    might be interpreted as plus on numbers
       2(3) might be interpreted as multiplication of two numbers;
     parentheses should carry no meaning than structuring of
     expressions!
             Cf. Comment #32

Reject Proposal but accept the rationale. This relates to DAN2 which DIN accepts. DAN2 scales well, whereas the above proposal does not. (Consider if there were one hundred 3s, the square bracket notation would be unworkable.) Given that a marking is defined as a multiset, and the symbolic sum representation is defined in A.2.1, there should be no ambiguity.

DIN24. Type: Minor editorial
   Location: Clause 6.4. p15, l. -3 to -1

   Proposal: Replace `square (more generally by a rectangle)' by
             `rectangle (in this case a square)'

   Rational: Otherwise, there is an asymmetrie between the graphical
             representation of places and transitions.  Therefore, the
             general case should occur outside parentheses in both cases
             (or vice versa).

Accept
Ed: A bit of English variety has no place in a standard!

DIN25. Type: Major technical
   Location: Clause 7

   Proposal: The algebra H as well as references to it should not occur
             within the definition of HLPNG.  Omit $H$ completely and
             replace

                Type by Type: P --> S
                M_0  by a syntactical object (cf. Comment #1 and Appendix)

   Rational: HLPNG should only consist of syntactical objects
             Cf. Comment #1 and Appendix

Reject - see response to comment 1.

DIN26. Type: Minor technical
   Location: Clause 7.2, p. 19, ll. 1-2

   Proposal: Omit `for Type(p) = H_s' and replace `BTERM(O \cup V)'
             by `BTERM(O \cup V)_{Type(p)}'

   Rational: More concise notation, comprehensibility.

Overtaken by events - BTERMs are abolished - See comment for DIN2.

DIN27. Type: Minor editorial
   Location: Clause 7.2, p. 19, l. 3

   Proposal: Replace `with a multiset of terms' by `with a multiset term'

   Rational: This is needed due to the change in the previous version; arcs
      are inscribed by a multiset term (cf. Annex A.3.4)

Overtaken by events -  see comment for DIN2 (arcs will be annotated by terms).

DIN28. Type: Minor editorial
   Location: Clause 7.4

   Proposal: Replace `assign_{bool}' to `Val_{\alpha}' etc.

   Rational: Otherwise, there is no link from \alpha to assign_{bool}
             see Annex A.3.6 (but even there, there are some inconsistencies
             cf. Comment #41)

Accept intent. 
Ed: assign is used for terms (see A.3.6) whereas Val is used for multiset terms, not terms. Since TC is a term, assign is the correct function for the evaluation. However, because BTERMs no longer exist, the function Val is now used for terms (assign is abolished), and hence Val_{bool, \alpha_{t}}(TC(t)) = true is now used in clause 7.4.1.

DIN29. Type: Minor technical
   Location: Clause 7.5

   Proposal: Add parentheses to the definition of M'

   Rational: Dissolve ambiguities (cf. Comment #18)

Reject
Ed: same reason as in response to DIN18

DIN30. Type: Minor technical
   Location: Clause 8.2

   Proposal: Replace `the name of the type (Type(p))' by `sort'

   Rational: Otherwise Type(p) is a set which
             has no name at all!  But the sort of the Signature would do
             because it is a syntactical object.
             Cf. Comments #1, #25, and Appendix

Reject.
Ed: This is subtle. Because the HLPNG is purposely defined concretely (using the algebra) (see response to DIN1), different sorts may be mapped to the same set in the algebra (see DIN8). eg H_s1=H_s2=Z (the integers). The idea is to label the place with the name of the place's type (eg Z), because the HLPNG is operating at the concrete level. Associating different sorts to places, which are typed the same, would be confusing.

DIN31. Type: Minor editorial
   Location: Clause 8.3

   Proposal: Replace `A Transitions' by `A transition'

   Rational: Typo?

Accept: Replace the capital T by lower case (t).

DIN32. Type: Minor technical
   Location: Clause 8.4, Annex A.2.1

   Proposal: There should be an explicit symbol for multiplication
             of multisets by natural numbers; e.g. `. x .'

   Rational: Parentheses should not be overloaded; in case of multisets
             over numbers parentheses are ambiguous! Cf. Comment #23.

Accept intent
DAN2 and the response to DIN23 solves this problem.

DIN33. Type: Minor technical
   Location: Clause 9, p. 22

   Proposal: The definition of the semantics of HLPNG can be significantly
             simplified in the following way:

             Define
               Type(t) = {\alpha: V_t --> S |
                           \alpha is an assignment such that
                                      Val_{\alpha}(TC(t)) = true }

             where V_t is the set of variables associated with transition t.

             Then, the lambda-expressions and TC' are not needed any more.

             Pre(p,t) can be defined as Val_{\alpha}(A(p,t)) and
             Post(p,t) as Val_{\alpha}(A(t,p)).

   Rational: Lambda expressions and TC' are not necessary and make the
             concepts more difficult to understand.

Accept intent
Ed. Although the current version is technically correct, this is a useful simplification as stated in the above rationale, we dont have to introduce new notions (Lambda expressions). The technical details need refinement. The following change incorporates the intent of this comment.

In Clause 9, 

Given the removal of BTERMs and replacement of assign by Val for terms in A.3.6,

1. replace the first two paras of page 23 (point 3) by

Define V_t \subseteq V as the set of variables associated with transition t.
Define \alpha_t as an assignment for H and V_t (cf A.3.6).

Then Type(t) = {\alpha_t | Val_(bool,\alpha_t)(TC(t)) = true}

2. replace point 5 by

The pre and post maps are given, for all (p,t), (t,p)\in F, by the following family of mappings:

Pre_(p,t) : Type(t) ---> \mu Type(p)
Post_(p,t) : Type(t) ---> \mu Type(p)

For (p,t)\notin F ... (as before).

Thus for all t\in T, and for all m\in Type(t)

Pre(t,m) = {(p,b)| p\in P, b\in Pre_(p,t)(m)}
Post(t,m) = {(p,b)| p\in P, b\in Post_(p,t)(m)}

where Pre_(p,t)(m) = Val_{alpha_t = m}(A(p,t)) 
and Post_(p,t)(m) = Val_{alpha_t = m}(A(t,p))

DIN34. Type: Major technical
   Location: Clause 10.1.1

   Proposal: Omit l. 4--8

   Rational: The status of this part is not clear at all! Is it normative?
             Is it an implicit norm for place transition systems?
             A norm for P/T-systems should not be defined as a special
             case of P/T-systems because of mathematical overhead.
             Cf. Comment #43

Reject
The clause is normative. The US requested that 'Petri nets' be defined as a subclass, in their vote of disapproval of the CD. It was always intended to define subclasses in a normative annex, which has been included in all drafts of the standard. Given the major nature of the change, and that 17 countries have approved this version, its removal is not possible. I would agree with DIN that the specialisation of the definition of the HLPNG results in large mathematical overhead, but it does show the relationship. Note that a more usual definition of 'Petri nets' is given at the end of B1.

DIN35. Type: Minor technical
   Location: Clause Annex A.2

   Proposal: Perhaps, multisets should be restricted to finite multisets

   Rational: Only for finite multisets all functions have a
             linear extension. Cf. Comment #17.

Ed: This has been dealt with in the response to DIN17.            

DIN36. Type: Minor technical
   Location: Clause Annex A.3.1, A.3.3

   Proposal: Separate variables from signatures

   Rational: Defining variables within signatures is very unusual.  In
             particular, it makes a change of the signature necessary, when
             a new variable is introduced.

Accept
Ed: On the basis that it may make the standard easier to read. This affects clause 7.2 (inclusion of V in the HLPNG tuple, change def of Sig, etc) and A.3.1, A.3.3 and B.1. 

DIN37. Type: Minor technical
   Location: Clause Annex A.3.3

   Proposal: Omit `For s, s_1, ..., s_n \in S (n > 0)' on p. 26, l. -1 and
             include it into the third item on p. 27, l.3.

   Rational: Otherwise, the binding of n and the s_i is in the wrong way;
      n is fixed before the operator an its arity is known. In
      particular, n may change for each operator.  To make the
      definition mathematically sound, the binding must not be global.

Accept intent.
Ed. This is subtle but important for the induction to work correctly. The agreed  proposal is to leave 'For s\in S' on page 26, as it is needed for points 1 and 2 (as well as 3) on page 27, but then to state at the beginning of 3. `For s_1, ..., s_n \in S (n > 0)', in alignment with DIN's proposal.

DIN38. Type: Minor technical
   Location: Clause Annex A.3.4

   Proposal: Add subscript `s' for each BTERM(O \cup V)

   Rational: Otherwise BTERM(O \cup V)_{s}is not defined  (but used)

Overtaken by events, since there is no longer any need for BTERMs, the problem no longer exists.

DIN39. Type: Minor technical
   Location: Clause Annex A.3.4

   Proposal: Add a forth way for defining BTERMS:

             * If u is a term of sort boolean and b is a BTERM,
               then [u] b is a BTERM

   Rational: Otherwise, the abbreviations defined below are not really
             defined; e.g. [m = e] b

   NOTE: Perhaps, there should be another notation not using square brackets
         which are proposed to denote multiset in these comments.

Overtaken by events as BTERMs are no longer required. 
Ed. The User is free to choose any operator symbols, so there is no need to define it in the standard.

DIN40. Type: Minor technical
   Location: Clause Annex A.3.5

   Proposal: For Boolean and Natural signatures there should be an
             explicit requirement, that the sets associated with bool
             and nat are {false, true}and the natural numbers, respectively.

   Rational: Otherwise, being a Boolean or Natural signature is only a
             syntactical requirement which is not reflected in the semantics.

Agree with intent.
Ed. In A.3.2 this correspondence is given in paragraphs 1 and 2, so it is already taken into account. However, clause A.3.2 has been revised in the light of deleting clause A.3.4 (BTERMs), as there is no longer a requirement for a Natural signature. Clause A.3.2 now comprises just the first paragraph, further clarified to ensure that these concerns are taken into account. 

DIN41. Type: Minor technical
   Location: Clause Annex A.3.6

   Proposal: Replace assign by Val

   Rational: See Comment #28

Accept (overtaken by events)
Ed: assign is used for terms, whereas Val is used for multiset terms (see DIN28, DIN33). With the removal of multiset terms (BTERMs), Val is now used for terms in preference to assign. This has been done consistently throughout.

DIN42. Type: Minor technical
   Location: Clause Annex A.3.6

   Proposal: In analogy to Clause A.3.3 the binding of \sigma, s and n
             should be made in the third item.

             Moreover, the items should be numbered as in A.3.3

   Rational: See Comment #37

Accept intent in a similar way to DIN37.

DIN43. Type: Major technical
   Location: Clause Annex B

   Proposal: Omit Annex B or make it informative.

             If this Clause is not omitted, call Clause B.1
             Place/Transition Systems (P/T-systems).  The name `Petri net'
             does not stand for a particular version of Petri nets.

   Rational: The standard should be for high-level Petri nets.  By the
             definition of place transition systems as special cases there
             would be a standard for low-level nets either;  but defining
             place transition systems as special case of high-level nets
             is not appropriate.

Reject but accept the intent of the comment
Ed: see response to DIN34. The change of name from Petri nets to Place/Transition Systems is problematic, as the usual definition of P/T systems includes place capacity. It is agreed that Petri nets is not a good name, because that term is used loosely.  It has been agreed to use the term 'Place/Transition nets' for this class of net, with an appropriate change to the introductory paragraph of Annex B.

DIN44. Type: Minor editorial
   Location: Bibliography, p. 41, l.8

   Proposal: Replace `Grunlagen' in B. Baumgarten's book by `Grundlagen'

   Rational: Typo

Accept.
-----------------------------------------------------------------------------

Appendix
========

This appendix gives a brief outline, how the to separate syntax and semantics
more clearly in HLPNG.  Moreover, it shows how BTERMS can be more general and
(and in part be specified by the user).  This text is based on a communication with the editor of the Standard, J. Billington.

If the committee agrees on a clearer separation of syntax and semantics, DIN
would be willing to work out these idea in more detail.

Including Flexibility
=====================

The basic idea is to implicitly associate each sort s of some signature
SIG = (S,O) with a CORRESPONDING MULTISET (or bag) SORT b(s).  Then,
operators (resp.  the arity of the operators) of the signature may be on
sorts s as well as on sorts b(s);  for clarity I will distinguish this kind
of signatures by calling them multiset (or bag) signatures.

In the following I will roughly sketch a formalization of these concepts;  if
you like these concepts I could formalize them in the style of the standard.

A MULTISET (or bag) SIGNATURE is a tuple BSIG = (S,O), where S is a finite
set of SORTS and O is a finite set of OPERATORS.  Each sort s \in S is
(implicitly) associated with a unique sort b(s).  We define
  BS = S \cup {b(s) | s \in S }
Each operation o \in O is associated with an ARITY of BS* x BS.  For clarity
I will use symbol s for elements of S only;  I will use z for elements of BS.

Then, TERMS can be defined as usual:  For a sorted set of BSIG-variables
V = (V_z)_{z \in Z}we define:
- for o \in O_(\epsilon,z) we have o \in  TERM(SIG,V)_z
- for v \in V_z we have v \in TERM(SIG,V)_z
- for o \in O_(z1...zn,z) and ei \in TERM(SIG,V)_{zi}
  we have o(e1,...,en) \in TERM(SIG,V)_z

The BTERTMs used in the current version of the standard can be defined as
follows:  For each s \in S  BTERM(SIG,V)_s = TERM(SIG,V)_b(s).
Basically, the uppercase B has moved from the front to a lowercase b
at the end.

The standard operations on BTERMS (cf. A.3.4) can be included in any
multiset algebra by definition (if you want to): For each s \in S
the set of operators O should contain  the following operations:

 [.] : s --> b(s)     (this makes an element of sort as a singleton multiset)
  . x . : Nat x b(s) --> b(s)
  . + . : b(s) x b(s) --> b(s)

Now, what is an algebra corresponding to BSIG = (S,O): A tuple H = (S_H, O_H)
is a multiset algebra, if S_H is a family of sets which associates each sort
s \in S with a set H_s.  Moreover, we define H_{b(s)}= \mu H_s;
i.e. H_{b(s)}is a multiset over the set H_s corresponding to sort s.
Moreover, for each operation o(z1...zn,z) \in O there is an operation
o_H \in O_H such that o: H_z1 x ... x H_zn --> H_z.

If you have the standard operations on multiset included by definition, we
of course need to define that the corresponding operations in the algebra
behave accordingly.

That's it.

What is more as long as BSIG does not contain any additional operations
which refer to a sort  b(s),  there is no difference to the current version of
the standard.

Separation of Syntax and Semantics
==================================

In addition to the above proposal, I would like to plead (again) for a
clearer separation of syntax and semantics in the standard!  I appreciate
the distinction of high-level Petri nets and high-level net graphs.  The
main motivation (see introduction) seems to be the separation of syntax
and semantics.  This is achieved for transition inscriptions and
arc-inscriptions; but, not for markings.

The inscriptions Type is semantical since each place is associated with a
set. Why don't we use Type: P --> S;  then this inscription is also
purely syntactical.  The initial marking could be syntactically represented
by M: P --> BTERM(SIG) such that M(p) \in BTERM(SIG)_Type(p).
In my opinion the syntactical representation does not contradict the fact
that markings are changing dynamically.  Similar to the correspondence of
syntactical arc-inscriptions to the semantical concepts of Pre and Post, there
is a correspondence between the syntactical representation of markings to
the markings of high-level Petri nets.  There is no reason to consider
markings to be `more semantical' than arc-inscriptions, isn't it?

To sum up: Everything (except for the algebra itself) in net graphs
can and should be syntactical.  This would support the compatibility with
the concepts of net schemes.  Indeed in that case,  a net scheme is just
a net graph without an algebra.

------------------------------------------------------------------------

JAPAN (Approve with Comments)

JPN 001 E: Unify the spelling for "High-level Petri Net". For example,
followings are used:
                 Line 34 of Page 6  "High-level Petri Nets"
                 Line 3, 9 of Page 7  "High-level Petri nets"
                 Line 34 of Page 8  "High-level Petri Net"
   Line 23 of Page 11  "High-level Petri nets (HLPN)"
   Line 8 of Page 13  "HLPNs"

         Also, unify for "High-level Petri Net Graph":
                 Line 36, 41 of Page 6  "High-level Petri Net Graph"
                 Line 9 of Page 13  "High-level Petri net graph (HLPNG)"
                 Line 17 of Page 13  "High-level Petri Net Graph"
   Line 2 of Page 14  "HLPNGs"

Accept - see also DIN4
Ed.  High-level Petri Net, and High-level Petri Net Graph are now used throughout the document.

JPN 002 E: Replace the followings with "HLPNG" according to the definition of Line 9 in Page 13.
                 Figure 1 of Page 15  "HLPN-Graph"
                 Figure 2 of Page 17  "HLPN Graph"
                 Line 25 of Page 21  "HLPN Graph"

Accept the above 2 (figure captions), but for clarity in a major heading, spell out in full to be consistent with other major headings.  This helps with the table of contents, where the reader has not yet come across the abbreviations.

JPN 003 E: P.3, Contents: The table of contents shall not include sub-sub
clause to conform to "6.1.2 Table
  of contents (p.34)" of the ISO/IEC Directives Part3, 1997.

Rejected. The ISO/IEC Directives Part3, 1997, p3, uses 3  levels of headings in its own table of contents, and this is standard type setting practice enforced by good word processors (like LaTeX).  (This is a too literal reading of clause 6.1.2 (on page 19) of the Directives.)

JPN 004 E: P.8, 3 Terms and Definitions: The introductory wording should be added to conform to
  "6.3.1 Terms and definitions (p.38)" of the ISO/IEC Directives Part3,
1997.

Accepted.
Ed: My reading of the Directives suggests that Clause 3 should be Terms and Definitions, and Clause 4 should be Symbols and Abbreviated Terms. This is a bit of work for the editor renumbering the definitions. 
On closer reading of the directives, having abbreviations and terms and definitions in the one clause is allowed, so long as the heading is changed appropriately - see the last para of the Directives clause 6.3.2 (page 21).

JPN 005 E: Symbols, such as mathematical symbols, should be listed in the
clause titled "Symbols and
    abbreviated terms" to conform to "6.3.2 Symbols and abbreviated terms
(p.38)" of the ISO/IEC
    Directives Part3, 1997.

Accepted. 
It was agreed at the Curitiba meeting for the Petri net specific mathematical notation, M[T_\mu\rangle M', be defined in clause 4.

JPN 006 E: P.11, L.19: "Note: " shall read as "NOTE  ".

Accepted

JPN 007 E: P.12, L.21: "M[T >M' " should read as "M[T >M']".

Rejected. The current notation is correct, the suggested change will make it incorrect.

JPN 008 E: P.13, L.27, L.31: The meaning of "x" and "y" used in "f(x)" and
"x<y" should be described.

Accept. (eg x,y) will be inserted after the first instance of variables in the fourth bullet point of clause 6.2

JPN 009 E: P.14, L.23: "... in subclause 6.4" shall read as "... in 6.4" (It
is unnecessary to use the term
  "subclause").

Withdrawn. It is left up to the editor's descretion as to which form is used, but it must be consistent throughout the document.

JPN 0010 E: P.14, L.31 and P.15, L.9: These lines needs clause numbers.

Accept.
Create

'6.3.2 Transition Rule for a Single Transition Mode'

and then

'6.3.3 Step of Concurrently Enabled Transition Modes'

JPN 0011 E: P.15, L.18-19: "The places are represented by ... and the arcs
by arrows." should be replaced with the sentence referring Clause 8 which defines the
representation of places and so on.

Withdrawn

JPN 0012 E: The capitalization of terms such as Declaration (L.10 of P.18
and L.10 of L.20) and marking (L.20 and 23 of P.19) should be consistent.

Accepted

JPN 0013 E: P.20, L.9: The sentence "defining all the types ... the Graph
part) duplicating with 3.1.8
   Declarations in Clause 3 Terms and Definitions should be deleted.

Withdrawn

JPN 0014 E: P.21, L.6-7: "The position of ... is a matter of taste, and is
not mandated." shall read as "The
     position of ... is not mandated." properly as the International
Standard.

Accepted. The words 'is a matter of taste, and' will be deleted.

UK (Approve with Comment)

UK1E: p6 line 2 - do you wish to add ",design" after specification? cf the points in 1.2

Accept
Ed: Yes

UK2E: p7 sect 1.2 - I propose the examples in the final paragraph be given in alphabetical order so as not to imply any priority

Accept

UK3E: p9 sect 3.1 - do you wish to define "type" cf use in 3.1.11

Accept
Ed. Add
'3.1.27 Type:  a set'

UK4E: p9 3.1.18 - typo "instatiated"

Accept (see AUS04, USA2)

UK5E: p12 sec 5.3 - Do you wish to add a Note pointing out that a transition may be concurrently enabled with itself? Just for clarity.

Accept

UK6E: p15 sec 6.3 - At the end I would replace "next subclause" by Subclause 6.4

Accept.

UK7E: p16 next last line. I suggest that black tokens be called "unstructured" rather than "ordinary"

Compromise.
After discussion at Curitiba, it was agreed to use the word "simple" rather than "ordinary".

UK8 TL p26 Ed Note- I think you only need the constant 1 given the third part of the definition on p27

Overtaken by events. BTERMs have been removed, and hence dont need the naturals.

UK9E: p27 A.3.4 line2 - repeated word "than"

Accept

UK10TL: p35/36 ExampleE - on the last line of p35 the word "receive" is used does this imply the direction of the arrow in Fig 9 is wrong? I ask the author to check.

Accept
This is an error in Example_F which needs to be fixed.

UK11E: p41 Biblio - Should the Lakos/Christensen Zaragoza paper the author refers to in his reply to comment ITATH01 be included in the biblio?

Accept:  Yes include this reference in the Bibliography.

USA (Approve without comment)

but - these comments from Prof Tad Murata should have been included:

USA1 E 
Clause 3.1.13: Add a space between  "3.1.13" and "Many-Sorted Algebra"

Accept
 
USA2 E
Clause 3.1.18:  Check the spelling of the word, instatiated.
 
Accepted - replace by instantiated (see AUS04)

USA3 E
 Annex C, Figure 10: Part of the label on the arc from 
 {(Alice_s_purse, c10 + c50)}to {(Alice_s_purse, c10)}
 seems to be cut off when pasted. 
 It should be (spend, {(x, c50)}). 

Accepted
 
USA4 E
 Annex C, Fig. 13 Example_G: Change subscript "o" to "0" in 
 M0(Crates_in_transit) = Mo(Letters_in_transit) = Mo(store_room)
                          ^0 not o                 ^0 not o
 
Accepted

------------end disposition report----------------------------------------
Email from Kindler (Germany) (input 5.3)

Date: Mon, 10 May 1999 20:05:51 +0200
From: Ekkart Kindler <kindler@informatik.hu-berlin.de>
Subject: Re: Draft Disposition Report, FCD15909 (Second try)

Dear Jonathan,

by now, I have had a closer look at your comments and at your new proposal
concerning the PN-standard.

I do agree that we are converging.  In order to make sure that I did
understand the basic changes in your new proposal, let me briefly rephrase
them in my words:

1. In the new version, there will only the concept of terms (no BTERMS any- 
   more);  but there will (must) be terms which evaluate to multisets
   in the corresponding algebra.

2. An arc-inscription is legal if it evaluates to a multiset
   of the sort/type corresponding to the involved place for all assignments.

3. There will be a semantical (concrete) concept of a marking and a (more)
   syntactical concept of a marking.

This way, the version of algebraic Petri nets as defined by the standard
allows sufficient `flexibility'.  Therefore, we can live with this new
proposal.

One problem, however, is the schema aspect, were a schema is an algebraic net
without a fixed algebra.  Without a fixed algebra, we cannot define legal
arc-incriptions anymore (because evaluation of terms is no longer possible).
This would require a more syntactical definition (as proposed in my previous
comment).  One way out of this is to define a schema as a HLPN with a
set (or rather a class) of associated algebras; then, an arc-inscription of a
HLPN-schema is legal, if the term evaluates to a multiset of the corresponding
sort in all algebras for all assigments. This seems to be in the spirit of
the definition of HLPN.  What do you think of that?

Still, I tend not to include the schema aspect into the standard.
But, it would be nice to have at least some hints on schemas and on the
relation of HLPNs to schemas in the standard.

Even if schemas do not occur in the standard, I propose to have a concrete
concept of markings as well as a syntcatical concept of markings (ground terms
which evaluate to multisets)---this makes sense for some analyis algorithms
(cf. my previous emails).

I hope this helps to settle our discussion.

Best wishes,
Ekkart
--
PS: Concerning the meeting in Brazil:  Unfortunately, I don't have the money
    to come to this meeting (I rather spend it for visiting Williamsburg).
-------------------------------------------------------------------------
Email to Kindler on 24 April 1999 (input 5.2, which includes input 5.1 - both circulated to WG11 members by email)

Dear Ekkart,

It is a long time since you made your input on the standard, and I am now just starting to get back into it, due to pressure of other pressing things.

Many thanks for all the thought you have put into this.
Please see my comments below. I think we are converging.

I would like to come to a conclusion about this as soon as possible, to get the disposition and the final text agreed in the next couple of weeks for ratification at the WG11 meeting in Curitiba, Brazil, in the last week of May - if at all possible.

Best regards - Jonathan

>Dear Jonathan, dear Members of WG11, dear Petri net experts,
>
>in the Draft Disposition Report on FCD 15909 some fundamental changes
>of the DIN FCD1509 vote have been rejected.  We are convinced that
>the proposed changes are important and will significantly improve the
>standard and its acceptance.  Therefore, I will try to convince other
>national bodies of the significants of these changes and to vote in favour
>of these changes.
>
>Kind regards,
>Ekkart Kindler
>
>==========================================================================
>This DIN reply to the Draft Disposition Report on FCD 15909 is structured
>as follows:
>
>  I. Arguments for a clearer separation of syntax and semantics
>
>
>  II. Proposed changes 
>
>    1. For separation of syntax and semantics
>
>    2. Customizable operations on BTERMS
>
>
>  III. Detailed reply to comments in the Draft Disposition Report
>
>
>I. Arguments for a clearer separation of syntax and semantics
>-------------------------------------------------------------
>
>DIN has proposed a version of HLPNG which is purely syntactical (see DIN1).
>As it stands, HLPNG are not purely syntactical because types as inscriptions
>of places and markings are semantical.
>
>There are several reasons for a clear separation of syntax and semantics.
> 1. When using HLPNG (in particular when implementing a tool), there needs to
>    be a syntax for these annotations anyway.  Maybe there is a common sense
>    syntax for some types (e.g. natural numbers); but in general there is no
>    such syntax (see below). 

The standard only provides an abstract syntax - the form of the syntax by terms - but
no notation for types, operators etc is mandated here - what is mandated is the semantics via clause 5. This allows different syntaxes, but with a common semantics. It provides the possibility of translating between the different syntactic variants. In implementing a tool, a concrete syntax needs to be defined. This is currently not within the scope of this standard, and it would be extremely difficult to get consensus on this, given the different tools in the market place. It would also take a lot more work, and can't be included in this standard.
>
> 2. There are some analysis methods for high-level Petri nets, which need
>    a purely syntactical representation of a marking.  Here are two examples:
>
>      M. Lindquist: Parameterized reachability trees for predicate/transition
>      nets. PhD thesis.  Acta Polytechnica Scandinavica, Ma 54, 1989
>
>      K. Schmidt: Parameterized reachability trees of algebraic Petri nets.
>      16th ICATPN, Springer 1995.

It is nice to have as many analysis methods as possible, but this is no reason to vote against the standard, which is concerned with providing an unambiguous specification language with an agreed semantics. I suspect that these analysis techniques can also be used to prove properties about a scheme, which would then provide results for a concrete version, that is described by an HLPNG, with a particular algebra - so I dont think anything is lost here.
>
>  3. In a more syntactical version, HLPNG would better fit to the concept
>     of Algebraic Net Schemes proposed by W. Reisig!  Then, Algebraic Net 
>     Schemes are just HLPNG without a fixed algebra.

It is certainly possible to have a more syntactic form, that does not include the algebra, for the purpose of defining schemes. What I am proposing here is that both forms are included, as we need both. This was indicated in an editor's note in the CD. In my response to DIN in the draft disposition, I indicated that we could include both. 
I am not sure what DIN's position is with respect to having both the scheme and a concrete definition. Is DIN happy with this?
>
>I miss to see the editors point that the HLPNG should be concrete (see reply
>to DIN1).  Would a syntax for -- let's say -- PASCAL be more concrete if the
>part about the syntactical representation of real numbers would be left
>semantical?  I would rather say, that this syntax would be incomplete.
>Maybe, having the standard syntax for natural numbers as inscription for
>markings of sort Nat is nicer than some awkward representation by a term
>succ(succ(zero)).  Though this works nice for natural numbers (and some
>standard data types), this does not work if there is no common understanding
>(pragmatic) of the data type.  The current version of HLPNG allows any type
>-- it might not have any `common sense syntax' (e.g.  Agents when modelling
>distributed algorithms).  Therefore, HLPNG must provide a syntax for these.
>A more convenient syntax for standard data types could be easily introduced
>by conventions.

See comment under 1. above. We need concrete markings, and to run the net at the concrete level - as this is what is meaningful for industrial applications. Moving terms around the net is not easy to relate to the physical world - as I have indicated to you in a previous email.
>
>In II.2 there will be a proposal how to give a purely syntactical definition
>of HLPNG; note that there will be the notion of a `symbolic marking' which is
>the syntactical representation in HLPNG and there will be a notion of a
>`marking' which is its semantical counterpart.  Everybody is free to use only
>semantical markings -- if he wants to.  But, there should also be a 
>concept of
>HLPNG for symbolic markings (cf. 2.).
>
OK - it seems that you are accepting that there should be both. Am I right? - see under 3 above.

>
>
>II. Proposed changes
>--------------------
>
>In this section, we propose a change of the definition of HLPNG which
>is purely syntactical and allows some more `flexibility' in building
>BTERMS.  Both aspects are independent of each other.

Given that we have concrete items for places, transitions and arcs, we are going to have a mixture of syntactic and semantic anyway. So I guess it is not purely syntactic, but certainly more syntactic, and suitable for describing schemes - which is fine.
>
>II.1. Syntactical representation of HLPNG
>-----------------------------------------
>
>This changes are basically the same as proposed in DIN25 and DIN26.  The
>function Type is changed to associate a sort of the signature to each place
>(rather than a type).  The initial marking is replaced by a symbolic
>initial marking.  Moreover, there is a concept of marking and of initial
>marking of a HLPNG.
within in the same definition? - hence a mix?
>
>Clause 7.2:
>  Replace: Type: P --> S_H  
>  By:      Type: P --> S
>
Not sure that this is what you want - see below - and agree that in the scheme this function should be Sort rather than Type.
>  Replace first sentence on page 19 (arc annotations)
>  By:   - A : F --> BTERM(O \cup V) such that for all (p,t), (t',p) \in F,
>          A(p,t), A(t',p) \in BTERM(O \cup V)_{Type(p)}.

This is too restrictive, as we need to allow for subtypes and multisets in the concrete version. (Ie there may be several sorts that would be compatible, not just Type(p).) The current definition attempted to deal with this by allowing any sort s, that mapped to a carrier H_s = Type(p), to be the sort of BTERM. But this is also restrictive. I now think that what is required is to replace the def of A with

- A : F --> BTERM(O \cup V) such that for all (p,t), (t',p) \in F,
for all bindings \alpha, Val_\alpha(A(p,t)), Val_\alpha(A(t',p)) \in \mu Type(p)

in the current definition.
That is, so long as the annotation on an arc evaluates to a multiset over the associated place's type, then it is allowed. (This is what is required by the enabling condition and the transition rule.)

>
>  Replace last item of the definition of HLPNG (marking)
>  By:   * M : P --> BTERM(O) such that for each p \in P:
>          M(p) \in BTERM(O)_{Type(p)}, is the symbolic initial marking.
>
>  Replace in the text following the items: `A typing function associates ...'
>       (up to the end of this paragraph).
>  By:  The typing function associates a sort of the signature with each 
>place.
>       A place is inscribed by a BTERM representing the initial marking
>       (see Clause 7.3) of this place.
>
>Note that, capital M will be used for symbolic markings; m will be used for
>markings. Maybe, the function Type should now be named Sort.
(Yes agreed Type --> Sort)

>
>Clause 7.3 (completely new text):
>       A marking, m, of the HLPNG is defined by
>       m: P --> \bigcup_{p \in P}\mu H_{Type(p)}such that
>       m(p) \in \mu H_{Type(p)}.  The initial marking of the
>       HLPNG is defined by: m_0(p) = eval(M(p)).

This, and the above changes, seem to suggest that the algebra, H, is maintained in the definition. Wouldn't it be cleaner to have schemes defined without the algebra (as it plays no part), and then have a concrete version that does include H?
>
>Ed. Note: eval is the evaluation function which can be defined by
>eval = Val_{\alpha}where \alpha is the unique assignment:
>\alpha: \emptyset --> H.  This must be added in Appendix A.3.6
>(see II.2 and below).
>Moreover, a convention of syntactical representations of constants of
>standard sorts (Nat, Bool, etc.) could be introduced.

What did you have in mind?

>
>If the above changes are accepted, the following  clauses
>need to be adapted in order to conform with the changes:
>  - Throughout: M and M' must be replaced by m and m'
I would not recommend this. Much prefer that it is the syntactic version that has lower case, and the concrete version upper case - as at present.

>  - Glossary (Clause 3.1):
>      + Symbolic initial marking must be added
>      + Place Type must be replaced by Place sort
>  - Clause 6.2 Place Types must be also replaced by Place Sorts and
>               Place Marking must be replaced by Symbolic Initial Marking
>  - Clause 6.3 The concept of marking must be added.
>  - Clause 8.5 Can be omitted
>  - Clause 9 (3rd item last paragraph) `D = ...' must be replaced by
>       D = {H_{Type(p) | p \in P}\cup {Type(t) | t \in T }.
>  - Clause A.3.6: At the end, the special case of an evaluation eval
>       must be defined (see above and II.2).
>  - Clause B.1: Replace Type: P --> {dot}by Type: P --> Dot and
>       replace M_0: P --> Dot by M: P --> BTERM(O)
>  
Probably not necessary, given that the concrete form is maintained. Possibly one could add a para in clause 6 on the scheme.   
>
>II.2. Customizable operations for BTERMS
>----------------------------------------
>
>As it stands, BTERMS can be inductively build from TERMs (Clause A.3.4) by:
>i'a,   i x b, and  b1 + b2 (where i is a term over Nat and b, b1, b2 are
>BTERMS of appropriate sort).  In DIN2 we argued that this is restrictive.
>For example, there is no BTERM with one variable i (over Nat) which gives
>us the multiset [1 , 2 , ... , i ] for each chosen value i, i.e. for each
>i each number up to i occurs exactly once in the multiset. (at least, I
>fail to see that this is possible;  the problem is that the user is free
>to define operations on the TERM-level but NOT on the BTERM-level according
>to the current version of the standard).
I think we can do without BTERMs all together, and just use appropriate operators in the signature to define whatever we like. This was the comment made in the draft disposition.
>
>In order to allow more flexibility for defining own BTERM-constructs, there
>was an outline of a definition of BTERMS in the Appendix of the DIN vote.
>Here, we give a full definition which basically replaces A.3.  In this
>proposal, we subsume proposal DIN36 (separation of variables from signatures)
>for a more convenient presentation -- but the proposal works without that.
>For arguments in favour of the separation of Variables from Signatures
>see III, DIN36.
>
>  A.3.1 Multiset Signatures
>
>  A many-sorted multiset signature BSIG = (S,O) comprises
> 
>     * a set S of sorts (sort symbols)
>       for each sort s \in S we define a unique sort b(s) representing
>       the corresponding multiset sort over s;  we define
>       B(S) =  S \cup {b(s) | s \in S }

This is providing a restriction of the signature, which isn't warranted for the concrete definition, although it may be useful at the level of schemes.
>
>     * a set O of operations (operation symbols); each operation o \in O
>       is associated with an arity B(S)^+, where B(S)^+ denotes the non-empty
>       sequences over B(S).  Technically, O = (O_a)_{a \in B(S)^+}is an
>       B(S)^+ indexed set.
>
>  NOTE: o \in O_z with z \in B(S) is called a constant of BSIG.
>
>
>  A.3.2 Variables for a Multiset Signature
>
>  For a multiset signature BSIG = (S,O) a B(S)-indexed set
>  V = (V_z)_{z \in B(S)}disjoint from O is a variable set of BSIG.
>
>
>  A.3.3 Terms
>
>  Let V be a variable set for BSIG = (S,O).  The BSIG-Terms over V, denote by
>  TERM(BSIG,V)_z, are inductively defined by:
>
>     * for z \in B(S) and o \in O_z: o \in TERM(BSIG,V)_z
>
>     * for z \in B(S) and v \in V_z: v \in TERM(BSIG,V)_z
>
>     * for z_1...z_n z_{n+1}\in B(S) and o \in O_{z_1...z_{n+1}}and
>       e_i \in TERM(BSIG,V)_{z_i}for i=1, ..., n:
>            o(e_1, ..., e_n) \in TERM(BSIG,V)_{z_{n+1}}
>
>  A.3.4 Algebras
>
>  For a multiset signature BSIG = (S,O), a BSIG-Algebra H = (A,F) comprises
(careful with A and F - as they are already used in the definition - arc annotation
and flow relation - other symbols required)
>
>     * an indexed set A = (A_z)_{z \in B(S)}of non-empty sets such that for
>       each s \in S we have A_{b(s)}= \mu A_s, i.e. each domain of a
>       multiset sort b(s) is really a multiset over the domain 
>corresponding to
>       sort s.
>
>     * an indexed set of functions F = (f_o)_{o \in O}where
>       f_o: A_{z_1}x ... x A_{z_n}\rightarrow A_{z_{n+1}}for
>       o \in O_{z_1...z_{n+1}}.
>
>  Convention:  We assume that each sorted multiset signature BSIG = (S,O) has
>  the sorts Nat and Bool and for each sort s \in S there are the following
>  operations:
>      .'. : Nat s --> b(s)
>      .x. : Nat b(s) --> b(s)
>      .+. : b(s) b(s) --> b(s)
>
>  For each algebra, we assume that Nat and Bool correspond to the set of
>  natural numbers N and the set Boolean, resp.  Moreover, the functions
>  corresponding to the operations .'. , .x., and .+. have the usual meaning.
>
>Ed. Note: This could be defined more formally.

OK - all this is very nice, as it shows how the appropriate operators can be defined to obtain the syntax that is wanted for arc expressions when multiset descriptions are required on arcs - but they are not required all the time. Hence, all we need to do is to annotate arcs with terms. If we need the machinery above, then this has nicely illustrated how it can be done. It may be appropriate to include this in the tutorial, but it is not required for the standard.  Thus we dispense with BTERMs, (just have a Sig rather than a BSIG) and annotate arcs by

- A : F --> TERM(O \cup V) such that for all (p,t), (t',p) \in F,
for all bindings \alpha, Val_\alpha(A(p,t)), Val_\alpha(A(t',p)) \in \mu Type(p)

This is then more elegant than the previous definition.
>
>  A.3.5 Assignment and Evaluation
>
>  For a multiset signature BSIG = (S,O), some variable set V for BSIG and
>  a BSIG-Algebra H = (A, F) an assignment is a mapping
>  \alpha: V --> A such that \alpha(v) \in A_z for v \in V_z.
>
>  An assignment \alpha can be extended to terms
>  Val_{\alpha}: TERM(BSIG,V) --> A  by the following inductive definition:
>
>     * for o \in O_z: Val_{\alpha}(o) = f_{o}
>
>     * for v \in V_z: Val_{\alpha}(v) = \alpha(v)
>
>     * for z_1...z_n z_{n+1}\in B(S) and o \in O_{z_1...z_n}and
>       e_i \in TERM(BSIG,V)_{z_i}for i=1, ..., n:
>            Val_{\alpha}(o(e_1, ..., e_n)) = 
>              f_o(Val_{\alpha}(e_1),...,Val_{\alpha}(e_n)).
>
>  Val_{\alpha}is called the evaluation function corresponding to \alpha
>
>  For the empty set of variables, there is a unique assignment
>  \alpha : \emptyset --> A.  The evaluation Val_{\alpha}corresponding to
>  this unique assignment is simply called evaluation and denoted by eval.
>
>This finishes the changes (resp. the new text) in the Appendix (A.3). Now,
>BTERMS(O \cup V)_s can be consistently replaced by TERM(BSIG,V)_{b(s)}
>throughout the current text of the standard.

OK - so at the syntactic level, terms of TERM(BSIG,V)_{b(s)}annotate arcs, and hence will be appropriately evaluated as multisets. This leaves the problem of 'subsorts'. We may want a mixture of terms of different sorts, that may still evaluate to a multiset over the place type. eg consider a place p of sort Nat, and two more sorts int4 and int5, that map to two carriers {1,2,3,4}, and {1,2,3,4,5}, and variables associated with all these sorts. We may want to write x_Nat + x_int4 + x_int5 on the arc, and evaluate it as a multiset over the naturals. As I understand it, your BSIG does not allow this. However, it is no problem in the concrete version, as this term would be allowed, because it evaluates correctly. 

(Note that in the evaluation of such a term, each of the variables must be evaluated as a 'singleton' multiset - by convention, and this needs to be included in the definitions. ie
because of history, we would like to be able to write x on an arc, rather than 1'x on the arc (where x:Type(p)), but interpret it as 1'x. That is: if we evaluate an arc expression and find that we return an element of Type(p), then we assume that it should be converted to a singleton multiset over Type(p).)

>Now, the user is free to define own operations on the multiset level.
>
>
Always has been, as you have nicely illustrated, which allows us to eliminate BTERMs (from the concrete definition).

>III. Further Comments
>---------------------
>
>In this part, we reply on the individual comments in the Draft
>Disposition Report in the order mentioned.
>
>
>AUS01--AUS08 okay
>
>DAN1--DAN3 okay
>
>DIN1: see above I and II.1
OK - see comments above
>
>DIN2: see above II.2
See Editor's comment in draft disposition, and the above comments.
>
>DIN3--DIN4: okay
>
>DIN5, DIN13, DIN15, DIN20, DIN22:
>      Here, some words of explanation are due:
>
>      Substitution is an operation on terms.  In given term, some variables
>      are replaced by a term of appropriate sort.  The result of
>      a substitution is a term again.  In particular, substitution
>      returns a syntactical object (a term).
>
Understood (see draft disposition)
>      An evaluation of a term returns the value of the term in a given state
>      or under a given assignment.  The result is semantical (a value of the
>      corresponding algebra).  A formal definition for evaluations in our
>      context was given in II.2 (A.3.5) above.

Understood
>
>      I have had a look in different text books on computer science; and
>      this terminology seems to be standard.
>
Which ones? I guess there is a general understanding of substitution of values for variables used in the anglo-saxon world, so there may be some cultural differnces here.

>      In the current version of the high-level standard, there seems to be
>      no need for the concept of substitutions at all.  There
>      is no need to define an evaluation via a substitution and reduction to
>      a simplest form.  Rather, the use of this concepts induces problems:
>        * What is the simplest form?  It is know that in general simplest
>          forms (normal forms) do not exist (e.g. we cannot say whether
>          1'a + 1'b is simpler than 1'b + 1'a).

OK - perhaps this is a bit loose - but you know what I mean from the example in the disposition of DIN 13. Perhaps one should say something like - 'gather like terms together' in 3.1.24.2, as this operation certainly occurs. Do you have some better words?
>
>        * What is reduction?
>
>        * Reduction according to which rules?
>
>      If we use the concept of evaluations only, there is no problem.  
>      

>DIN6--DIN7: okay
>
>DIN8: In algebraic specifications (without polymorphism), it is always taken
>      care that a SIG-Algebra has as many domains as there are sorts in
>      the signature.  
Why do we need to here?

>Of course, it may happen that two different sorts are
>      associated with the same mathematical domain e.g. Nat as well as Agents
>      are associated with the natural number.  If the domains are considered
>      to be a set of sets, this set will have less sets than sorts (because
>      two sets are identical).
>
Yes - I dont see any problem. What is the problem?
>      In order to cope with this problems there are two possibilities:
>       * The domains are presented as a list of sets (where multiple 
>occurrence
>         is allowed);  this approach is often taken in books on algebras.
>       * In the context of algebraic specifications, the domains are 
>presented
>         as a family of sets (or as S-indexed set).
>
>      The main point was, that the concept of algebras as used in the
>      standard nicely fits to the literature and other standards in the field
>      of algebraic specifications and mathematical logic.

We should use economy of definition where we can. Currently I dont see the need for a more complex definition - just following books for their sake I dont see as a virtue - but I have probably missed something here - please let me know what the technical problem is.
>
>DIN9--DIN12: okay
>
>DIN13: see DIN5
>
>DIN14: okay
>
>DIN15: see DIN5
>
>DIN16--DIN17: okay
>
>DIN18: The standard should be as unambiguous as possible. I do agree that
>       there is no ambiguity due to the conventions.  But some people might
>       read an expression M - P + P' as M - (P + P');  the reason is that P
>       and P' are similar to each other and different quite from M, such that
>       the usual conventions are overruled in their minds.  Therefore,
>       additional parentheses would be helpful (and do no harm):
> 
>          M' = (M - Pre(...) ) + Post(...)
>
Would M' = M + Post() - Pre()
be acceptable - it doesn't require parenthesis, which add to clutter.
>DIN19: okay
>
>DIN20: see DIN5
>
>DIN21: okay
>DIN22: see DIN5
>
>DIN23--DIN24:
>
>DIN25, DIN26: see DIN1
>
>DIN27--DIN28: okay
>
>DIN29: see DIN18
>
>DIN30: see DIN1
>
>DIN31--DIN35: okay
>
>DIN36: Similar to DIN8, the separation of variables from signatures is
>       common sense in algebraic specifications.  The reason is that
>       the same signature is often used with different variables--and the
>       whole machinery (SIG-morphism and algebra-morphisms etc.) works
>       without variables.
>
>       But even in algebraic high-level nets, this separation is adopted.
>       For example K. Schmidt (see I.) uses one signature for the net, but
>       the variables are locally defined for each transition.
>
>       Maybe, this is a matter of taste.  But why not using the concepts
>       in the same way as in the field of algebraic specifications?
Thanks for the example above (II.2). I shall look into this one.
>
>DIN37--DIN39: okay
>
>DIN40: The statement that the domains for sorts Nat and Bool should 
>correspond
>       to N and Boolean in the algebra is there, indeed.  But it is in the
>       syntactical part, where algebras do not occur.  The appropriate place
>       would be in A.3.5.
It seems quite natural to me where it is - perhaps there should be a forward reference to A.3.5. What do others think? However, this needs to be revised in the light of just using terms rather than BTERMs. It seems that only a Boolean Signature is required.

>DIN41-DIN44: okay
>
>JPN001--JPN0014: okay
>
>UK1E--UK11: okay
>
>USA1--USA4: okay