|
Meeting
27 Minutes
1.
Call to order
Meeting
was called to order at 09:06 PST/17:06 GMT. Please
remember to send in your e-mail to 2.
Approval of minutes from meeting 26
First
order of business is approval of the minutes from meeting 26. 3.
Status Update
1647-2007
donations Andy:
There are 6 documents that have been donated and are currently under
review for
the next LRM (1647-2008). 1.
Name Spaces.
This will be annex C of the language reference
manual.
That was put out for review a number of weeks back and I have received
a fair
amount of feedback from a number of reviewers which I appreciate the
rapid
turnaround as well as the willingness to take a look at the material.
There are no serious issues have come up yet really in name
spaces. In a
moment we’ll discuss using the issue tracking system, we’d like to
start recording each of the things that we do find even minor
corrections in
the issue tracking so that Joe can capture the changes and any
discussions that
take place can be recorded there and then we can resolve them and check
them
off. 2.
Encapsulation.
This will be chapter 22. I’ve also received a lot of good feedback,
again no technical issues perse, although there are a couple of
questions which
will require some discussion between Matan, myself and Joe, but those
two
documents look to be in pretty good shape at this point. The
feedback
from this has not gone into the issue tracking system yet although I’ll
raise those entries myself or get back to the individuals and reviewers
to,
once we make a change to the issue tracking system, to add those into
the
system. 3.
Method
Ports. This is still in internal review, since we have Matan
on the line, Matan are you aware that Joe and I had sent you some
questions,
some weeks back regarding method ports and if you’d had a chance to
read
those yet? Matan: I did mail back my replies although not
quickly, a little late but I’ll resend it. Actually I’m not
the expert on method ports so I answered off my head but … do you still
have Yaron? active in the workgroup?? Andy : He hasn’t joined the past couple of
meetings … Yaron [Kashai], do you remember when Yaron was last in
?? Yaron Kashai: which Yaron? Matan: Yaron Pitzol Yaron: Oh Yaron – no he hasn’t for a long
while I think mid last year was the last time he joined. We could
recruit
him though – ask him to drop by and tell him we’d like him to take
a look, I suppose he will do it if we just ask him
nicely. Andy: Why don’t Matan, you and I and Joe can
meet up later today or tomorrow then, I’ll go back and check my
messages,
we may have misplaced that in all the recent changes. So message
ports
status really is that theres still some internal discussion going on
among the
group. So message ports is still in internal review. 4.
Messaging. The draft material was recently completed by Matan, I
appreciate all the work he invested in that taking a large, 54 page
product
specification, something that came out of a product and condensed it
down into
the syntax and semantics we need to become part of the ERM. It’s
now 11 pages, I’ve reviewed that, I think that Joe have you reviewed it
at this point also or are you in the middle of that at this point??
Joe: I’ve initially reviewed it Andy: Okay so we’ll be providing some feedback
to Matan, my initial take on it is that its very clean and will be soon
ready
for changing into a section of the reference manual. Joe: My official position is that the draft I want to
start with is with most of the examples gone to make it more IEEE
compliant. Andy: Exactly 5.
Sequences. Under development by Joe. There was a
little delay that was introduced with some administrative snags, that’s
now been taken care of and we’re proceeding to complete the first
draft. 6.
Reflection
API. Initial
Document is still
being finalised and I’ll be working with Cadence to release the
copyrights for the IEEE so that they become an official donation. Joe: If I understand correctly …
Andy: That is correct, right we’ll talk in a
moment about the review schedule. Are there any questions on just the
state
right now of the six items that are going into the 2007 draft? Matan: One question, I don’t know if you want
to take it but Joe said that we would want to take all of the examples
out of
the messaging draft and I remember that we did leave a very few
examples but we
thought in first version that they were helpful – do you think it wise
to
remove all of them? Might help the understandability of this very
bare
format for submissions. Andy: I’m going to ask Joe to comment on this
in a moment but my initial take Matan, is that what we’d like to
capture is the Front matter and main body of the chapter bodies
that
simply define the language itself and the constructs and the semantics
of those
constructs. And that where necessary if its useful to have
examples, that
they are traditionally relegated to an annex section that can be
referred to
but are typically not inserted inline. Joe – do you want to
elaborate on that a little more?? Joe: What I’d really like to do here Matan is
to, and you got to see me do it with the last version, is to have
an annex for an example and so really be more code centred.
I agree
with you that messaging on itself is not as easy to understand without
the
examples. What I’d really like to do is in the appendix have, in
a
hosted website a series of examples and then I can have a posted
reference from
the actual messages clause to those examples, it’s cleaner,
ultimately that’s the way to go. The reality is that in most cases with
most standards is that someone comes along and writes a how-to book and
it’s the how-to book that actually has the examples. I’m not
sure, I know you’ve pared down a lot the examples I’m not sure that
its going to be none of them exist of just one or two of them exist,
and
that’s part of me going through it again more formally, I’ve
skimmed it twice and I really appreciate that you did the work of
triaging in
the first place. I’m also going to defer slightly to Yaron and
see
if he has any opinions on this as well. Andy: One thing that is useful with the way that the
draft is currently written, is he has one example, a small example and
then he
uses it to illustrate various constructs of messaging and that is a
useful flow
that differs quite a bit from simply throwing lots of code that try to
illustrate the use of, for example, messaging within the body of a
verification
environment. Joe: Maybe this is where we do need to make an
exception and say that we do need a slightly more elaborate example
here.
But what I want to avoid, and this is the fine line, is in saying that
we do
that with all the other clauses as well. Because in almost all
cases an example
will help but in almost all cases multiple examples, will be frowned
upon by
the IEEE and could slow down the approval process. Andy: Because you can end up in those examples with
inferred requirements on the part of an implementer that are not
intended. Joe: Yes – lets play with that one a little bit
– this is my first impression. You’ve put in much more time
than I have currently. Andy: Yaron – did you have any opinions on the
extent to which examples are employed within the ERM? Yaron: The only experience we had was that the fewer
examples the better off we are in terms of passing things through the
IEEE
process. I think people from the programming side are always trying to
make the
standard more accessible but ths is really not the intention, that’s
not
what it is about. Trust Joe to do the right pruning even if that
means
that the standard becomes more ambiguous or more not ambiguous but more
cryptic. Andy: It can be somewhat drier, I think this is
probably what Matan’s concern is Mac: The purpose of examples is to remove ambiguity,
and the right way to remove ambiguity is to make the words tighter -
the BNF
and so on. Sometimes you can’t do that so you use an example but
the wrong use for examples is to be a teaching guide. Andy:? Where we end up replacing what should be
explicit syntax with elaborate semantics. Mac: The problem with the teaching guide is that you
end up with your examples is not precise and brings in these other
questions
and then you have to get the editors not to screw it up when they’re
formatting it so theres lots of work to make sure an example makes it
through
but the purpose for having an example in an LRM is to remove
ambiguity.
If you have some other desire then its wrong place. Andy: What we need to look for as we remove any examples
that were in the original material with messaging, if they’re
illustrating usage that is not explicitly explained and the textural
description on the construct or how the construct is used or the way
the
construct behaves then we need to perhaps make substitutions where you
will
place an example with some elaborated text. Joe: Lets look at this another way. Heres the
impossible dream, the impossible dream is the standard is perfect, no
examples
are required. The reality is that we need to show code in places
when its
for a conceptual thing messaging – yes we would need a more elaborate
example than we would, say just for name spaces. I’ll have a look
at that with Matan. Yaron you’ll get to see a copy of that before it
goes
out to the workgroup and if it really is that it doesn’t work then
we’ll take it from there. Unfortunately I’ve been delayed
because of paperwork issues. Andy: Sounds good Name Spaces and encapsulation Andy:
The Issue tracking system only has the old version choices when you
open a new
issue for the 1647-2008 LRM (e.g. "Draft 0.5" and "Draft 0.6") which
were from
the previous LRM. So I’m going to be adding choices to there
tomorrow that are applicable to the version we’re working
on.
I’m inclined to use numbers like 1.something. Yaron did you have
any advice on how to go there, I don’t want to reuse version no’s
because we could introduce ambiguity in terms of the issues we already
have
recorded in the system. Yaron:
Definitely we don’t want that but generally there is no restriction so
as
long as there is some coherent numbering then that’s fine. Andy:
I’ll be adding those, for now as you the working group review the
documents and open issues just leave the version numbers blank at the
time
being and after I add the version choices I’ll back annotate those into
the issues themselves. Forecast Review Schedule/ Editor Andy:
Unfortunately we’ve slipped about a month, because we wanted to have
name
spaces and encapsulation reviewed by the end of January it looks more
like
we’ll be closing at the end of February. So that pushes each of
the
subsequent things sequences, method ports, messaging and reflection
back a
little bit also. I think we can still release the draft LRM in
the early
to mid June timeframe. That’s my plan at this point, it seems that
around
the DAC timeframe that the status update could be distributed at the
time of
the conference. Joe, does that seem unreasonable to you?
Joe: What
I’m looking at is again name spaces, encapsulation in February/March,
sequences and method ports in April, messaging could be in March and
reflection
could be in the April timeframe, which gives us all of may for
iteration and
document feedback. Joe:
My belief is the sequence for the remaining four is probably ports then
messages then sequences and reflection API will be last, that one for
sure
won’t be until April. I do think when ports gets a heads up from
everyone what it really is, is the e ports with the addition of method
ports so
its an additional roughly 8 pages of material. Encapsulation for
those of
you who have looked at it is an additional 8 pages of material whereas
when we
get into messages and sequences, its totally new material, it’ll be
about
30 pages of new text and reflection API I’m sorry I don’t really
know how big that one really is. Andy:
Its 10 pages Joe:
The overall hope here for the working group is that, as these things
come out,
they turn around within a month or so. Now I recognize that with those
messages
and sequences they make take a little bit more time and the idea is to
go into DAC
with the feeling that we’re in the last review if not done with it and
in
the pre ballot stage. Andy:
As you have the floor Mr Editor is there anything else you’d like to
add? Joe:
No – just that folks understand the idea here is similar to a couple of
years ago that we’re trying to do a bigger push in the first half of
the
year, recognizing that there’s going to be downtime because of both,
hopefully a ballot stage and holidays in the summer. So people can
schedule the
year accordingly, undoubtedly there’ll be new comments and updates in
the
Autumn. Andy:
Any questions re where we are at this point in time ?? Joe:
One other heads up you know we’re talking about a 2008 standard My hope
is that the reality of the ballot review in the Autumn and go through
the IEEE
process before end of year, therefore that’s why it will not be
published
until 2008, but the workgroup should be done by the end of 2007. Andy:
That’s a good point 2008 doesn’t indicate anything other than the
final signoff from the IEEE will take place. 4.
Other Business
Results of
the Face to Face meeting
Survey Andy: I
didn’t get a lot of
feedback by the way 6 people voted, 4 preferred Darren
Galpin: We don’t
know as its quite close to DAC so it might be one or the other,
we
don’t know yet. Joe:
Okay. What about US
attendees on the call? Mac: I’ll
probably be at the
DATE conference. Andy: Any
other ideas or suggestions
on a face-to-face in the April timeframe? Joe: Allow
people the chance if they
might make it can never make it etc. Andy: I’ll
try to phrase the
next message in such a fashion that it is more open-ended Joe: Offer
two options – the
time and date you can make it and also … pre ballot Summary:
April will be better than
March because four documents will have been reviewed by this time.
Andy
will ask individual members what April dates are best and at what
locations. 5.
Patent policy
The chair has issued a call for essential patents, in
compliance with current
IEEE/SA PatCom guidelines. The
WG members
are advised to review the call for essential patents and the patent
related
slide presentation
posted on
the web site. 6.
Next meeting
We are
bound by the 30 days notice requirement. Andy tentatively
suggested
Monday March 12th at 09:00 PST/17:00 GMT. The date may
change
according to circumstances. The review process will proceed
through
email. 7.
Adjourn
Andrew moved
to approve adjourning the meeting,
seconded. |
| IEEE/SA home IEEE Standards Association |
DASC Home Design Automation Standards Committee |
VLSG Home Verification Language Study Group |
The
1647 PAR Project Authorization Form |
(Updated Thu Feb 22 14:03:03 PST 2007)