[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs] Extend scope of C001 Assigning_identifiers?
I’ve been trying to follow this and now think I understand what this is about… the PLCS DEX team is re-discovering the STEP architecture. Only now:
DEX = Integrated Resource Schema
Specialized DEX = AIM short form selecting subset of DEX resource schema
Instantiated DEX = AIM short form plus Rules, reference data and specific implementation guidance.
Next you’ll find you need to formally represent the business concepts (ARM application objects) and define their relationship to your DEX (mapping table).
If you’re going to do all that, you might as well use something closer to STEPMod rather than how DEXLib works.
We go ‘round and ‘round…
Cheers, David
-----Original Message-----
MartinIt is a question to which degree we need "specialized" DEXs and capabilities, this is something we have to sort out. The objective for the definitions below (documented in DEXLib introduction) is to reduce the amount of Exchange agreements to a minimum. This will reduce the need for special tailoring of translators. The objective is to reduce implementation costs. By standardizing "instantiated" DEXs and capabilities we eliminate the abstraction level and introduce a simplification that will make implementations more effective.We are of course open for ideas that help to reduce quantity of instantiated capabilities and DEXs.It seems like we have a choice between two different regimes for PLCS implementations. One is to use the current level of precision in DEXLib. This will require extensive use of exchange agreements and translator tailoring for new exchanges. DEX000 (DEX Template proposal) offers a solution to reduce cost and time delay for new exchange scenarios.DEX typesThree levels of DEX precision may apply in order to specify a data exchange set. · Generic DEXs define a comprehensive data exchange set that inherently captures a number of specific data exchange ideas. A generic scope opens for usage that is not planned or documented. Many applications, and translators, will not be able to handle a generic scope. · Specialized DEXs normally consists of a subset of the capabilities of the generic DEX. Often DEX specifications will be redundant. The generic and the specialized DEX may be identical. A specialized DEX represents a family of business data exchange requirements with identical data model structure. · Instantiated DEXs define outer leaf data exchange specifications for single business data exchange requirements (ideas) that shall be equally understood at both sides of an exchange. Instantiated DEXs are hence specializations of generic (or specialized if existing) DEXs, representing each single family member. An instantiated DEX may contain all or a subset of the entities of the generic DEX. Capability typesThree levels of capability precision apply in order to identify the outer leaf reference data, constraints and rules needed to interpret specific business concepts. · Generic capabilities define the interpretation of the ARM schema of ISO 10303-239 to fulfil business requirements for information representation. · Specialized capability normally consists of a subset of the entities of the generic capability. In some cases, the generic and the specialized capability will be identical. A specialized capability represents a family of business concepts with identical data model structure. It therefore normally is more precise than the generic capability · Instantiated capability uses the same subset of entities as the specialized capability. An instantiated capability defines the business concept as the single family member of the specialized capability, with no room for ambiguity. In reality, an instantiated capability is a further specialization of the population of a specialized capability. (a) Short forms of instantiated capabilities shall compose the short form of the instantiated DEX for generation of the DEX longform. Only instantiated capabilities shall be used by a DEX (b)The specific rules and reference data of instantiated capabilities and DEXs shall be added to the DEX shortforms. Regarding your concerns: The situation shall to be the opposite of the scenario you describe. DEXs and capabilities will be re-used in different business scenarios. DEXs and capabilities shall reflect commonly used business data exchange concepts at a level that is not subject to interpretation. For example, the "Allowance part list" is a commonly known business obcejct wich is subject to exchange. This concept must be identically understood and interpreted by exchange parties. The instantiated capabilities and their constraints in this DEX will be reused in several DEXs. Further development of DEXLib tool is needed to manage the large amount of concepts (Indexing machanism). We do not propose any changes to the original idea with the DEX architecture. The only difference is that we introduce a more detailed specification to eliminate possible ambiguities. The capabilities shall be re-used and shall be the main bulding blocks for the DEXs. Use of reference data will distinguish the usage of the instantiated capabilities in different DEXs.
Regards Trine
From: Gibson, Martin
[mailto:ils-de@a.dii.mod.uk] Trine,
Notwithstanding the recommendations resulting from the DEX Sync meetings, and so that we all know (or think that we know) what we're talking about before we get to the meeting please could you provide us with your definitions of the following:- 1) Generic DEX 2) Specific DEX 3) Instantiated DEX 4) Specialised capability 5) Instantiated capability
I also have some concerns though. If I correctly understand your logic and line of thought, it seems that we would ultimately end up with a standardized DEX containing standardized capabilities for each and every data exchange scenario that might exist in any given business domain. The logical consequence of this would be that any particular DEX implementation would inevitably be different from virtually any other DEX implementation, making every AP239-based system incompatible with every other AP239-based system. This is surely not what was originally envisaged.
Regards,
Martin
Martin Gibson
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]