[wg11] EXPRESS Section 11 question

[Ed Barkmeyer]

Alan,

I wrote:
>>It is my position that the text of Part 11 is slightly in error, and the 
>>clause should be corrected to read:
>>"An entity which is either explicitly REFERENCE'd or implicitly
>>interfaced shall only be instantiated to play the role described by an
>>attribute of an instantiation of an entity in **, or interfaced into, ** 
>>the interfacing schema."

You wrote:
> I think that only sort-of works.  If you had a set of mutually referencing 
> instances of implicitly interfaced entities, then that would meet the above 
> critera, but would probably be wrong.

Possibly.  But they wouldn't be implicitly interfaced unless at least 
one of them is also referenced by an explicitly interfaced entity.
I suppose there could be some other means of implicitly interfacing 
them, e.g. by explicitly REFERENCEing a FUNCTION or RULE that involves 
one of those data types.

> Just to check, you do think an s1.e1 would be OK if it was referenced by an 
> s1.e2 that was referenced by an e3.  Yes?

Yes.

>>BTW, it has been pointed out before that this feature was ill-designed. 
>>Combining the "dependent entity" concept with the interfacing concept 
>>makes a completely orthogonal notion available only on interfacing.
> 
> 
> Agreed.  It would be nice if you could specify "second class" or support 
> concepts such as a date.  There should be some means of doing it explicitly 
> though.

Agree.  (Interestingly, I had originally written "second class entity" 
and changed it to "dependent entity".  Clearly we agree on the sense of 
this.)

I would be a bit careful here, however.  A "date" or "currency" or 
"measure" or "role" entity is an object that is *always* second-class: 
it is only meaningful as the value of some attribute.
But there are other entities that are "first-class" with respect to some 
discipline or view, but have only "dependent instantiation" with respect 
to some other view.  E.g. Person is a first-class entity with respect to 
human resource management, but it might be only a dependent entity with 
respect to product descriptions.


>>And therefore, in the 
>>long form, there is no way to convey that property at all.
> 
> 
> Doesn't that mean that any information base created from the long form could 
> break the dependencies stated in the short form?

Or any exchange file.  Absolutely.  That was the point of the previous 
SEDS, that the "dependency" requirement is lost in the long form, with 
the consequence that a population that is valid under the long-form 
schema isn't necessarily valid under the short-form schema, and 
therefore fails to meet the intent of the standard (AP).

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark at nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8264                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8264                FAX: +1 301-975-4694

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."