RE: [plcs-dex] Alternative representation of Parts List

[Tim Turner <timturner11@bellsouth.net>]

Leif,

thanks for the notes. I agree that there is an issue to be resolved here,
but I really would like to get some of the basics out the way with first.

To be explicit about the conclusion regarding the representation of Part
lists, I believe it was agreed that given a documented requirement for the
business concept, that this may form a conformance class (CC) within a Dex
or an option within a CC where there might be alternative representations to
provide the same information.

The conformance classes are to be defined against capabilities and the
entities required. The obvious Dex to use is Dex1, from the design
perspective for the Part list. The architecture slide from the meeting notes
(dist. by Trine) scopes out this (but does not refer to conformance
classes).

There has been no discussion on the range of conformance classes as yet -
this is the first, but there needs to be some thought into the organisation
& structuring of CC's and any options within. 

Options have been used in a number of protocols already (e.g. AP227 ed2) &
generally used in large APs to reduce the number of CC's that would
otherwise be present. Options are usually used to specify one of a number of
possible representations used within a CC. For example, geometry; I can
exchange the same product data & geometry using wireframe, breps or solid.
Hence I may have 3 different options within the CC. A 4th one might include
the possibility of all. 

I will load up a PDF of 227ed2 conformance classes which uses options onto
the Oasis site.

With respect to the different manner in which a parts list can be
represented, I would first of all like to gain agreement upon accepted (or
otherwise) views of what a part list is. My personal preference is to use
the examples and definitions as documented in the PDM Usage Guide since we
know these to have been tested and currently in-use by those who have
implemented this schema.  

C003 was aimed at documenting the same examples but using the PLCS model
rather than the PDM Schema. I admit that there is some overlapping
terminolgy with what should be business concept - driven, but this was the
reference material which PLCS chose.

On a related note, AP203 encompasses the PDM schema and a set of recommeded
practices have been drafted. These extend the concepts discussed within the
PDM schema usage guide and probably need review by anyone anticipating
representing a parts list. I will also load this onto the Oasis site. I
believe that these may well be a good starting point and we may need to
either accept them as guiding principles & to adapt them for PLCS, or to
reject them with some argument as to why.

Perhaps there ought to be a team set up to review this material, capability
C003, the NDLO material and the options you have outlined. 

kind regards,
Tim



-----Original Message-----
From: Gyllström Leif [mailto:leif.gyllstrom@aerotechtelub.se]
Sent: 07 March 2005 07:13
To: plcs-dex@lists.oasis-open.org
Subject: [plcs-dex] Alternative representation of Parts List 


Hi

At the Lillehammer meeting we had a lot of discussions regarding Parts List,
and whether it
should be a separate DEX, or a capability, or .... However, I think we
concluded on that.

However, I still think there is a practical issue that we have to resolve
and that is HOW
a Parts List should be represented in a data exchange based the PLCS data
model. 
My concern does not just adress the Parts List issue, but practically any
other exchange
of documented results such as a FMECA analysis report, a Maintenance plan
etc etc.

In the attached document I've provided four different approaches on HOW a
documented
result (e.g. Parts List) could be represented in a data exchange. (And there
might be more)

I think we have to conclude on one approach which will be generic enough to
cater
for any type of documented result.

Any thoughts ?? 

It might even be a combination of the four approached that would be the best
solution
such as a combination of #1 and #4.

Regrads

Leif Gyllström


 <<Four alternatives for Part List representation.doc>>

<<attachment: winmail.dat>>