RE: [plcs-dex] What is a DEX

["Barker, Sean (UK)" <sean.barker@baesystems.com>]

Peter,

	Your summary is, for the most part, correct. My note was
essentially about a detail of the definition of a DEX, namely, whether
Message is part of a DEX, or whether it is external to a DEX.
	It is also a clarification of the statement "a File will contain
one DEX". Since a DEX is a specification, the question was whether this
statement meant it conformed to one DEX specification, with multiple
instantiations, or whether it meant a single instantiation. Restriction
of the number of instantiations is, therefore, a matter of exchange
agreement (business rule).
	The term Task Set arises from the AAM lifecycle stage, in which
the DEX supports the evolution of the support solution. One element of
this is the contracting for the set of tasks applicable to an equipment
and its sub-equipments. The function of task set is mainly to control
contracting for the set of tasks, as well as interchange the task
descriptions. It is this contracting/lifecycle control aspect of Task
Set that has been put out of scope.
	I hope this clarifies.
	

Sean Barker
0117 302 8184

-----Original Message-----
From: Peter Bergstrom [mailto:peter.bergstrom@eurostep.com]
Sent: 27 August 2005 08:27
To: Barker, Sean (UK); DEXS-PLCS-OASIS (E-mail)
Subject: RE: [plcs-dex] What is a DEX

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

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




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