|
I too
have the sense that the DEXs we are working on are too generic, and,
potentially too big. In deciding how to move forward we need to
balance
- the
scope of any DEX
- the
ref data options that may support it
- the
permitted variants within a DEX
On top
of all this it may often be necessary to add further local business
level constraints at the company to company or system to system exchange
level.
We
also need to remember that the environment we work is is both fragmented and
varied when compared with the world of CAD.
For
all of the above reasons I think the right way to proceed is for the DEX work to
be lead by teams with REAL business cases; for them to develop a DEX that
suits their local needs (offering variants within it IF they need these) and
then for subsequent changes to be made when a second similar case emerges that
cannot use the existing DEX as it stands.
This
is not a problem that can be solved by abstract thinking, however clever.
The existing world of support data is just too messy.
John Dunford,
Eurostep Limited,
25, Chaucer Road, BATH BA2 4QX,
UK
Tel: +44 1225 789347
Mobile: +44 0797 491 8202
Rob.
A ”generic” capability (as defined in DEXLib) consists of a set of
variables/parameters as entities and attributes. Each of the parameters are documented in the "Usage"
part of the capability documentation.
One entity may have several reference data definitions. This implies
the possibility of several combinations of variables/parameters for each
capability. Each of these combinations represents different business concepts
or business meanings. That’s what the
Norwegian pilots call “instantiated” capabilities. The Norwegian
pilots have identified (and documented)
more than 20-30 instantiations of several of the capabilities – each of them
applied in at least one instantiation
diagram.
As Leif pointed out in the February
meeteing, it
therefore looks like a
DEX represented in DEXLib is
not specific enough (both from a business point of view and from
an implementor’s point of view) before
it consists of a precise combination of instantiated capabilities. That’s why
the Norwegian pilots operates with what we have called instantiation
diagrams (which consists of instantiated
capabilities). In a way an instance diagram may correspond to a DEX,
but it is more precise and mostly smaller than the DEXs in DEXLib.
As Leif pointed out in the February meeting, the capabilities in DEXLib
do not look specific enough compared with the experience from the Norwegian
pilots. It is not enough relating a lot of reference data stuff to each of the
parameters in a capability. It seems to me that DEXLib easily could contain
the additional information to achieve
"instantiated capabilities". We have also discussed the possibility to add the
instantiation diagrams into the DEXLib documentation.
Of course it is still
a possibility that DEXLib and the capability concept in DEXLib contains the
"instantiated" capability level, but we have not been able to identify
it?
Hopefully we can discuss this further in
Oslo?
Regards
Trine
-----Original
Message-----
From: Rob Bodington [mailto:rob.bodington@eurostep.com]
Sent: 27. mars 2004 15:30
To: Hansen, Trine;
plcs@lists.oasis-open.org
Subject: RE: [plcs] Review of capabilities
- Some comments from the Norwegian pilots
Thanks
for this Trine.
I’m not sure I
understand what you mean by the comment:
•
How to handle/document instantiated capabilities?
A caapbility is
described in dexlib.
What do you mean by
an “instantiated capability” ?
-----Original
Message-----
From:
Trine.Hansen@dnv.com [mailto:Trine.Hansen@dnv.com]
Sent: 26 March 2004 16:31
To:
plcs@lists.oasis-open.org
Subject: [plcs] Review of capabilities
- Some comments from the Norwegian pilots
Finally some comments to the
documentation of capabilities in DEXLib based on Norwegian pilots
needs/experience.
See attached
document.
<<Comments
from the Norwegian Pilots after review of C032 and C016.doc>>
Regards
Trine
Hansen
UCTNO940, Information Quality
Management
Det Norske Veritas
AS
( + 47
67 57 96 38 (office)
( + 47
90 83 44 24 (mobile)
* trine.hansen@dnv.com
http://www.dnv.com
**************************************************************
Neither
the confidentiality nor the integrity of this message can be guaranteed
following transmission on the Internet.
All messages sent to a DNV email
addressee are swept by Sybari Antigen for the presence of computer viruses.
DNV acknowledges that SPAM email represents a potential security risk,
and DNVs filters to block unwanted emails are therefore continuously
adjusted. DNV has disabled "out of office" replies to the Internet
**************************************************************
**************************************************************
Neither
the confidentiality nor the integrity of this message can be guaranteed
following transmission on the Internet.
All messages sent to a DNV email
addressee are swept by Sybari Antigen for the presence of computer viruses.
DNV acknowledges that SPAM email represents a potential security risk, and
DNVs filters to block unwanted emails are therefore continuously adjusted. DNV
has disabled "out of office" replies to the Internet
**************************************************************
|