semi合集-English.pdf - 第3637页

SEMI E139.1-0705 © SEMI 2005 13 o Convert the modified PDE element to its ca nonical form according to W3C rec ommendation xml-c14n without comments (that is, the “with comments” op tion is not used). This yields an octe…

100%1 / 7923
SEMI E139.1-0705 © SEMI 2005 12
7.1.5 Added XML Constructs
7.1.5.1 In the process of translating the UML model for the PDE into a useful XML schema, is was necessary to
add certain types and constructs to the schema. This section describes these XML constructs.
7.1.5.2 XML simpleTypes
7.1.5.2.1 Table 11 describes each simpleType
2
added to the PDE schema.
Table 11 simpleTypes In The PDE Schema
Type
Description
UUID
Holds a standard 36-character uuid string. The pattern is defined as five groups of
characters, each separated by the “-“ character. Here is an example value in UUID format:
“44BBA855-CC51-11CF-AAFA-00AA00B6015C”.
Checksum
Holds a 128-bit MD5 checksum value. The simpleType is hexBinary – 32 characters
representing 4 bits each (16 bytes).
InputBoundsType
This construct defines the enumerated choices (List or Range) needed for the attribute
inputBoundsType of PDEparameter.
7.1.5.3 Added XML complexTypes
7.1.5.3.1 Table 12 describes each complexType
2
added to the PDE schema.
Table 12 complexTypes In The PDE Schema
Type
Description
ListOfStrings Holds a collection of zero or more strings.
7.2 Requirements For PDE Schema
7.2.1 This section contains all requirements specified for the PDE Schema. ¶7.1 above is included for
documentation purposes.
7.2.2 Checksum Calculation
7.2.2.1 The method for calculation of checksum values is specified by the SEMI E139 RaP standard to be MD5.
The MD5 calculation processes a sequence of bytes (or octets) to yield the checksum value. This section specifies
that sequence of bytes for the PDE and external PDEbody.
7.2.2.2 PDE Checksum
7.2.2.2.1 The PDE checksum element value shall be calculated based on the XML instance document for the PDE.
This applies to PDEs that have internal PDEbodies and also to those that do not.
7.2.2.2.2 XML documents can contain white space and layout information that is independent of the XML content.
So, two XML documents that have identical XML content might not be identical byte for byte. Allowance has been
made for these differences.
7.2.2.2.3 The W3C recommendation xml-c14n (
http://www.w3c.org/TR/xml-c14n
) defines a method for creating a
canonical form of an XML document. This canonicalization process eliminates the white space and layout
information from the checksum calculation. The xml-c14n recommendation shall be applied in the following way:
The checksum calculation shall be performed on a canonicalized form of the RaP:PDE element. The
computation of the checksum shall be equivalent to the procedure described below:
o In the RaP:PDE element of the original PDE replace the value of the 'checksum' element by
00000000000000000000000000000000 (that is, 32 zeroes).
2 “simpleType” and “complexType” are XML terms (see also “xs:simpleType” and “xs:complexType”).
SEMI E139.1-0705 © SEMI 2005 13
o Convert the modified PDE element to its canonical form according to W3C recommendation xml-c14n
without comments (that is, the “with comments” option is not used). This yields an octet stream encoded in
UTF-8.
o Apply the MD5 algorithm to the resulting octet stream to compute the checksum.
7.2.2.2.4 The resulting checksum value can be used as needed. For example, if a new PDE is being created, the
value may be placed into the checksum element. For an existing PDE, the value may be compared with the existing
value of the checksum element to determine if the content is unchanged.
7.2.2.3 PDEbody BodyChecksum
7.2.2.3.1 The format of an external PDEbody is determined by the equipment supplier. In this case, the entire
PDEbody content as contained within TransferContainer shall be included in the checksum calculation process. The
calculation method for the bodyChecksum attribute of the PDEbodyReference element is MD5 as specified by the
E139 RaP standard.
7.2.3 XML Schema
7.2.3.1 All PDE instance documents shall conform to the XML schema document named:
E139-1.V0705.RaP.PDE.xsd
7.2.3.2 The contents of the above-mentioned schema document constitute a core part of this specification. This
schema document should be provided with this document.
7.2.3.3 In addition, all PDE instance documents shall conform to all requirements related to the PDE content as
specified in SEMI E139.
8 Manifest Schema Definition
8.1 Manifest Mapping to XML
8.1.1 This section describes how the Manifest definition from SEMI E139 is mapped to XML. The descriptions in
this section are provided to support and explain the XML schema document (attached, see ¶8.2). This section
contains no requirements. Specific requirements are included in ¶8.2.
8.1.2 Manifest Class
8.1.2.1 SEMI E139 does not represent the Manifest in UML. To facilitate creation of the Manifest schema, the
Manifest itself is treated as a single class containing an unordered sequence of Entries.
8.1.2.2 The first two columns of the Translation Table for this Manifest class (Table 13) hold little information
because this class was not explicitly defined in SEMI E139. However, the second two columns describe the XML
form of the Manifest class. Figure 11 shows the XML form of the Manifest.
Table 13 Translation Table For Manifest Class
Attribute or Role
Name
UML Type
XML Element or Attribute (or
Reference)
XML Name/Type
<none> <none> element Manifest (complexType)
<none> <none> element Entry (complexType)
<none> UUID element uid (simpleType UUID)
<none> String element PDEdescriptor (simpleType xs:string)
<none> String element PDEbodyDescriptor (simpleType xs:string)
<none> String element location (simpleType xs:string)
SEMI E139.1-0705 © SEMI 2005 14
Figure 11
Manifest
8.1.3 XML simpleTypes
8.1.3.1 Table 11 describes each simpleType added to the XML schema for the Manifest.
Table 14 simpleTypes In The PDE Schema
Type Description
UUID Holds a standard 36-character uuid string. The pattern is defined as five groups of characters, each
separated by the “-“ character. Here is an example value in UUID format: “44BBA855-CC51-11CF-
AAFA-00AA00B6015C”.
8.2 Requirements For Manifest Schema
8.2.1 This section contains all requirements specified for the PDE Schema. ¶8.1 above is included for
documentation purposes.
8.2.2 All Manifest instance documents shall conform to the XML schema document named:
E139-1.V0705.RaP.Manifest.xsd
8.2.3 The contents of the above-mentioned schema document constitute a core part of this specification. This
schema document should be provided with this document.
8.2.4 In addition, all Manifest instance documents shall conform to all requirements related to the Manifest content
as specified in SEMI E139.
9 Related Documents
Rivest, Ronald, The MD5 Message-Digest Algorithm,
IETF RFC: 1992 http://www.ietf.org/rfc/rfc1321.txt.
NOTICE: SEMI makes no warranties or representations as to the suitability of the standards set forth herein for any
particular application. The determination of the suitability of the standard is solely the responsibility of the user.
Users are cautioned to refer to manufacturer's instructions, product labels, product data sheets, and other relevant
literature, respecting any materials or equipment mentioned herein. These standards are subject to change without
notice.
By publication of this standard, Semiconductor Equipment and Materials International (SEMI) takes no position
respecting the validity of any patent rights or copyrights asserted in connection with any items mentioned in this
standard. Users of this standard are expressly advised that determination of any such patent rights or copyrights, and
the risk of infringement of such rights are entirely their own responsibility.
Copyright by SEMI® (Semiconductor Equipment and Materials
International), 3081 Zanker Road, San Jose, CA 95134. Reproduction of
the contents in whole or in part is forbidden without express written
consent of SEMI.