Dex compilation and capabilities (referencing vs representation).

[Tim Turner <timturner11@bellsouth.net>]

All,

Probably due to my own ignorance, I have the following up for
clarification/discussion/shoot-out :- ) !


It seems (painfully) evident that when trying to use many of the
"referencing" capabilities in a dex, that these are insufficient when it
comes to compilation. This is because either the capability does not pull in
enough of the required entities through it's dependancy list, or it's entity
usage section is incomplete.

Adding entities to the capability usage list means (to my understanding)
that this then needs to be discussed in the body of the capability. However,
many of those have been left out because they pull in even more entities
which begins to defeat the objective of providing a reference.

The alternative is to resort to pulling in the corresponding
"representating" capability. Other capabilities bring in the same as those
defining the representation in the first place, but only document those
aspects needed to identify key parts. If you need to both describe the
representation and how to reference (the PIF), then you have to pull in both
capabilities. However, at the Express level this is meaningless since (in
most cases) the former covers the entities of the latter. Some capabilities
will need to become smaller in scope in the future (e.g.
representing_breakdown_structures) where it is evident that many exchanges
will only need to use certain aspects (e.g. system_breakdown).

Many "referencing" capabilities are not referencing mechanisms as one would
normally expect. I (for one) would expect that a reference is just that -
like reference to a library book or to some point in an RDL - you have a
string. These capabilities are making the assumption that a database (or the
like) exists and that an exchange has already occurred, and that to identify
something in that database you need to follow the guidance in the
referencing capability.

IMHO we should NOT make ANY assumptions about the implementation, because
that should be immaterial from what we are doing. Hence if we are to produce
Data Exchange Standards (DEXs) the building blocks we use to create them
must explicitly define each of the entities used, or pull in a building
block which does.

I think that what is in these referencing capabilities is useful and have a
place in what we're doing, but they have made the whole architecture more
complex than necessary.

IMHO, I would suggest that this information would be really useful within
the Dex Information Model Overview section since it guides the user into
understanding how to identify the design, planned or realized item
in-the-context-of the domain - such as the design configuration, the design
assembly, the design breakdown (i.e. the capability). Other examples include
the product_as_planned in-the-context-of the domains - such as the planned
configuration, the planned assembly, the planned breakdown etc., and on to
the realized contexts. The reader has the requirement(s) to be able to find
these items in the mass of information we are delivering and needs to know
that the mechanism is accurate, dependable and scaleable.

When the user/reader understands at that level, how to access the
information he/she needs, their next question is going to be - how do I
generate a representation that allows this? The answer, of course, is in the
capabilities that hopefully provide the enough guidance to the implementor
to understand the nuances of the model and what is required to produce a
valid representation.

Kind regards,
Tim

NB If we want to reference something  from another exchange, or another Dex
then lets create the mechanism to do it without making the product/process
any more complicated. I have a suggestion on this for another email!