基本介紹
- 中文名：ISO-10303-21
- 形式：數據交換
- 舉例說明：ISO-10303-21;
- 定義 ：交換結構的明碼文本內碼
定義,舉例說明,倒栽跳水部分,數據部分,歷史,外部連結,
定義
ISO 10303-21 步檔案 是最用途廣泛的數據交換的形式 步. 由於它 ASCII 結構它是容易閱讀的以典型地每條線一個事例。 步檔案的格式在ISO 10303-21中被定義 交換結構的明碼文本內碼. ISO 10303-21定義了內碼機制關於怎樣根據指定的代表數據 明確圖解，但不是明確圖解。 步檔案也叫 p21檔案 並且 步物理檔案. 檔案擴展名 .stp 並且 .step 表明檔案包含數據符合步套用協定。
舉例說明
一個典型的例子如下所示:
ISO-10303-21;倒栽跳水;
FILE_DESCRIPTION ( /*描述* (‘一個最小的AP214例子以單件’)，
/* implementation_level * ‘2; 1’);
FILE_NAME ( /*名字* ‘演示’，/* time_stamp * ‘2003-12-27T11 ：57 ：53’，
/*作者* (‘Lothar Klein’)，
/*組織* (‘LKSoft’)，
/* preprocessor_version * "，
/* originating_system * ‘IDA-STEP’， /*授權* ");
FILE_SCHEMA ((‘AUTOMOTIVE_DESIGN {1 0 10303 214 2 1 1}’));
ENDSEC;
數據;
#10=ORGANIZATION (‘O0001’， ‘LKSoft’， ‘公司’);
#11=PRODUCT_DEFINITION_CONTEXT (‘部分定義’， #12， ‘製造業’); #12=APPLICATION_CONTEXT (‘機械設計’);
#13=APPLICATION_PROTOCOL_DEFINITION ("， ‘automotive_design’， 2003年， #12); #14=PRODUCT_DEFINITION (‘0’， $、#15， #11);
#15=PRODUCT_DEFINITION_FORMATION (‘1’， $， #16);
#16=PRODUCT (‘A0001’， ‘測試第1部分’， "， (#18)); #17=PRODUCT_RELATED_PRODUCT_CATEGORY (‘部分’， $， (#16));
#18=PRODUCT_CONTEXT ("， #12， ");
#19=APPLIED_ORGANIZATION_ASSIGNMENT (#10， #20， (#16));
#20=ORGANIZATION_ROLE (‘id所有者’);
ENDSEC;
END-ISO-10303-21;
倒栽跳水部分
您能從在檔案之上的舉例子看被分裂成二個部分從事最初的主題詞 ISO-10303-21;:
倒栽跳水部分 有一個固定的結構包括的3到6小組在被發布的命令。 除了數據域 time_stamp 並且 FILE_SCHEMA 所有領域也許包含空字元串。
FILE_DESCRIPTION 描述 implementation_level. 這個檔案的版本和依照選擇。 可能的版本是1為原始的標準後面1994年， 2為技術錯誤1995年和3為再版。 依照選擇是二者之一1為內部和2為外在映射複雜個體事例。 您這裡經常將發現價值__ ‘2; 1’ __。 價值‘2; ’強制執行外部映射的2也是可能，但只很少使用。 價值‘3; 1’和‘3; 2’在2001標準表明延長的步檔案如被定義與幾數據部分、多個圖解和FILE_POPULATION支持。 FILE_NAME 名字 這個交換結構。 它在這個檔案也許對應於檔案的名字在檔案系統的或反射數據。 沒有嚴密的規則如何使用這個領域。 time_stamp 當這個檔案被創造了，表明時候。 時間在內部數據時間格式ISO 8601中被測量，即。 2003-12-27T11 ：57 ：53 為27 2003年12月， 2分鐘到中午時間。 作者 創造這個交換結構的人的名字和郵寄的地址 組織 人屬於的組織 preprocessor_version 生產這個步檔案系統和它的版本的名字 originating_system 最初創造信息系統和它的版本的名字在這個步檔案包含了。 授權 批准這個檔案人的名字和郵寄的地址。 FILE_SCHEMA. 為版本2僅一個明確圖解與圖解的對象標識符一起可以這裡被列出。 從版本3在此為幾個詞條是輕鬆。
最後3個倒栽跳水小組從版本3隻合法的打開。
FILE_POPULATION，表明conformas對明確圖解的合法的人口(設定個體事例)。 這由另外收集數據完成從幾data_sections和參考事例從其他數據部分。 governing_schema明確圖解被表明的人口屬於，並且由哪些它可以被確認 determination_method 推測事例屬於人口。 三mehods被預定義： SECTION_BOUNDARY、INCLUDE_ALL_COMPATIBLE和INCLUDE_REFERENCED。 governed_sections個體舉例的數據部分充分地屬於人口。 FILE_POPULATION的概念是非常緊挨SDAI schema_instance。 不幸地在標準化過程期間達到協定得到這些概念充分地同步是不可能的。 所以JSDAI增加進一步屬性到FILE_POPULATION作為聰明的評論報導所有缺掉信息從schema_instance。 這為兩個，進口和出口支持。 SECTION_LANGUAGE準許分配預設語言為所有或為一個具體數據部分。 這為在的那些明確圖解是需要的例如名字和描述給個體哪些語言串屬性不提供有能力指定。 SECTION_CONTEXT提供有能力為所有或唯一數據部分指定另外的上下文信息。 可以使用這即。 為步APs表明哪依照類由一個特殊數據部分包括。
數據部分
數據 部分根據一個具體明確圖解包含套用數據。 這數據內碼根據一些簡單的原則。
事例名字： 在交換結構給每個個體事例一個唯一名字以形式“#1234”。 事例名字必須包括一個正數(>0)並且是典型地少於2. 事例名字在步檔案之內當地只是合法的。 如果同一個內容從系統再被出口事例名字也許是不同的為同樣事例。 事例名字也使用通過屬性值或聚集成員參考其他個體事例。 參考事例由在當前事例前後被定義。 唯一個體數據類型事例通過用大寫字母寫個體的名字在括弧之內代表由屬性值然後跟隨在被定義的順序。 看見即。 “#16=PRODUCT (...)”上述。 複雜個體數據類型事例在步檔案代表通過使用內部映射或外在映射。 外部映射，如果複雜個體事例包括超過一事假個體，總有使用。 所有唯一個體事例價值從彼此以字母順序獨立地在這種情況下被測量如上所定義以括弧內一起被編組的所有個體價值。 當複雜個體事例只包括一事假個體時，默認情況下內部映射為依照選擇1使用。 內碼是相似的到那個一個唯一個體事例以子型定義發布的另外的命令。 映射屬性值： 僅明確屬性得到映射。 因為他們的價值可以從其他部分，被推論相反，獲得的和再宣稱的屬性不是列出的。 未裝配屬性值被給和“$". 在子型得到再宣稱如獲得的明確屬性被輸入和“*“在supertype屬性的位置。 映射其他數據類型： 列舉，布爾和邏輯值用大寫字母測量與一個帶領的和落後的小點例如“.TRUE.". 字元串值被測量在““。 對於字元以代碼大於126一個特別內碼使用。 如在ISO 8859和10646中被定義支持字元集。 注意，典型8 (即。 西歐人)或16個(Unicode)位字元集不可能為步檔案串直接地被採取。 他們必須被解碼用一個特別方式。 整數和真正的價值與典型的程式語言是半新相同的 聚集體的元素(設定，請求，列出，列陣)在括弧里被給，分離由“,". 必須為根據被定義的數據類型的精選的數據類型保重。 被定義的數據類型的名字這裡達到目的也是映射。 為此的更多細節參見“映射明確對Java”。
歷史
有些細節照料：
ISO 10303-21的初版：1994有有些臭蟲和得到固定由一個技術錯誤。 如果您想要學習這個標準您更好讀… 再版ISO 10303-21 ：2002年，包括所有固定和引伸為幾個數據部分。 第21部分定義了二依照類。 他們在怎樣僅不同輸入複雜個體事例。 總使用的依照類1強制執行所謂 內部映射 哪些是更加緊湊的。 沒有得用於的依照類2實踐強制執行 外在映射 總。 在理論，因為後處理也許會處理一些supertypes，但可能不知道指定的子型，這將允許更好的AP互用性。 第21的第1編輯部分強制執行對所謂的短的名字的用途。 哪些是任意的在第2編輯。 今天實踐上沒有使用短的名字。 第2編輯考慮到幾個數據部分。 在只實踐一個數據部分使用(第1個編輯內碼)
外部連結
步指南 詳細步驟檔案文獻 [! 它不是步文獻，它是PDM (產品數據管理)圖解描述，雖然用步表達…!]
