RE: [plcs-tog] Issue Resolution Request # 1

["Rob Bodington" <rob.bodington@eurostep.com>]

Hi
I would like to state the Eurostep position on this based on
consultation with people who have developed some of the templates,
people who are reading the templates, and also people who are using them
for implementing software i.e. the target audience. 
Some of the implementers were not familiar with PLCS.
Not all of those asked where Eurosteppers

We very strongly believe that we should do everything necessary to make
the templates as understandable as possible. We also believe that we
need to get the templates published as soon as possible to help people
deploy PLCS.

To this aim we think that it is absolutely essential that some related
and relevant entities are shown in a template as this will explain why
and how the template is to be used. Yes, the information can and should
be shown in the capability, but that does not mean that it should not be
shown in the template as well.

A good example is representing_activity_actual 
http://www.plcs-resources.org/plcs/dexlib/data/templates/representing_
activity_actual/sys/section.htm#model_diagrams
 
The proposal would remove Activity_happening from the diagram. In other
words the template would not show that an Activity_actual can be related
to a planned activity. Therefore not showing an essential part of how
the template can be used.
 
In order to avoid confusion - the extraneous entities should be kept to
a minimum and should be clearly marked as not being instantiated by the
template.
 
A final comment is that this change will have a MAJOR IMPACT on the
existing templates as we would have to go through virtually all the
templates that we have written modifying them. 

Regards
Rob

> -----Original Message-----
> From: tai@sfk.mil.no [mailto:tai@sfk.mil.no]
> Sent: 12 June 2007 16:16
> To: plcs-tog@lists.oasis-open.org
> Cc: tai@sfk.mil.no
> Subject: [plcs-tog] Issue Resolution Request # 1
> 
> Issue Resolution Request no.:	1
> Issue type:	Check list issue
> 
> Attached is the documentation on Issue Resolution Request # 1.
> There are two positions in this case:
> 1.	Keep the templates as small as possible by only showing what is
in
> scope and hence will be instantiated by the template.
> 2.	Show the template with entities within scope as well as entities
> related to its scope. Hence show more than what will be instantiated
by
> the template.
> 
> Effect of the decision on work already performed will in both cases be
> that templates will have to be adjusted. Either by removing or adding
> stuff from each template. In the case of adding this clearly must be
> corrected straight away. In the case of removing the urgency is not as
> great  provided each template is provided with a note to disregard the
> greyed areas.
> 
> When deciding we should keep in mind what will serve the intended user
of
> the templates best as well as avoiding overlapping documentation with
> possible inconsistency as a result. Possible inconsistency will be a
> bigger problem in the case of manual generation of documentation.
> 
> 
> The TOG Chair recommends the following approach:
> 
> 
> Each member of the TOG is invited to forward his/her point of view to
the
> TOG via the mail exploder.
> After 5 working days, the TOG holds a Telecon on the issue.
> 
> 
> 
> Best regards
> 
> Tor Arne Irgens
> TOG Chair