|
I am
sorry I have to disagree with John,
Surely
we deliberately chose the DEXs to be generic in order for the standard to be
able to cope with the wide range of the businesses interested in PLCS. If we
produce specific DEXs as advocated by Trine and Leif we will end up with a vast
number each tailored specifically to one sector of one business area. For
instance Trine said the Norwegians have already identified 30 variations of
one capability. Multiply that by the number of capabilities and you will realize
just how many tailored DEXs are likely to be produced and just how bespoke they
will be.
What
has happened to the idea of having a standard that is universal, (sorry I mean
International), and can be used by every relevant business sector,
implemented by specific mapping and utilizing extended reference data to cope
with terms that relate only to your business.
I
almost agree on one point, John's final sentence. The existing world of
support information is uncoordinated, (not messy as that is a very
imprecise word), - but surely that is why we starting this PLCS thing in the
first place.
Les Debenham
LSC Group Ltd.
PO Box 77 Devonport
House
Durley Park, Bristol BS31 2YH
Tel: +44 117 916 1464
Fax: +44
117 916 1499
Mob: +44 7739 306799
www.lsc.co.uk
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
**************************************************************
DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG
|