Reply to Comments on Draft Petri net
Standard V2.1
Date: Thu, 14 Aug 1997 19:04:51 +0930
To: Kurt Jensen <kjensen at daimi dot aau dot dk>
From: Jonathan Billington <j dot billington at unisa dot edu dot au>
Subject: Re: Petri Net standardisation
Dear Kurt,
At last my reply to your comments!
Firstly - many thanks for them, as they help to clarify issues.
My reply follows each of your comments.
Best wishes
Jonathan
>Comments to the Working Draft 18 February, 1997, Version 2.1 of the
>High-level Petri Net Standard.
>
>
>MAJOR COMMENTS
>
>p.1, li -8: WE think it is far too early to think about standardisation of
>OO concepts for Petri nets.
that is OK - it is scheduled for a third part, which may only include
hierarchies - it depends on the contributions to the work - this is a
little way off - and maybe by that time the OO situation will become
clearer - otherwise it may just be the hierarchies that we standardise -
there seems to pressure for hierarchies in the UK.
Are you happy with the structure of Parts - it seems to me the most
sensible way to proceed.
>
>p 11, li 5: Why do we need multisets of terms. What we really need is a
>term which can evaluate to a multiset -- and that is something slightly
>different. It is in my view very important that it is legal to have an arc
>expression (or a function in an arc expression) which can evaluate to
>multisets. Without this capability a lot of practical models become much
>more clumsy.
No problem. You can set up terms to evaluate to multisets. You just need
the appropriate multiset carrier in the algebra. ie the sort of the term
(which may be a variable or a function or more complex) on the arc, maps to
a multiset in the algebra. I used this mechanism in my thesis for reset
arcs and purging - but I only needed variables there.
We need multisets of terms to provide for the usual syntax (eg x+3y) used
on arcs and allow for conditionals in arc expressions (see figure 2). This
is discussed in note 3 on p21. We need there to be natural number terms for
the multiplicities of terms in the multiset of terms on the arcs. Then a
particular term may have its multiplicity evaluated to zero, and hence be
eliminated - see example in figure 2. Multisets of terms allows for this
syntax. If there is a simpler way of doing it, I would be pleased to know
about it.
>
>p. 13, upper part: As before we think it is important to allow functions
>which map into multisets. It is not clear to us that the present
>formalisation allows this.
>
It does - see above - you need a multiset for the co-domain. As a multiset
can be represented as a set (of ordered pairs, the second being the
multiplicity) there is no problem as the multiset (set of ordered pairs)
just becomes a carrier in the algebra.
>p. 18, lower part: We don't understand why you introduce a new notation
>for multi-sets. We think {(1,1),(2,0),(3,2),(4,0)} is difficult to read
>(and totally unnecessary. Why not stick to 1 + 2(3), or even 1'1+2'3, which
>we prefer.
This is done because it is standard set notation. (It shows you how a
multiset is represented as a set.) If you like, it defines the 1 + 2(3)
notation, in terms of standard mathematics via section 4.2's definition of
a multiset. This is providing an example for 4.2.
>
>p. 21, bottom: Again functions into multisets should be mentioned. They
>are, in my view, extremely important
I think this is answered above - if not let me know.
>
>p. 23, li 9-10: We propose to remove the remark about ambiguity of
>association of arc annotations. The mechanism for this is very tool
>dependent. Moreover, it is a much larger problem, to distinguish e.g.
>between place name, place type and initial marking
The standard is just saying that a mechanism must be provided to avoid
ambiguity. This is very important for the standard. Nothing else is
mandated. It is important that tool developers make sure that such
ambiguity is avoided. Hence to conform to the standard you must incorporate
this mechanism into your tool or diagram. Maybe we should add that any
ambiguity between a place's name and its type name should also be avoided,
but I think this is more obvious.
Hence I would retain this statement as essential.
>
>p. 23, middle: We propose to remove the drawing of the transition, since
>it implies that conditions are written inside transitions while the name is
>written outside. This is not consistent with current practice, where the
>name often is written inside the transition, while the condition is written
>outside.
>
I believe it is hard to know what 'current practice' is. There is no doubt
that Design/CPN uses the conventions you state above, but Predicate
Transition nets have often placed transition conditions inside transitions.
The standard does not mandate any convention here. It just again says that
the association of the annotations with the transition must be clear and
not ambiguous. Thus the conventions adopted by Design/CPN are catered for.
I think it is good to give an example. Hence I would retain it. I could add
some text stating that this is only an example, and that other conventions
would conform, but I think the last sentence of 8.3 already says this.
>p. 24, section 8.5 (and the last two lines of p. 23). We propose to remove
>this section all together. The user of angular brackets cannot be done
>consistently, since we may have functions mapping into multisets (should
>they be in brackets or not). Moreover, we do not prescribe a standard for
>the inscription language. Then it strange (and totally unnecessary) to
>prescribe a standard for multiset notation.
>
We need a way of distinguishing between multiplicities and terms as 2(1) is
different from 21, and we would like to be able to write 21 instead of
1(21). Hence we do need some notation for this. My approach has been to try
to use standard mathematical notation wherever possible. Thus for tuples I
much prefer (a,b,c) rather than <a,b,c>, as parenthesis are normally used
in this context (as far as I am aware). My proposal would be to eliminate
the use of angular brackets all together, and use parenthesis to
disambiguate where necessary.
A term itself can evaluate to a multiset. That doesn't mean that the term
has to be in angular brackets or parentheses. We just use parentheses to
disambiguate when necessary. This will require some changes to the last
paragraph of 8.4, and also to 8.5 which I shall do in the revised version.
An example.
We can have an expression on an arc such as 3x+2y+4(1), where the colour
set of the associated place is A, a multiset over A is denoted A[ms], and
we have
x:A[ms] and y:A. Say A={1,2,3}, x evaluates to 1+2(2)+3, y evaluates to 3,
and 1 evaluates to 1, then Val(3x+2y+4(1)) = 3(1+2(2)+3) + 2(3) + 4(1) =
7(1)+6(2)+5(3).
We must be able to make the distinctions between multiplicities and terms,
and multiplicities and values. Use of parentheses is the usual way to do
this.
>
>MINOR COMMENTS
>
>p2. l -10: We are not at all sure that a mathematically based concrete
>syntax would be a help. It would probably more be a burden.
>
Noted.
The basic syntax should be neutral to the various inscription languages -
hence use standard mathematical notation as much as possible.
>p.7, middle: Perhaps you should indent "input arc" and "output arc", or
>make they plain (instead of bold). With the current typography it is
>difficult to see that these paragraphs are subparagraphs of Arc.
Yes - I shall use the conventions specified by ISO for this.
>
>p. 9 li 5: arcs involving the transition --> the surrounding arcs
>
Yes - OK - will change
>p.9 li -7: We do not think you use Z for anything, hence it can be omitted
>
It is used in figure 1, hence retain.
>p.9 li -1: unity --> one
OK
>
>p 10, middle: In 4.2.3. We would omit the mathematical expression. It is
>not necessary for the understanding, and it is a bit problematic since Ø is
>polymorphic and hence independent of A (which is undefined).
I take your point, but given A is generic, does it matter?
>
>p. 16, li 5: These are sets ---> These are non-empty sets.
Yes - accepted.
>
>p. 18, figure. The arrow heads in the figure should be larger (if you want
>to show people how a nice high-level graph looks.
Yes - probably - but I am using LaTeX picture mode here which automatically
decides on the size - I guess Lamport must have thought it looked nice.
>
>p.19, middle: It is not clear to us what you mean by "outfix" notation.
>
Refering to fugure 2.
Standard notation would be (like f(x)), [](true) = 1.
Infix notation is often used for familiar functions such as addition, where
we replace the standard notation +(3,4) by 3 + 4. Infix because the
operator symbol is used 'in between' the arguments. Conversely if the
operator symbol [] (in this case} surrounds the argument (ie is outside),
it is called Outfix: [true] = 1, rather than [](true) = 1.
>p. 20, figure: Larger arrow heads. The two rightmost arc annotations would
>become more understandable, if they were written: if m=* then L else 1
(I am assuming *=e)
Yes - probably for those used to if then else statements. The syntax for
arc expressions does not provide for the key words if, then and else, and
hence we cant use this. This is part of an inscription language that we are
not going to specify. We can only use terms built out of constants,
variables and operator symbols (with arguments) - hence the notation used.