RE: [plcs-dex] What is a DEX

[Peter Bergstrom <peter.bergstrom@eurostep.com>]

I'm sorry, but I don't understand. I probably misunderstood something very
basic here, so I better explain my view and let wiser men (and women) tell
me what I didn't understand...

I though the DEX was a specification for an exchange file. In my mind, the
DEX is standardized and fixed through OASIS, you would never send 'it'. You
would send and exchange file _conforming_ to the DEX.

DEX3 would in my mind specify how tasks have to be structured/encoded to be
transmitted accorded to DEX3 and PLCS. I thought DEX3 should not say you
cannot send more than one task at the time (that, too me, would be quite
rediculous). It would specify the structure/format for instances according
to the Task(_method)-entity and related entities.

If someone would want to limit the exchange file to say 'just one task per
file', they would do so in the exchange agreement, I would say, or possibly
in the Business concept, but it is not part of the DEX to make such
limitations.

Regarding the name 'Task-set', I have always wondered why the 'set' was
there. The DEX shouldn't either specify you have to send a set of tasks. In
my mind, an exchange file conforming to a future DEX3 specification could
contain 1 or many tasks. I would actually prefer to have the name be 'task',
not 'task set'.

If I have misunderstood the entire issue with your email here, please tell
me so and don't waste more time on this. If I haven't, I'm worried...


Peter
--
Peter Bergstrom          office: +46-8 200 440
Eurostep AB              mobile: +46-708 111 966
Vasagatan 38             fax: +46-708 111 965
111 20 Stockholm
Sweden

-----Original Message-----
From: Barker, Sean (UK) [mailto:sean.barker@baesystems.com]
Sent: den 26 augusti 2005 16:17
To: DEXS-PLCS-OASIS (E-mail)
Subject: [plcs-dex] What is a DEX



At DEX 3 meeting, we had a discussion arising from the definition of a
DEX in the context of Task-list. The discussion is summarized in the
attached figure. Essentially the question is whether the message entity
is part of the DEX, but the argument goes as follows:

1) A DEX is a design, rather than a physical file (DEX as Realized).

2) Create temporary term "DEX content item", meaning everything but the
message.

3) An exchange consists of a message AND [[Exactly one DEX content item]
OR
							[Many DEX
content item]]

The user requirement (Norwegian Frigate) was for many DEX content items.

4) A DEX is either [The DEX content items] OR [The message entity AND
the DEX content items]

The preferred solution was [Message AND DEX content items] (Bottom
right, in red).

In the case of DEX 3, the content item is a Task, and
Message.Content_item[i] points to each Task.
No DEX can contain the content of any other DEX.

5) Note: the various items in the DEX are independent of each other, and
the fact that they come as a collection is merely a convenience, for
example, to avoid having to manage too many files. Tool vendors have a
valid input at this point. The number of items per DEX may be restricted
by business rule.

6) We can now delete the term "DEX content item", and say, say, DEX 3
contains a message and several Task descriptions.

Note: The users have decide to restrict the scope of DEX 3 to Task. This
is narrower than the original Task-set, wherein the Task-set would
define a collection for a specific purpose and provide any appropriate
meta-data. Discussions have been started about generalizing DEX 5 to
cove such a requirement.

DO NOT SHOOT THE MESSENGER.

Sean Barker
0117 302 8184



********************************************************************
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.
********************************************************************