semi合集-English.pdf - 第3636页

SEMI E139.1-0705 © SEMI 2005 12 7.1.5 Added XML Constr ucts 7.1.5.1 In the process of translating the UML model for t he PDE into a useful XML schema, is was necessary to add certain types and constructs to the schema. T…

100%1 / 7923
SEMI E139.1-0705 © SEMI 2005 11
Figure 8
PDEparameter
7.1.4.8 PDEbody
7.1.4.8.1 The PDEbody class is mapped to the XML complexType also named PDEbody. Table 9 shows that the
PDEbody is of type xs:any. This type allows the implementation to place elements and attributes in an instance of
PDEbody without restriction. The resulting XML structure is illustrated in Figure 9.
Table 9 Translation Table For PDEbody
Attribute or Role Name UML Type
XML Element or Attribute
(or Reference)
XML Name/Type
none n/a element or attribute [0..] user defined
Figure 9
PDEbody
7.1.4.9 PDEbodyReference
7.1.4.9.1 The PDEbodyReference class is mapped to the XML complexType also named PDEbodyReference.
Table 10 shows how the attributes of PDEbodyReference are mapped to XML. The resulting XML structure is
illustrated in Figure 10.
7.1.4.9.2 See ¶7.2.1 for instructions on the calculation of the value of the bodyChecksum element.
Table 10 Translation Table For PDEbodyReference
Attribute or Role Name UML Type
XML Element or Attribute
(or Reference)
XML Name/Type
bodyChecksum Checksum element bodyChecksum (simpleType Checksum)
specification String element specification (simpleType xs:string)
Figure 10
PDEbodyReference
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)