semi合集-English.pdf - 第3010页

SEMI E121-0305 © SEMI 2003, 2005 6 Rule 2: Do not use the sam e prefix for more than one XML na mespace. Prefixe s defined with the same characters and in the same order a re considered the same even when defined in diff…

100%1 / 7923
SEMI E121-0305 © SEMI 2003, 2005 5
8.7.3.4 The <NSS> syntax is limited to upper or lower case characters followed by upper lower characters including
a hyphen “-“ . The <NSS> is composed of more than one field and each field is separated by a period as shown
below. No other characters than the ones shown are allowed and should be considered reserved.
<NSS> ::= <XML Domain>”.”<SEMI Domain>”.”<Version>”.”<Name>
<XML domain> ::= <Letter> [ Letter-Number-Hyphen]
<SEMI Domain> ::= <Letter> [ Letter-Number-Hyphen]
<Version> ::= <Letter> [ Letter-Number-Hyphen]
<Name> ::= <Letter> [ Letter-Number-Hyphen]
8.7.3.5 <XML Domain> — A XML domain needs to be included to explain whether this is a schema (xsd) or a web
service (ws) by using the following format: <XML domain> = “xsd” for schema or “ws” for web service.
8.7.3.6 <SEMI Domain> or <Company Domain> — Include in the SEMI domain identifier the standard number as
assigned by SEMI. For example, Specification for Carrier Management = “E087”. In those cases where the standard
has not been approved but a formal document number has been assigned, use this number instead. For example,
Equipment Diagnostic Interface = “Doc3563”. When the definition is from a third party use the defined company
domain. For example, Etch equipment = “EtchTool” or “Model-3731-134”.
8.7.3.7 <Version> — Properly identifying the revision level of the schema and it is required when there is an
approved version of the standard the namespace definition should include the date that corresponds to the standard
release date or when it was approved. Dates are represented as month (mm) and year (yy) and use the “Vmmyy”
format. This field is not required when SEMI standards are non-existent. For third party applications it is
recommended that the “Vx-x” form be used. For example, 2001 Feb = “V0201” or for Version 2.1 = “V2-1”
8.7.3.8 <Name> — This label corresponds to the actual name of the document to which the namespace belongs.
For metadata definitions include the descriptive name of the schema using upper camel case. Ex.
CarrierManagement, EquipmentDiagnosticAcquisition, EquipmentMetadata, etc. For web services, the <Name>
includes the service or interface role and whether it corresponds to the “binding” or the “portType” definition. (See
UDDI Version 3 from OASIS for WSDL structure).
Examples of valid representations of namespaces are:
“urn:semi-org:xsd.E087.V0702.CarrierManagement”
“urn:semi-org:xsd.Doc3509.V12.DataCollectionManagement”
“urn:supplierXX-com:EtchTool.V07.Model123”
“urn:semi-org:ws.E132-1.V0305.SessionManager-binding”
“urn:semi-org:ws.E125-1.V1104.MetadataManager-portType”
Examples of invalid representation of namespaces are:
“urn:semi.org:xsd.Doc3509.V12.DataCollectionManagement” (Invalid use of period in <SEMI Domain>)
“urn:semi-org:xsd.E087.V7.22.CarrierManagement” (Invalid use of period in <Version>)
8.7.4 Multiple Default Namespaces
8.7.4.1 When more than one namespace is used in an XML document or schema, a prefix shall be defined for each
of the namespaces that uniquely identifies the elements that belong to each of the namespaces. This prefix is used to
specify that a local element or attribute name belongs to a particular namespace. These prefixes are used to override
attribute values and must be documented by the supplier of the application. The following rules apply to prefixes:
Rule 1: Prefixes should be defined in all uppercase or all lower case letters but not both.
Ex: <Definition xmlns: CMS=”urn:semi-org:xsd.E087.V0201.CarrierManagement”>
<CMS:Data> abcd </CMS:Data>
<CMS:Data> xyze </CMS:Data>
</Definition>
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