[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
No cyclic part_view_definiton structures may be defined. The value of the
identification_assignment.identifier (for PDM Schema this is the local id
attribute) must be unique in combination with the same relating assembly and
related component definitions. For PLCS this implies that the identifier for
each part_view_definition, part_version and part must be unique within the
assembly. It is generally recommended that only subtypes of
assembly_component_relationship be instantiated. It is not necessary to
instantiate the optional relation_type, location_indicator or quantity
attributes for an instance of next_assembly_usage in the context of a basic
parts list. If information on the assembly type is to be represented, then
this additional information should be represented using the
view_definition_context.description attribute. This information is linked
through the part_view_definition.additional_contexts attribute inherited
from product_view_definition (leaving the application_domain and
life_cycle_stage attributes empty). Examples of such type information are
'functional assembly', 'manufacturing assembly', and 'design assembly'.....
.... I think most is still applicable, except for those examples which might
be different depending upon usage.
Prop 1: This information, however, is now captured under the CVS versioning
so removing these sections for now, is not a problem and may aid consistency
across the capabilities. I could agree to putting this on the "back-burner"
for now so that the complexity issue can be ironed-out first; though I
suspect we may need to come back to it at some point.
The other thing that seems to come out of this (for me at least) is a
question on whether the capabilities should document any of the items
referenced from a select type. In some capabilities I see examples that are
specific to the Dex within which it is primarily to be used, but when I look
at Dex 1, I realize that the example (entity used) in the capability is not
actually present (e.g. out of scope). Likewise, I could have done the same
in generating capabilities under Dex1 & for example, in
assigning_identifiers I may have only used the entity "Part" when showing
how the identification_assignment works, though this may not be present in
al Dexs.
Prop 2: We (modellers) need to decide if we are to document the contents of
these select types or not. I have actually documented ALL PLCS entities
available from the identification_item select type, though only chosen one
for the example. I have also added notes to state that this list may change
depending upon the usage of the capability (i.e. in which Dex) since the
contents of the list may be pruned according to the scope. However, someone
looking at the capability, from a *re-use point of view*, would be able to
see which entities are referable from the material and to make decisions
accordingly for the Dex they are planning. I would therefore, suggest this
as a default position when documenting the capabilties, (though I am still
open to discussion)!
Kind regards,
Tim
-----Original Message-----
From: Leif.Tonning@dnv.com [mailto:Leif.Tonning@dnv.com]
Sent: 30 April 2004 07:53
To: timturner11@bellsouth.net
Cc: rob.bodington@eurostep.com; Trine.Hansen@dnv.com;
Jochen.Haenisch@epmtech.jotne.com
Subject: RE: Pre-post processor info
I get some of the picture.
As you are aware, we have had some uncertainty as to wether the current PLCS
capabilities and DEX'es can easily be reused in our pilots, and we have
communicated our needs and ideas back to Rob and others.
In this work we have not met the problem you refer to with documentation of
capabilities and the related DTD.
I appreciate that the PDM schema rightly calls on pre and postprocessors.
However, we have not met the need for these in our work. Why?
As in PLCS, we develop generic capabilities, and these are to a large extent
of the same type. Then we instantiate the capabilities to hold real data.
Currently, thes instantiated data are legacy type, not subject to
standardisation, but they should (using reference data) be identical to
stable logistics business data as found e.g. in DefStan 00-60. Then the
instantiated caps (possibly grouped inside a generic cap) should be
standardised.
To be able to use caps (the instantiated ones), instantiation diagrams (also
candidates for standardisation when populated with reference data) are
developed. These represent business concepts where the caps are used and
reused.
To populate a PLCS database, we have not met needs for postprocessing other
than as defined in the instantiations (the mapping diagrams). This, however,
does not mean that postprocessing is not an added value, but the need should
be carefully assessed before another level of complexity is added to PLCS.
To extract data from the PLCS database, query is used. Again no other need
for preprocessing, and again, carefully assess the need, complexity and cost
benefit..
We believe that the exchange specification for import and export technically
is the same, but there may be other reasons why this is not so.
Also, provided pre and post processing is introduced, care should be taken
to distinguish between the generic part and the instantiatied part. I see
the generic parts only as aids to develop the instantiated parts. When the
logistics domain is fully populated with instantiated reference data, these
should be used by all, and the need for the generic capabilities disappear.
Mapping legacy data to PLCS will then be done using the instantiation
diagrams and the instantiated capabilities. Databases and data exchanges
will hold instantiated data (legacy or the reference data substitution for
the legacy data), not generic capabilities.
Knowing well I am operating in troubled water, I still hope this is to help
and not to confuse. If the latter, forget the mail.
Best regards
Leif Tonning
-----Original Message-----
From: Tim Turner [mailto:timturner11@bellsouth.net]
Sent: 29. april 2004 20:50
To: Tonning, Leif
Cc: rob.bodington@eurostep.com
Subject: RE: Pre-post processor info
Oh um, sorry!
Well a lot of the early capabilities had sections on pre & post processor
guidence in the main body, underneath the descriptions of the entity
attributes being documented. For example, under representing assembly
structures & BOM there is a section on
PostprocessorRecommendationsPostprocessor Recommendations. However, these
sections need to be moved to the usage area (I.e. in amongst the entity
definitions), but I cannot copy the section to that part as the dtd seems
not to allow it. I need to see some sort of example on how this should be
done, or for the dtd to change to enable a simpler format.
I believe that I can just delete the attribute sections I have manually
provided since these are already available in the usage area.
Regards,
Tim
-----Original Message-----
From: Leif.Tonning@dnv.com [mailto:Leif.Tonning@dnv.com]
Sent: 29 April 2004 02:46
To: timturner11@bellsouth.net
Cc: rob.bodington@eurostep.com
Subject: RE: Pre-post processor info
Hi, Tim
Sorry, I'm not on the net. Probably I have missed some communication and do
not understand what you are asking.
I will do my best to give you an answer, but need better to understand the
issue
Leif t
-----Original Message-----
From: Tim Turner [ <mailto:timturner11@bellsouth.net>
mailto:timturner11@bellsouth.net]
Sent: 28. april 2004 20:32
To: Rob Bodington (E-mail); Tonning, Leif
Subject: Pre-post processor info
Guys,
I'm trying to address the issue of moving much of this information
into the usage section, but I need an example where this has been done that
I can follow.
Do you have anything I could look at?
Cheers,
Tim
**************************************************************
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
------_=_NextPart_001_01C431B0.B1B96960
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#008080 size=2><SPAN class=072551508-04052004>It
would be of beneficial to all involved in the current programme if this type of
query was broadcast via the 'exploders' instead of depending on the good faith
of other 'team players'</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#008080 size=2><SPAN
class=072551508-04052004></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#008080 size=2><SPAN
class=072551508-04052004>Gordon</SPAN></FONT></DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Nigel Newling <BR><B>Sent:</B>
04 May 2004 09:01<BR><B>To:</B> Les Debenham; Gordon Robb<BR><B>Subject:</B> FW:
Pre-post processor info<BR><BR></FONT></DIV>
<DIV> </DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Tim Turner
[mailto:timturner11@bellsouth.net]<BR><B>Sent:</B> 30 April 2004
17:02<BR><B>To:</B> Leif.Tonning@dnv.com<BR><B>Cc:</B>
rob.bodington@eurostep.com; Trine.Hansen@dnv.com;
Jochen.Haenisch@epmtech.jotne.com; Nigel Newling (E-mail)<BR><B>Subject:</B>
RE: Pre-post processor info<BR><BR></FONT></DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2>Leif,</FONT></SPAN></DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2>Still waters run deep, so any troubled ones are fairly shallow ones ; -
)</FONT></SPAN></DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff size=2>I
think I understand what you are saying and raise two proposals - though
the implications need to be clearer..</FONT></SPAN></DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2><SPAN class=160373013-30042004><FONT face=Arial><FONT color=#0000ff
size=2><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2>Your experiences seem not to involve full exchange file scope as
defined by the Dexs, since you are dealing with legacy data and more ad-hoc
query-related data extraction which does not require a fully instantiated Step
file acc. to one or other Dexs. However, for longterm data archiving I suspect
that this may be
required.</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff size=2>The
suggestion is that there needs to be (or is already) a generic set of
capabilities that may then be extended with standardized terms for common
usage within a domain. These terms of common usage I would suggest are those
defined by the user community (such as MoD, Nato, or other large organization)
and are represented as reference data. </FONT></SPAN></DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff size=2>This
means that the capabilities can/should only provide example reference data
until the particular exchange community has adopted a specific set/collection
of reference data for that industry/domain. Once adopted, the reference data
can be used to complete the schema in terms of the acceptable values for
attributes such as identifiers and relevant rules can be written to enforce
these. This version of the capability(s) is what you are saying needs/could be
standardized.</FONT></SPAN></DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff size=2>In
other guises, this is close to the subject of a set of implementor's
agreements, but begins at a little higher level.</FONT></SPAN></DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2><SPAN class=160373013-30042004><FONT face=Arial><FONT color=#0000ff
size=2><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN> </DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial><FONT color=#0000ff
size=2>From this view I can see that pre & post processor guidence may be
a little premature and would need to be careful not to include items that are
effectively example reference data items. </FONT></FONT></SPAN></DIV>
<DIV><SPAN class=160373013-30042004></SPAN><SPAN
class=160373013-30042004><FONT face=Arial><FONT color=#0000ff size=2><SPAN
class=160373013-30042004></SPAN></FONT></FONT></SPAN><SPAN
class=160373013-30042004><FONT face=Arial><FONT color=#0000ff size=2><SPAN
class=160373013-30042004></SPAN></FONT></FONT></SPAN> </DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial><FONT color=#0000ff
size=2>However, some of the sections on this subject are indeed more
generic & for example, under the capability
representing_assembly_structure the first pre-processor statement
reads...</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DL>
<DD>
<ADDRESS><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2>No cyclic part_view_definiton structures may be defined. The value of
the identification_assignment.identifier (for PDM Schema this is the local
id attribute) must be unique in combination with the same relating assembly
and related component definitions. For PLCS this implies that the identifier
for each part_view_definition, part_version and part must be unique within
the assembly. It is generally recommended that only subtypes of
assembly_component_relationship be instantiated. It is not necessary to
instantiate the optional relation_type, location_indicator or quantity
attributes for an instance of next_assembly_usage in the context of a basic
parts list. If information on the assembly type is to be represented, then
this additional information should be represented using the
view_definition_context.description attribute. This information is linked
through the part_view_definition.additional_contexts attribute inherited
from product_view_definition (leaving the application_domain and
life_cycle_stage attributes empty). Examples of such type information are
'functional assembly', 'manufacturing assembly', and 'design
assembly'.....</FONT></SPAN></ADDRESS></DD></DL>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff size=2>....
I think most is still applicable, except for those examples which might be
different depending upon usage.</FONT></SPAN></DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2><U>Prop 1:</U> This information, however, is now captured under the CVS
versioning so removing these sections for now, is not a problem and may aid
consistency across the capabilities. I could agree to putting this on the
"back-burner" for now so that the complexity issue can be ironed-out first;
though I suspect we may need to come back to it at some
point.</FONT></SPAN></DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff size=2>The
other thing that seems to come out of this (for me at least) is a question on
whether the capabilities should document any of the items referenced from a
select type. In some capabilities I see examples that are specific to the Dex
within which it is primarily to be used, but when I look at Dex 1, I realize
that the example (entity used) in the capability is not actually present (e.g.
out of scope). Likewise, I could have done the same in generating capabilities
under Dex1 & for example, in assigning_identifiers I may have only used
the entity "Part" when showing how the identification_assignment works, though
this may not be present in al Dexs. </FONT></SPAN></DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2><U>Prop 2: </U>We (modellers) need to decide if we are to document the
contents of these select types or not. I have actually documented ALL PLCS
entities available from the identification_item select type, though only
chosen one for the example. I have also added notes to state that this list
may change depending upon the usage of the capability (i.e. in which Dex)
since the contents of the list may be pruned according to the scope. However,
someone looking at the capability, from a *re-use point of view*, would be
able to see which entities are referable from the material and to make
decisions accordingly for the Dex they are planning. </FONT></SPAN><SPAN
class=160373013-30042004><FONT face=Arial color=#0000ff size=2>I would
therefore, suggest this as a default position when documenting the
capabilties, (though I am still open to discussion)!</FONT></SPAN></DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff size=2>Kind
regards,</FONT></SPAN></DIV>
<DIV><SPAN class=160373013-30042004><FONT face=Arial color=#0000ff
size=2>Tim</FONT></SPAN></DIV>
<BLOCKQUOTE>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Leif.Tonning@dnv.com
[mailto:Leif.Tonning@dnv.com]<BR><B>Sent:</B> 30 April 2004
07:53<BR><B>To:</B> timturner11@bellsouth.net<BR><B>Cc:</B>
rob.bodington@eurostep.com; Trine.Hansen@dnv.com;
Jochen.Haenisch@epmtech.jotne.com<BR><B>Subject:</B> RE: Pre-post processor
info<BR><BR></DIV></FONT>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff size=2>I
get some of the picture.</FONT></SPAN></DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff size=2>As
you are aware, we have had some uncertainty as to wether the current PLCS
capabilities and DEX'es can easily be reused in our pilots, and we have
communicated our needs and ideas back to Rob and others.</FONT></SPAN></DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff size=2>In
this work we have not met the problem you refer to with documentation of
capabilities and the related DTD.</FONT></SPAN></DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff size=2>I
appreciate that the PDM schema rightly calls on pre and postprocessors.
However, we have not met the need for these in our work.
Why?</FONT></SPAN></DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff size=2>As
in PLCS, we develop generic capabilities, and these are to a large extent of
the same type. Then we instantiate the capabilities to hold real data.
Currently, thes instantiated data are legacy type, not subject to
standardisation, but they should (using reference data) be identical to
stable logistics business data as found e.g. in DefStan 00-60. Then the
instantiated caps (possibly grouped inside a generic cap) should be
standardised.</FONT></SPAN></DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff size=2>To
be able to use caps (the instantiated ones), instantiation diagrams (also
candidates for standardisation when populated with reference data) are
developed. These represent business concepts where the caps are used and
reused.</FONT></SPAN></DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff size=2>To
populate a PLCS database, we have not met needs for postprocessing other
than as defined in the instantiations (the mapping diagrams). This, however,
does not mean that postprocessing is not an added value, but the need should
be carefully assessed before another level of complexity is added to
PLCS.</FONT></SPAN></DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff size=2>To
extract data from the PLCS database, query is used. Again no other need for
preprocessing, and again, carefully assess the need, complexity and
cost benefit..</FONT></SPAN></DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff size=2>We
believe that the exchange specification for import and export technically
is the same, but there may be other reasons why this is not
so.</FONT></SPAN></DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff
size=2>Also, provided pre and post processing is introduced, care should be
taken to distinguish between the generic part and the instantiatied part. I
see the generic parts only as aids to develop the instantiated parts. When
the logistics domain is fully populated with instantiated reference data,
these should be used by all, and the need for the generic capabilities
disappear. Mapping legacy data to PLCS will then be done using the
instantiation diagrams and the instantiated capabilities. Databases and
data exchanges will hold instantiated data (legacy or the reference data
substitution for the legacy data), not generic
capabilities.</FONT></SPAN></DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff
size=2>Knowing well I am operating in troubled water, I still hope this is
to help and not to confuse. If the latter, forget the
mail.</FONT></SPAN></DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff
size=2>Best regards</FONT></SPAN></DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff
size=2>Leif Tonning</FONT></SPAN></DIV>
<DIV><SPAN class=920481511-30042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Tim Turner
[mailto:timturner11@bellsouth.net] <BR><B>Sent:</B> 29. april 2004
20:50<BR><B>To:</B> Tonning, Leif<BR><B>Cc:</B>
rob.bodington@eurostep.com<BR><B>Subject:</B> RE: Pre-post processor
info<BR><BR></FONT></DIV>
<DIV><SPAN class=884433718-29042004><FONT face=Arial color=#0000ff
size=2>Oh um, sorry!</FONT></SPAN></DIV>
<DIV><SPAN class=884433718-29042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=884433718-29042004><FONT face=Arial color=#0000ff
size=2>Well a lot of the early capabilities had sections on pre & post
processor guidence in the main body, underneath the descriptions of the
entity attributes being documented. For example, under representing
assembly structures & BOM there is a section on <A
name=PostprocessorRecommendations><STRONG><FONT face="Times New Roman"
color=#000000 size=3>Postprocessor Recommendations</FONT></STRONG></A>.
However, these sections need to be moved to the usage area (I.e. in
amongst the entity definitions), but I cannot copy the section to that
part as the dtd seems not to allow it. I need to see some sort of example
on how this should be done, or for the dtd to change to enable a simpler
format.</FONT></SPAN></DIV>
<DIV><SPAN class=884433718-29042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=884433718-29042004><FONT face=Arial color=#0000ff
size=2>I believe that I can just delete the attribute sections I have
manually provided since these are already available in the usage
area.</FONT></SPAN></DIV>
<DIV><SPAN class=884433718-29042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=884433718-29042004><FONT face=Arial color=#0000ff
size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=884433718-29042004><FONT face=Arial color=#0000ff
size=2>Tim</FONT></SPAN></DIV>
<DIV><SPAN class=884433718-29042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=884433718-29042004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<BLOCKQUOTE>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Leif.Tonning@dnv.com
[mailto:Leif.Tonning@dnv.com]<BR><B>Sent:</B> 29 April 2004
02:46<BR><B>To:</B> timturner11@bellsouth.net<BR><B>Cc:</B>
rob.bodington@eurostep.com<BR><B>Subject:</B> RE: Pre-post processor
info<BR><BR></FONT></DIV><!-- Converted from text/rtf format -->
<P><FONT face=Arial color=#0000ff size=2>Hi, Tim</FONT> <BR><FONT
face=Arial color=#0000ff size=2>Sorry, I'm not on the net. Probably I
have missed some communication and do not understand what you are
asking. </FONT><BR><FONT face=Arial color=#0000ff size=2>I will do my
best to give you an answer, but need better to understand the
issue</FONT> </P>
<P><FONT face=Arial color=#0000ff size=2>Leif t</FONT> </P>
<UL>
<P><FONT face=Arial><SPAN lang=no></SPAN></FONT><SPAN
lang=no> <FONT face=Tahoma size=1>-----Original
Message-----</FONT></SPAN> <BR><SPAN lang=no><B><FONT face=Tahoma
size=1>From: </FONT></B> <FONT face=Tahoma size=1>Tim Turner
[</FONT></SPAN><A href="mailto:timturner11@bellsouth.net";><SPAN
lang=no><U><FONT face=Tahoma color=#0000ff
size=1>mailto:timturner11@bellsouth.net</FONT></U></SPAN></A><SPAN
lang=no><FONT face=Tahoma size=1>] </FONT></SPAN><BR><SPAN
lang=no><B><FONT face=Tahoma size=1>Sent: </FONT></B> <FONT
face=Tahoma size=1>28. april 2004 20:32</FONT></SPAN> <BR><SPAN
lang=no><B><FONT face=Tahoma
size=1>To: </FONT></B> <FONT face=Tahoma
size=1>Rob Bodington (E-mail); Tonning, Leif</FONT></SPAN> <BR><SPAN
lang=no><B><FONT face=Tahoma
size=1>Subject: </FONT></B>
<FONT face=Tahoma size=1>Pre-post processor info</FONT></SPAN> </P>
<P><SPAN lang=en-us><FONT face=Arial size=2>Guys,</FONT></SPAN> </P>
<P><SPAN lang=en-us><FONT face=Arial size=2>I'm trying to address the
issue of moving much of this information into the usage section, but I
need an example where this has been done that I can
follow.</FONT></SPAN></P>
<P><SPAN lang=en-us><FONT face=Arial size=2>Do you have anything I
could look at?</FONT></SPAN> </P>
<P><SPAN lang=en-us><FONT face=Arial size=2>Cheers,</FONT></SPAN>
<BR><SPAN lang=en-us><FONT face=Arial size=2>Tim</FONT></SPAN>
</P></UL><BR>**************************************************************<BR>Neither
the confidentiality nor the integrity of this message can be guaranteed
following transmission on the Internet. <BR>All messages sent to a DNV
email addressee are swept by Sybari Antigen for the presence of computer
viruses. <BR>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
<BR>**************************************************************
<BR></BLOCKQUOTE></BLOCKQUOTE><BR>**************************************************************<BR>Neither
the confidentiality nor the integrity of this message can be guaranteed
following transmission on the Internet. <BR>All messages sent to a DNV email
addressee are swept by Sybari Antigen for the presence of computer viruses.
<BR>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
<BR>**************************************************************
<BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
<BR>
<BR>
<P><B><FONT SIZE=1 FACE="Arial">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 </FONT></B></P>
<BR>
<BR>
------_=_NextPart_001_01C431B0.B1B96960--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]