semi合集-English.pdf - 第3011页

SEMI E121-0305 © SEMI 2003, 2005 7 8.9.2.2 For this case implementatio n is straight forward. An enumerated list is the cho ice and the list is not extendable. The abov e construct should only b e used where it is clear …

100%1 / 7923
SEMI E121-0305 © SEMI 2003, 2005 6
Rule 2: Do not use the same prefix for more than one XML namespace. Prefixes defined with the same characters
and in the same order are considered the same even when defined in different letter case.
Ex. CMS and cms are equivalent.
8.7.5 Target Namespace
8.7.5.1 When more than one namespace is used in schema definition a target namespace should be defined using the
“targetNamespace” format definition. The target namespace definition should include the elementFormDefault =
“qualified” such that the elements defined within the target namespace are all qualified (in the namespace).
For example:
<schema targetNamespace="urn:semi-org:xsd.E125.V0303.Metadata"
xmlns:CEM = "urn:semi-org:xsd.E120.V0303.CommonEquipmentModel"
xmlns:CMS = "urn:semi-org:xsd.E087.V0304.CarrierManagement"
elementFormDefault="qualified">
</schema>
For web services:
<wsdl:definitions name="ESD" targetNamespace="urn:semi-org:ws.E125-1.V0305.Metadata-portType"
xmlns="urn:semi-org:ws.E125-1.V0305.Metadata-portType"
xmlns:auth="urn:semi-org:xsd.E132-1.V0305.auth"
xmlns:esd="urn:semi-org:xsd.E125-1.V0305.esd"
xmlns:eqmport="urn:semi-org:ws.E125-1.V0305.Metadata-portType"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
</wsdl:definitions>
8.8 Character Sets
8.8.1 Vocabularies (element and attribute names) should be restricted to the ASCII 7-bit character set (ISO-646) in
addition to restrictions imposed by XML and XML Schema on element and attribute names as defined in this
document.
8.8.2 XML Schema and instance documents should use the UTF-8 (ISO-10646) encoding; all other documents
should use the UTF-8 encoding (other encoding types may be used for documents whose intended use is restricted to
locales where the restriction to UTF-8 is inappropriate).
8.8.3 UTF-8 supports the ASCII 7-bit character set and the Unicode character set and is the current default
encoding for SOAP based documents.
8.9 Extensions to Enumeration Lists
8.9.1 As a general guideline fixed enumeration lists should not to be changed with additional values. Extendable
enumeration lists, on the other hand, are defined such that they allow the inclusion of supplier or application specific
choices.
8.9.2 Non-extendable Enumeration Lists
8.9.2.1 When an element or attribute has a fixed list of values it can be assumed that it is necessary to restrict the
list. The reasons for restriction to a fixed list are:
The implementation has a known set of cases to consider.
Variations in spelling, abbreviating, and case use need to be eliminated.
For example, an answer to a question may be either “yes” or “no”. A depth may be either “HI” or “LOW”. A unit of
measure may be one of a long, but finite list of ISO abbreviations.
SEMI E121-0305 © SEMI 2003, 2005 7
8.9.2.2 For this case implementation is straight forward. An enumerated list is the choice and the list is not
extendable. The above construct should only be used where it is clear that the list should be tightly controlled and
only extended as a new version. If a user needs to extend the list they should copy this construct and build their own
schema with the simpleType that contains the new set of values.
When the usage case indicates that the enumerated list should be fixed then a simpleType using enumeration of
values should be used. The elements and attributes that use these values should be local. Extension (or further
restrictions) on the set of values should be done by SEMI with a change in version.
<xsd:simpleType name=”pressureType” final=”#all”> (block=”#all” may also be used)
<xsd:restriction base=”xsd:string”>
<xsd:enumeration value=”HI”/>
<xsd:enumeration value=”LOW”/>
</xsd:restriction>
</xsd:simpleType>
8.9.3 Extendable Fixed Enumerated Lists
8.9.3.1 The term ‘extendable fixed’ is contradictory. However, there is a common usage case suggested for this
situation. This case is where the list is fixed but allows ‘other’ or ‘unknown’ to be specified. In this case, there is no
semantic meaning to the value of ‘other’ or ‘unknown’ except that it states that the given list has not appropriate
values.
In this example a list of process control may include {R2R, FDC, SPC, other}. The instance writer may not want to
use the listed options, and therefore can choose ‘other’ or ‘unknown’ as the value.
8.9.3.2 In this case the semantic meaning of the two values is different. ‘Other’ generally means that there is an
appropriate value but it is not in the list of values that are given. ‘Unknown’ means that the instance writer does not
know the value. The example below illustrates a list where the enumeration “other” defined.
<xs:simpleType name="ProcessType1" block=”#all”>
<xs:restriction base="xs:string">
<xs:enumeration value="R2R"/>
<xs:enumeration value="FDC"/>
<xs:enumeration value="SPC"/>
<xs:enumeration value="OTHER"/>
</xs:restriction>
</xs:simpleType>
When a fixed list may not be inclusive of all possible values, include the value, ‘other.’
When a fixed list is part of a mandatory element or attribute, consider including the value ‘unknown.’
8.9.4 General Extendable Enumerated Lists
8.9.4.1 In the previous section the value ‘other’ is described to be an extension policy. While this allows the user to
say that there is a value other than those in the enumerated list that is appropriate, it does not define ahead of time
what the value is. This is done by introducing a choice value: ‘Other: xxx’. This method allows the user to include
more meaningful information that qualifies the term ‘other’.
8.9.4.2 An example where value is defined which has the pattern ‘Other: \S\S*’, with \S\S* representing a string is
shown below:
<xs:simpleType name="otherNameType">
<xs:restriction base="xs:string">
<xs:pattern value="Other:\S\S*"/>
</xs:restriction>
</xs:simpleType>
8.9.4.3 To make this a union with the simple type whose result is the enumerated list the example for processType
illustrated above can be extended by
SEMI E121-0305 © SEMI 2003, 2005 8
<xs:simpleType name="ProcessType2">
<xs:restriction base="xs:string">
<xs:enumeration value="R2R"/>
<xs:enumeration value="FDC"/>
<xs:enumeration value="SPC"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="extProcessType">
<xs:union memberTypes="ProcessType2 otherNameType"/>
</xs:simpleType>
8.9.4.4 This method allows the writer to use ‘R2R’, ‘FDC’, ‘SPC’ or ‘Other: XXX’. While it does not define the
meaning of the ‘XXX’ it does allow an extension of the values at XML write time. When meanings of the extended
values has been agreed upon this offers a method for incorporating these extended values without requiring schema
changes..
<?xml version="1.0" encoding="UTF-8"?>
<root xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:NamespaceSchemaLocation="C:\standards\XML\E121\ExtensionSample.xsd">
<xyz>FDC</xyz>
<abc>Other:WTW</abc>
</root>
8.9.4.5 Another advantage using this approach is that the ‘Other: WTW’ portion offers a flag to the reading
application. If the reading application recognizes this string then it is aware that an extension is present and is able to
take appropriate action. If this pattern is used consistently in SEMI it will become a standard pattern for the reader.
Since this is a simple type it can be used as either an element value or an attribute value.
8.10 Schema File Naming Convention
8.10.1 Three schema files have been identified for at least each interface that a standard defines. In the case of a
client interface services the three files are: DataTypes.xsd, Client-Binding.wsdl and Client-PortTypes.wsdl. Those
standards that define services for multiple clients as well as for the equipment, several schema files will be defined.
8.10.2 Each defined standard that requires multiple interfaces to communicate shall provide a set of properly named
schema files depending whether those services are intended for the equipment or for a particular client. Figure 1
shows an example of these schema files.
E132 SecurityAdmin
E132-SecurityAdmin-PortType.wsdl
E132-SessionClient-PortType.wsdl
E132-SecurityAdmin-Binding.wsdl
E132 SessionManager
E132-SessionManager-PortType.wsdl
E132-SessionManager-Binding.wsdl
E132-Schema.xsd
E132-SessionClient-Binding.wsdl
E132 SessionClient
Figure 1
Example of Schema File Organization
8.10.3 The following convention will be used with SEMI standards:
<Standard Name>-<Version>[-<Service Role>]-<Schema Classification>.<Schema Type>