FW: error resolution assistance needed

Tue Jan 21 05:07:23 EST 2003

Phil,

if this is the agreement in WG11, fine with me. Then we need to change (or
at least: clarify) rule a) in 9.2.3.4 which currently says:
"a) The attribute redeclared in the subtype shall be a specialization of the
attribute of the same
name in the supertype."

Nontheless, 9.2.3.4 needs some additional text as pointed out in FR-8
explaining the renaming mechanism.

If there are no protests against this view, I will edit P11e2 accordingly.

Regards, Jochen.
____________________________________________________________
Jochen Haenisch			E-mail: Jochen.Haenisch at epmtech.jotne.com
EPM Technology AS		Home of the EXPRESS Data Manager
P.O Box 6629 Etterstad		Tel: Int + 47 23 17 17 26; mobile: Int + 47
922 60 274
N-0607 Oslo				Fax: Int + 47 23 17 17 01  
Norway					Web:  http://www.epmtech.jotne.com

> -----Original Message-----
> From:	Phil Spiby [SMTP:Phil.Spiby at Eurostep.com]
> Sent:	21. januar 2003 11:01
> To:	'Jochen Haenisch'; 'Hendrix, Thomas E'
> Cc:	'Tim King'; 'Ed'; 'Arne Tøn'
> Subject:	RE: FW: error resolution assistance needed
> 
> Jochen,
> 
> If renaming without specialization is not in the document then it should
> be!
> The re-declaration mechanism is to allow 
>  - making optional attributes mandatory
>  - making explicit attributes derived
>  - constraining the type to a specialisation
> And now in Ed2
>  - to rename an attribute
> 
> There is, and should be, no statements that redeclaration is forced to
> include specialisation!
> 
> Phil
> 
> PS I also haven't looked at the EXPRESS or the rest of this thread yet,
> but
> wanted to state my 
> Understanding on what is written.
> 
> > -----Original Message-----
> > From: Jochen Haenisch [mailto:Jochen.Haenisch at epmtech.jotne.com] 
> > Sent: 20 January 2003 19:00
> > To: 'Hendrix, Thomas E'
> > Cc: 'Tim King'; 'Phil Spiby'; 'Ed'; Arne Tøn
> > Subject: RE: FW: error resolution assistance needed
> > 
> > 
> > Hei Tom,
> > 
> > we can probably get into a lengthy discussion with this. So, 
> > Tim may rightaway choose a less controversial way of 
> > representing his requirement ... if the completion of the 
> > schema has some time constraints on it.
> > 
> > I do not agree that P11e2 allows renaming without 
> > redeclaration. And redeclaration requires a specialization. 
> > The entire clause 9.2.3.4 is about redeclaration; and RENAMED 
> > appears only in this clause. I have no idea why there is no 
> > simple renaming, but as WG11 decisions currently stand, I can 
> > not see that this is possible.
> > 
> > The agreed ballot comment resolutions for P11e2 are attached. 
> > Most of them are yet not incorporated into the final document 
> > ... . FR-8, which was rejected, relates probably to this 
> > case. Have a look.
> > 
> > Best regards, Jochen.
> > P.S.: I have not checked your Express - I anticipate that 
> > there is no specialization involved.
> > 
> >  <<ISO_10303-11_1994_DAM_all_comments.doc>> 
> > ____________________________________________________________
> > Jochen Haenisch			E-mail: 
> > Jochen.Haenisch at epmtech.jotne.com
> > EPM Technology AS		Home of the EXPRESS Data Manager
> > P.O Box 6629 Etterstad		Tel: Int + 47 23 17 17 
> > 26; mobile: Int + 47
> > 922 60 274
> > N-0607 Oslo				Fax: Int + 47 23 17 17 01  
> > Norway					Web:  
> > http://www.epmtech.jotne.com
> > 
> > > -----Original Message-----
> > > From:	Hendrix, Thomas E [SMTP:thomas.e.hendrix at boeing.com]
> > > Sent:	20. januar 2003 19:42
> > > To:	Jochen Haenisch (E-mail)
> > > Subject:	FW: FW: error resolution assistance needed
> > > 
> > > Hei Jochen
> > > 
> > > Tim King is getting this error from one of the PLCS ARM 
> > compilations.
> > > 
> > > ERROR  : Line   762: Illegal attribute redeclaration.
> > >          Redeclaring attribute: CONDITION_ASSERTION.VALUE_CONTEXT 
> > > RENAMED OBJECT_EVALUATED in line: 762
> > >          Redeclared  attribute: VALUE_RECORD.VALUE_CONTEXT 
> > in line: 1064
> > >          Redeclaration is no specialisation, only renaming
> > > 
> > > from this EXPRESS
> > > 
> > >    757 ENTITY Condition_assertion
> > >    758   SUBTYPE OF (Evaluation_record);
> > >    759   SELF\Value_record.value_recorded RENAMED assertion :
> > > Logical_assertion;
> > >    760   SELF\Value_record.expression_evaluated RENAMED condition :
> > > Condition;
> > >    761   SELF\Value_record.value_context RENAMED object_evaluated :
> > > OPTIONAL Entity_instance_reference;
> > >    762 END_ENTITY;
> > > 
> > > (see attachment for entire report)
> > > 
> > > After reading Ed Barkeyers's reply to my note to wg11 
> > (below), I think 
> > > I will claim that the compiler should permit this. What do 
> > you think?
> > > 
> > > 
> > > -----Original Message-----
> > > From: Ed Barkmeyer [mailto:edbark at nist.gov]
> > > Sent: Wednesday, January 15, 2003 9:52 AM
> > > To: Hendrix, Thomas E
> > > Cc: SC4 WG11
> > > Subject: Re: FW: error resolution assistance needed
> > > 
> > > 
> > > Thomas Hendrix wrote:
> > > > 10303-11:1994 and its DAM 1 , 9.2.3.4
> > > > 
> > > > "Rules and restrictions:  a)" seems to disallow the use of RENAME
> > >  > for attribute redeclaration unless the renamed attribute is  > 
> > > constrained by an additional change. Is this the intent?  > If so, 
> > > propose relaxing this restriction.
> > > 
> > > This is really a subtle point:  rule (a) requires a 
> > "redeclaration" in
> > > the full syntax thereof, but it is nowhere stated that a 
> > "redeclaration" 
> > > must actually constrain the data type of the attribute!
> > > 
> > > The purpose of redeclaration (before, and therefore other than, 
> > > RENAME)
> > > was to constrain the type, and there was formerly no reason 
> > to have a 
> > > redeclaration that does not further constrain the type.  But a 
> > > redeclaration of an attribute that declares it to be of exactly the 
> > > original type appears to meet all the requirements for a valid 
> > > redeclaration.
> > > 
> > > OTOH, it does seem that a simpler syntax for changing only the name
> > > would be useful.
> > > 
> > > -Ed
> > > 
> > > -- 
> > > Edward J. Barkmeyer                       Email: edbark at nist.gov
> > > National Institute of Standards & Technology
> > > Manufacturing Systems Integration Division
> > > 100 Bureau Drive, Mail Stop 8260          Tel: +1 301-975-3528
> > > Gaithersburg, MD 20899-8260               FAX: +1 301-975-4694
> > > 
> > > "The opinions expressed above do not reflect consensus of NIST, and 
> > > have not been reviewed by any Government authority."  << File: 
> > > arm_2003118v1_errors.zip >>
> > 