Hi Mats,
Thank you for highlighting this again - current
work has taken my eye off the issues raised before Christmas
holidays.
I guess these issues might be best logged as an
issue against the architecture &/or raised at the next TOG meeting - I have
few resources to follow up on these at the moment.
The danger I see in creating some of these
spcifications is that they shall, once defined, remain with little resemblance
to any of the actual DEXs that they were originally intended to be conformant
to, and will become nothing more than point to point interface
specifications.
On the naming aspect, I can live with Business DEX, but
personally I do not like the implication that it is a DEX. The DEXs have other
attributes (at present) such as a long form & guidance
material whereas the business side is generally more akin to a mapping
from an Application to a particular DEX, rather than a DEX themselves.
Kind regards,
Tim
Tim,
You
point out many important aspects with possible solutions which needs to be
resolved, please make sure they aren't
forgotten...
For now
I only like to make a small (and it is small) comment on the terminology
used by you. If you say "Business DEX Specification", to me that is read out
like; "Business Data EXchange Specification Specification". I would prefere
"Business DEX" instead of "Business DEX Specification".
Regards,
Mats - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Mats Nilsson, FMV
Dear Martin,
I did not note the final conclusion on the naming (too
busy talking I guess), but I am happy with it either way around. Some, however,
may think of this as something closer to an implementation agreement or
interface specification.
However, it is imperative that we DO agree on the format
& structure of the "Business DEX Specification" (BDS), as we must be able to
have a consistent view on what the spec looks like - without a definition,
we will have many examples of BDS' - but no one will know which is the accepted
style, format, or set of contents. Plus - what do we tell others outside of our
Oasis group that are now starting to ask about these (and other
aspects) when they want to develop their own? In my mind this is all part
of the architecture that should have been defined years ago, but we are having
to invent this as we progress. However, now the standard has been published
there is greater urgency to have all this material available
now.
We spent some time examining what the difference was
at the TOG meeting. The result was a mix of what has been generated for the
Manufacturers_item under TLSS and examples produced under the NDLO.
Fundamentally, a Business Dex Specification (BDS) will conform to a certain DEX.
The conformance would be shown through the use of all or a subset of the
entities defined within the DEX refered to. Unlike a DEX a BDS will use and
refer to Business Concepts which are mapped to those entities defined by the
DEX. (Current DEXs being generic in nature and applicable to more than one BDS).
The Business Concepts may introduce new templates to define the concepts.
These will be based upon the definitions (&
templates) prescribed for the entities mapped to, through the capabilities
used by the DEX. The BDS may define (textually) any constraints upon the
business concepts.
Yes, a number of the section headings will look similar to
that of a DEX but unlike a DEX, the BDS should provide the very real focus
for which the interface is being defined, e.g. for LSC, and our work on
UMMS, I'd like to develop an UMMS BDS which describes the business concepts
used in UMMS, their mapping to PLCS concepts as defined within DEX 4, along with
the context of such an exchange interface. In the future, if the UMMS data model
changes, then I only need update the mapping, likewise if the DEX changes, I
only need update the mapping. Ultimately, an UMMS BDS will not be the same
specification as DEX 4 as DEX 4 will suppport other mappings from other systems.
Personally, I don't think these specifications will
actually look that similar to a DEX - there is no need to duplicate the contents
or guidence in a DEX, only references. I suspect that a better name might
actually be something like ApplicationX DEX(N) Interface Specification
(e.g. UMMS DEX4 Interface Specification) as this describes more accurately what
it's purpose is. However, for something like a data wharehouse solution, which
receives input from potentially many applications the term DEX4 Interface
Specification would be better used (especially if using the DEX schema
itself).
The question of conformance to a DEX has so far been
largely ignored by everyone - assuming that it shall resolve itself. I disagree.
Unless we state what we mean by this, we will not be able to carry the
argument/logic forward to industry and others in SC4. By defining the concepts
used in a business exchange we can identify and resolve all the PLCS entities
required for that interface. As controversial as it might sound, this set of
entities need to be either a subset (read conformance class) of the DEX refered
to, or, the entire set according to the DEX. To achieve this, as discussed at
the TOG, we may need to generate & resolve a longform of the Express for a
BDS to be able to compare. Again, somewhat controversially, this then allows
implementers to only code for those entities required for the interface. This
was a solution to the problem faced by NDLO whose suppliers would not be
interested in exchanging more information than say a parts list. However, others
that have greater involvement who may need to exchange information according to
more than one BDS may (if all the BDS's refer to the same DEX) encode an
interface for the whole DEX, rather than one for each BDS. If the BDS's
refer to more than one DEX, then there may need to be more than one
interface. Note that usage of the DEX schema itself does not, however, mean
that every entity within it requires populating for every exchange - the
BDS should stipulate those.
These &
other issues will come to light very quickly once any implementation forum
(which is also being discussed now) starts, which is why we must have some
discussion and agreement about this, even if it may require further refinement
later. There is an added impact in whether or not we wish Dexlib to support the
BDS and in resolving the longform Express to indicate (sub) conformance to the
DEX.
In the interest of expediency, I would suggest to move
these issues to a new (email) thread and at least allow agreement on the
previous terms being discussed below.
regards,
Tim
In
terms of the 'business side of the equation', I thought that we had agreed on
Business DEX (Specification) rather than the other way around (DEX Business
Specification).
A
Business DEX will be the same as a PLCS DEX but will also specify business
context, business terms & concepts and will have references to the relevant
capabilities, templates and reference data - or maybe someone can correct me,
but I do think that we need to agree/decide on whether all this things are
actually contained within a Business DEX or whether the Business DEX
contains 'pointers' that refer out to these (and/ or other)
things.
Regards,
Martin.
I have added some details to the definitions to clarify
(or confuse!)
DEX = Data Exchange
Specification = the definition in DEXlib
DEX file = electronic file
(P21/P28) with actual instance data conforming to
(complete or sections of) a DEX
Data Exchange Set =
a term grouping all PLCS entities and attributes identified by a
DEX
Do we also have any agreement on the business side of the
equation? Some called it just a "DEX Business
Specification".
To me the DBS is a specification describing the terms and
business concepts of the domain which are then defined using the PLCS entities
according to the DEX referenced.
Regards,
Tim
From: Chris Kreiler
[mailto:kreilerc@mantech-wva.com] Sent: 16 December 2005
08:54 To: mats.nilsson@fmv.se;
plcs-tog@lists.oasis-open.org Subject: RE: [plcs-tog] RE: Documents
from the TOG meeting
This offers the best
compromise for describing what we are building. I vote
yes!
From:
mats.nilsson@fmv.se [mailto:mats.nilsson@fmv.se] Sent: Friday, December 16, 2005 7:38
AM To:
plcs-tog@lists.oasis-open.org Subject: VB: [plcs-tog] RE: Documents
from the TOG meeting
Nigel and I has reached a
consensus.
DEX = Data Exchange
Specification = the definition in DEXlib
DEX file =
electronic file with actual data conforming to (complete or sections of) a
DEX
Data Exchange Set =
a term grouping all PLCS entities and attributes identified by a
DEX
Regards, Mats - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - Mats
Nilsson, FMV
Från:
Nigel Newling [mailto:nfn@lsc.co.uk] Skickat: den 16 december 2005
12:40 Till: Nilsson, Mats
maxnn Ämne: RE: [plcs-tog]
RE: Documents from the TOG meeting
Now put it
to the wider audience and stand back!
-----Original
Message----- From:
mats.nilsson@fmv.se [mailto:mats.nilsson@fmv.se] Sent: 16 December 2005
10:54 To:
nfn@lsc.co.uk Subject: SV:
[plcs-tog] RE: Documents from the TOG meeting
Summary:
DEX = Data Exchange
Specification = the definition in DEXlib
DEX file = electronic file with
actual data conforming to (complete or sections of) a
DEX
Data Exchange Set = a term
grouping all PLCS entities and attributes identified by a
DEX
Regards, Mats - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - Mats Nilsson, FMV
Från: Nigel Newling
[mailto:nfn@lsc.co.uk] Skickat: den 15 december 2005
13:56 Till: Nilsson, Mats
maxnn Ämne: RE: [plcs-tog]
RE: Documents from the TOG meeting
The Information
displayed, following the selection of a DEX through the menu in
DEXLib, is the DEX 'specification'. The entities and attributes
identified in that specification comprise the DEX data
'set'
-----Original
Message----- From:
mats.nilsson@fmv.se [mailto:mats.nilsson@fmv.se] Sent: 15 December 2005
09:50 To:
nfn@lsc.co.uk Subject:
SV: [plcs-tog] RE: Documents from the TOG meeting
Set or
Specification or both?
Howard did not
specify...
Från: Nigel Newling
[mailto:nfn@lsc.co.uk] Skickat: den 15 december 2005
09:51 Till:
plcs-tog@lists.oasis-open.org Ämne: RE: [plcs-tog] RE: Documents
from the TOG meeting
The term
'Set' was introduced when we were discussing the scope of 'data
set' that should be defined by the DEX specification. Howard's
contribution has my vote - and we should not shy away from CCs
either!
-----Original
Message----- From:
Mason, Howard (UK) [mailto:howard.mason@baesystems.com] Sent: 14 December 2005
17:43 To:
mats.nilsson@fmv.se; kreilerc@mantech-wva.com; ils-de@a.dii.mod.uk;
rob.bodington@eurostep.com Cc:
plcs-tog@lists.oasis-open.org Subject: RE: [plcs-tog] RE:
Documents from the TOG meeting
At the risk of
being contentious, we tend to refer to a STEP AP and its conformance
classes. Without wishing to equate a PLCS DEX with a STEP
conformance class in detail, they are at the same
level.
A conformance
class is a specification, and individual conforming blocks of data are
files.
Also we never
defined the silent "s" in DEX.
This kind of
suggests to me that DEX is the specification (Data EXchange (set or
specification)) and an instance is a DEX(-compliant)
file.
Howard
Mason
From:
mats.nilsson@fmv.se [mailto:mats.nilsson@fmv.se] Sent: 14 December 2005
15:43 To:
kreilerc@mantech-wva.com; ils-de@a.dii.mod.uk;
rob.bodington@eurostep.com Cc:
plcs-tog@lists.oasis-open.org Subject: SV: [plcs-tog] RE:
Documents from the TOG meeting
*** WARNING
***
This mail has originated outside your
organization, either from an external partner or the Global
Internet. Keep this in mind if you answer this message.
|
Chris,
My opinion is
that we still are at a point where terminology could be changed, if it
is useful and brings clarity to our work. Still, more than
99.99998%* of the worlds population is unaware of PLCS and its
terminology (poor creatures...) ;o)
*) Calculated
as; 1 000 / 6 300 000 000
Från: Chris Kreiler
[mailto:kreilerc@mantech-wva.com] Skickat: den 14 december 2005
13:57 Till: 'Gibson,
Martin'; Nilsson, Mats maxnn; rob.bodington@eurostep.com Kopia:
plcs-tog@lists.oasis-open.org Ämne: RE: [plcs-tog] RE: Documents
from the TOG meeting
Martin and
Mats,
Although it is
a minor point, I think we should be careful about changing the
terminology at this point due to the recognition that Data Exchange Set
enjoys among most of our customers.
Just my 2 cents
before the snow storm here in West Virginia.
From:
Gibson, Martin [mailto:ils-de@a.dii.mod.uk] Sent: Wednesday, December 14, 2005
3:13 AM To:
'mats.nilsson@fmv.se'; rob.bodington@eurostep.com Cc:
plcs-tog@lists.oasis-open.org Subject: RE: [plcs-tog] RE:
Documents from the TOG meeting
My view is
that it should be 'Data Exchange Specification'
-----Original
Message----- From:
mats.nilsson@fmv.se [mailto:mats.nilsson@fmv.se] Sent: 14 December 2005
08:05 To:
ils-de@a.dii.mod.uk; rob.bodington@eurostep.com Cc:
plcs-tog@lists.oasis-open.org Subject: SV: [plcs-tog] RE:
Documents from the TOG meeting
Another
question: If I want to use the non-abbreviated term for 'DEX'. Should
I then pronounce/write it "Data exchange set" (which for my
swedish ears much sounds like file (file = a 'set' of data)) or
"Data exchange specification"?
Regards -
Mats
Martin,
Thanks for
the clarification!
I'm ok with
that. As long as everyone understands eachother! 'DEX' and 'DEX file'
it is!
Regards,
Mats - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - Mats
Nilsson, FMV
Från: Gibson, Martin
[mailto:ils-de@a.dii.mod.uk] Skickat: den 7 december 2005
11:33 Till: Nilsson,
Mats maxnn Ämne: RE:
[plcs-tog] RE: Documents from the TOG meeting
Hope you
enjoyed yesterday's telecon/meeting (as much as I
did!).
I'm not sure
it was mentioned within the telecon, but , you are correct in your
guess that the ToG Agreed that the term 'DEX' is synonymous with the
term 'DEX Specification' and that a 'DEX file' is indeed that file
which would be exchanged as part of a PLCS
implementation.
-----Original
Message----- From:
mats.nilsson@fmv.se [mailto:mats.nilsson@fmv.se] Sent: 06 December 2005
08:13 To:
rob.bodington@eurostep.com; plcs-tog@lists.oasis-open.org Subject: SV: [plcs-tog] RE:
Documents from the TOG meeting
All,
Is the
visio diagram a result of the review of the concept model
draft?
It lacks some of the terms in the concept model
(DEX file,
Requirements, etc.) and it refers to 'DEX Specifications' as 'DEXs'.
I did not
attend the meeting. Is this what was agreed?
I like the
graphical layout though (except for the 'uses' arrow pointing to
'Business Reference Data' that has no
source...).
Should I
put it in the DEXlib information pages (new name for the help
section...) and in that way prepare it for
ballot?!
Maybe
something for the meeting this afternoon?
Regards,
Mats - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - Mats Nilsson, FMV
Från: Rob Bodington
[mailto:rob.bodington@eurostep.com] Skickat: den 6 december 2005
08:00 Till:
plcs-tog@lists.oasis-open.org Kopia: Sean Barker Ämne: [plcs-tog] RE: Documents
from the TOG meeting
Hi
I have had
several requests for a non Visio version of the
diagram.
-----Original
Message----- From:
Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 30 November 2005
14:12 To:
'plcs-tog@lists.oasis-open.org' Cc: Sean Barker
(Sean.Barker@baesystems.com) Subject: Documents from the TOG
meeting
Hi
Here are the
diagrams/spreadsheets that we developed in the
TOG.
We went through all DEXs
(apart from 5 and 9) and identified which capabilities were
required. We then looked at who as editing it and whether they were
funded. The spreadsheet reflects results of this.
We also reviewed the
concept model and produced the attached Visio
diagram.
Regards
Rob
------------------------------------------- Rob
Bodington Eurostep Limited Web Page: http://www.eurostep.com http://www.share-a-space.com Email:
Rob.Bodington@eurostep.com Phone: +44 (0)1454 270030 Mobile:
+44 (0)7796 176 401
******************************************************************** This
email and any attachments are confidential to the
intended recipient and may also be privileged. If you are not
the intended recipient please delete it from your system and
notify the sender. You should not copy it or use it for any
purpose nor disclose or distribute its contents to any other
person. ******************************************************************** |
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
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
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
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
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
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
|