SEDS for ISO 10303-11

Jochen Haenisch Jochen.Haenisch at epmtech.jotne.com
Thu Nov 29 10:31:59 EST 2001 

David,

no! Changing the population within the aggregate would not change the
aggregate type. If the object that was assigned to the BAG parameter is a
SET, it will remain a SET even if you try to make an invalid change to its
elements.
By the way, I think that at least the union operator does not allow us to
add a duplicate element into a SET (which may be declared as a BAG, but be
populated with a SET) and, thus, make the SET invalid.

A good discussion - thank you and Ed, and Hans Karsten over here :-)

Regards, Jochen.

> -----Original Message-----
> From:	David Price [SMTP:david.price at eurostep.com]
> Sent:	29. november 2001 15:07
> To:	Jochen Haenisch
> Cc:	'WG11 exploder'; Hans Karsten Dahl
> Subject:	RE: SEDS for ISO 10303-11
> 
> Jochen,
> 
> Thanks, I think I understand the SEDS now. For any case where a variable
> has
> a declared type, assignments of a value of the variable to other variables
> or attributes shall maintain the original type so that TYPEOF can return
> the
> original type too.
> 
> A clarification question... given the BAG/SET example, if I add 2 as a new
> member of the x that has been assigned the SET [1,2,3] would you expect
> only
> BAG to be returned by TYPEOF? I assume so. That means it's more than just
> assignment that is affected. I think it means that the type of the
> assigned
> value must be maintained and then every operation that changes the value
> must check if the change causes a change in any of its types.
> 
> I imagine this adds complexity to implementations but as I said, I'll
> leave
> that issue to others.
> Cheers,
> David
> 
> > -----Original Message-----
> > From: Jochen Haenisch [mailto:Jochen.Haenisch at epmtech.jotne.com]
> > Sent: 2001 November 29 13:48
> > To: 'david.price at eurostep.com'
> > Cc: 'WG11 exploder'; Hans Karsten Dahl
> > Subject: RE: SEDS for ISO 10303-11
> >
> >
> > David,
> >
> > if TYPEOF is supposed to work like is_kind_of already - great.
> > Then we only
> > need to polish the describing text in the LRM. This is indeed what I
> hoped
> > for!
> >
> > NUMBER is only a special case for which TYPEOF also should return
> > the actual
> > type of the parameter value (not only the declared one).
> >
> > Same for aggregates, but only if they are really assigned a different
> type
> > of aggregate:
> >   LOCAL
> >     x : BAG OF INTEGER;
> >     y: SET OF INTEGER := [1,2,3];
> >   END_LOCAL;
> >   x := y;
> > In this case TYPEOF(x) should return ['SET', 'BAG'], not only ['BAG'].
> >
> > If you have:
> >   LOCAL
> >     y: BAG OF INTEGER := [1,2,3];
> >   END_LOCAL;
> > TYPEOF(x) should only return ['BAG'].
> >
> > The assignment is the point! Only then the program can really
> > trace the type
> > of an instance.
> >
> > I hope that makes my issue clearer?!?
> >
> > Regards, Jochen
> > > -----Original Message-----
> > > From:	David Price [SMTP:david.price at eurostep.com]
> > > Sent:	29. november 2001 14:28
> > > To:	Jochen Haenisch
> > > Cc:	'WG11 exploder'; Hans Karsten Dahl
> > > Subject:	RE: SEDS for ISO 10303-11
> > >
> > > Jochen,
> > >
> > > When you said it didn't apply to BAG and SET I assumed NUMBER
> > was the only
> > > case. The is_instance_of and is_kind_of only apply to entity
> instances,
> > > not
> > > simple data types, in SDAI so it's not quite the same thing. Actually,
> I
> > > think TYPEOF already works as you want in the case of entity
> > instances. It
> > > seems you are asking for simple types, but not aggregation types, to
> be
> > > treated the same as entity instances because you believe all data
> values
> > > will be represented as objects and therefore can maintain the
> > data type of
> > > whatever was most recently assigned. Is that right?
> > >
> > > Sorry to be a pain but I seem to be confused as to the extent of the
> > > request
> > > in this SEDS.
> > > Thanks,
> > > David
> > >
> > > > -----Original Message-----
> > > > From: Jochen Haenisch [mailto:Jochen.Haenisch at epmtech.jotne.com]
> > > > Sent: 2001 November 29 13:05
> > > > To: 'david.price at eurostep.com'
> > > > Cc: 'WG11 exploder'; Hans Karsten Dahl
> > > > Subject: RE: SEDS for ISO 10303-11
> > > >
> > > >
> > > > Daivd,
> > > >
> > > > yes, I do mean that this applies to more than NUMBER! Think of an
> > > example
> > > > with PERSON and subtypes MAN and WOMAN. That would make more sense.
> > > > If I am not mistaken, SDAI offers the required functionality in
> > > > is_instance_of/is_kind_of.
> > > >
> > > > Regards, Jochen.
> > > >
> > > > > -----Original Message-----
> > > > > From:	David Price [SMTP:david.price at eurostep.com]
> > > > > Sent:	29. november 2001 13:57
> > > > > To:	Jochen Haenisch
> > > > > Cc:	'WG11 exploder'; Hans Karsten Dahl
> > > > > Subject:	RE: SEDS for ISO 10303-11
> > > > >
> > > > > Hi Jochen,
> > > > >
> > > > > My two kroner...
> > > > >
> > > > > I do agree NUMBER is a strange datatype but I'm not sure that
> means
> > > the
> > > > > relationship between it and a specialiation of it should be
> treated
> > > > > differently OR do you mean for this to apply to more than NUMBER?
> > > > >
> > > > > > An implementation will nontheless keep track of the actual type
> of
> > > an
> > > > > > object. So, why not give the user the (necessary) possibility to
> > > > > > query this?
> > > > >
> > > > > I'm not sure it's a good idea to assume this for all
> > implementations.
> > > > > Functionally, NUMBER is treated like REAL in many of the 20s
> > > > series parts
> > > > > so
> > > > > implementations may lose the distinction. However, I've not
> > > implemented
> > > > > this
> > > > > myself so will leave that issue to others.
> > > > >
> > > > > Cheers,
> > > > > David
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jochen Haenisch [mailto:Jochen.Haenisch at epmtech.jotne.com]
> > > > > > Sent: 2001 November 29 12:24
> > > > > > To: 'david.price at eurostep.com'
> > > > > > Cc: 'WG11 exploder'; Hans Karsten Dahl
> > > > > > Subject: RE: SEDS for ISO 10303-11
> > > > > >
> > > > > >
> > > > > > David,
> > > > > >
> > > > > > no, the point is not to detect that a BAG is a SET based on the
> > > > > > characteristics of its population. This is beyond the limits,
> but
> > > not
> > > > > very
> > > > > > much. The point is to have a possibility to query which type of
> > > value
> > > > > has
> > > > > > intentionally been assigned to a parameter.
> > > > > >
> > > > > > Building on the previous example one could imagine the following
> > > > > > situation:
> > > > > >
> > > > > >  LOCAL
> > > > > >    x : NUMBER;
> > > > > >    y: REAL := 1.0;
> > > > > >    z: INTEGER := 2;
> > > > > >  END_LOCAL;
> > > > > >
> > > > > >  IF (...) THEN x:=y;
> > > > > >  ELSE x:=z;
> > > > > >  END_IF;
> > > > > >
> > > > > >  IF ('REAL' IN TYPEOF(x)) THEN ...; END_IF;
> > > > > >
> > > > > > Even though this may not be the most convincing real life
> > example, I
> > > > > hope
> > > > > > you see the usefulness of TYPEOF returning the type of the value
> > > that
> > > > > has
> > > > > > been assigned to it. How else could one treat x differently
> > > > based on the
> > > > > > type that it is carrying around?
> > > > > > An implementation will nontheless keep track of the actual type
> of
> > > an
> > > > > > object. So, why not give the user the (necessary) possibility to
> > > > > > query this?
> > > > > >
> > > > > > Best regards, Jochen.
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From:	David Price [SMTP:david.price at eurostep.com]
> > > > > > > Sent:	29. november 2001 12:13
> > > > > > > To:	Jochen Haenisch
> > > > > > > Cc:	'WG11 exploder'
> > > > > > > Subject:	RE: SEDS for ISO 10303-11
> > > > > > >
> > > > > > > Jochen,
> > > > > > >
> > > > > > > I'm not sure I like the idea that the datatype of something
> > > > > > depends on its
> > > > > > > instantiated value. TYPEOF is a datatype, not data value,
> > > > > > function so I'm
> > > > > > > a
> > > > > > > bit confused. Can you elaborate on why you want this change?
> Is
> > > this
> > > > > > > example
> > > > > > > any different from x being declared as a BAG that happens to
> be
> > > > > > > instantiated
> > > > > > > with non-duplicate members and so you want TYPEOF to return
> SET?
> > > > > > >
> > > > > > > Hope my question makes sense. It's basically, how far would
> > > > you expect
> > > > > > > this
> > > > > > > proposal to go?
> > > > > > >
> > > > > > > Cheers,
> > > > > > > David
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: owner-wg11 at steptools.com
> > > [mailto:owner-wg11 at steptools.com]On
> > > > > > > > Behalf Of Jochen Haenisch
> > > > > > > > Sent: 2001 November 29 09:02
> > > > > > > > To: 'seds at cme.nist.gov'
> > > > > > > > Cc: 'WG11 exploder'
> > > > > > > > Subject: SEDS for ISO 10303-11
> > > > > > > >
> > > > > > > >
> > > > > > > > Please, consider the SEDS report that is included below.
> > > > > > > > Best regards, Jochen Haenisch.
> > > > > > > >
> > > > > > > >  <<SEDS_Express_20011129.txt>>
> > > > > > > >
> > > > > > > > ____________________________________________________________
> > > > > > > > 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
> > > > > > > > N-0607 Oslo				Fax: Int +
> > 47 23 17 17 01
> > > > > > > > Norway					Web:
> > > > > > > > http://www.epmtech.jotne.com
> > > > > > > >
> > > > > > > >

More information about the wg11 mailing list