semi合集-English.pdf - 第3008页

SEMI E121-0305 © SEMI 2003, 2005 4 8.4.1.3 Acronyms shou ld be all in uppercase. Followi ng a Three (or more) Letter Acronym (TLA), all in uppercase, the next letter is lowercase , i.e.: TLAlowercase, not TLAUppercase. 8…

SEMI E121-0305 © SEMI 2003, 2005 3

6.2.9 Simple Object Access Protocol 1.1 — W3C Note, 8 May 2000 (SOAP, http://www.w3.org/TR/SOAP)

6.2.10 Web Service Definition Language 1.1 — W3C Note, 15 March 2001 (WSDL, http://www.w3.org/TR/wsdl)

6.2.11 ISO/IEC 11179 (1-6) Information Technology — Standardization and Specification of Data Elements

7 XML Three Tier Model Architecture

7.1 The following three-tier schema model is recommended:

 Primary Schemas (common SEMI models)

 Secondary Schemas (individual SEMI models)

 Tertiary Schemas (non SEMI models)

7.1.1 Primary Schemas — Primary Schemas are schemas that have been defined by SEMI. These schemas usually

cover a particular area such as equipment, transport system, scheduler/dispatcher, maintenance, etc.

7.1.2 Secondary Schemas — Secondary Schemas are schemas that have been defined by SEMI. These schemas are

for a particular functionality required by the application such as carrier management, process job, data collection,

etc. Secondary Schemas may derive from Primary Schemas as a base by extension or restriction.

7.1.3 Tertiary Schemas — Tertiary Schemas are defined by the supplier of the tool or application. These Schemas

may derive from either Primary or Secondary Schemas as a base by extension or restriction.

8 XML Recommendations

8.1 XML Document Compliance

8.1.1 All XML documents, by definition, must comply with the W3C Recommendation, XML version 1.0 (see

http://www.w3.org/TR/REC-xml for more detail on the specification). The purpose of this compliance is to assure

that all XML documents are “well-formed” and “valid”. A “well-formed” document means that there is exactly one

root element, all sub-elements (and recursive sub-elements) have delimiting start- and end-tags, and that they are

properly nested within each other. A “well-formed” document also conforms to the XML syntax specification and

does not include external references unless a schema reference is provided. An XML document is “valid” if it has

an associated schema and complies with the constraints expressed in the schema. “Valid” XML data is also “well-

formed”.

8.2 Use of XML Schema versus DTD

8.2.1 All XML documents should conform to a specified set of production rules. These production rules should be

specified as XML Schemas. XML Schemas are the preferable way to define XML documents. XML Schemas are

modular in structure and can be built from multiple components (files) by including or importing the components.

8.3 Using Elements versus Attributes

8.3.1 When defining attributes from an object model, it is preferable to define them as XML elements such that they

can be easily extended by other applications.

8.3.2 Use elements if the information is hierarchical, contains a content model, or could potentially become more

complex or hierarchical in the future.

8.3.3 Use attributes when the information is metadata about the element.

8.4 Naming Conventions

8.4.1

The following list is a compendium of recommended practices to be used when naming attributes and simple

or complex elements.

8.4.1.1 Use the UpperCamelCase convention for elements and the lowerCamelCase convention for attributes.

8.4.1.2 Do not use any punctuation in the element name; i.e. underscores, dashes, etc. Use only alphanumeric

characters.

SEMI E121-0305 © SEMI 2003, 2005 4

8.4.1.3 Acronyms should be all in uppercase. Following a Three (or more) Letter Acronym (TLA), all in

uppercase, the next letter is lowercase, i.e.: TLAlowercase, not TLAUppercase.

8.5 Common XML Structures

8.5.1 When defining a list of elements where each has the same element name, nest the list of elements inside a

parent element. Form the parent’s element name by concatenating the name of the list elements with the word

“List”.

8.5.1.1 For example:

<SubstrateID>Substrate1</SubstrateID>

<SubstrateID>Substrate2</SubstrateID>

<SubstrateID>Substrate25</SubstrateID>

</SubstrateIDList>

8.6 Schema Element Organization — The following recommendations apply only to the Primary and Secondary

Schemas.

8.6.1 With the purpose of readability of the schema and to aid in the understanding of the XML document, the

following guidelines are recommended when elements are defined in the XML document or schema:

8.6.1.1 Elements of type ID or KEY should be listed at the top of the schema, and elements of type IDREF or

KEYREF should be listed second.

8.6.1.2 Elements of simpleType should be declared first, followed by elements of complexType.

8.7 XML Namespaces

8.7.1 A namespace name is a URI (Universal Resource Identifier) that uniquely identifies the namespace. A

namespace is a group of names usually with a related purpose and context. The namespace is a globally unique

name. This is ensured by using a domain names as part of the namespace definition or a pre-determined identifier.

SEMI documents will use the URN (Universal Resource Naming) convention to define namespaces,

suppliers or

any other 3

party suppliers can use either URN or URL (Universal Resource Locator) descriptions.

8.7.2 Each application or document definition is responsible for providing a namespace for the extension of its

vocabulary definition. A namespace must be unique and to ensure its uniqueness the definitions of namespaces must

follow the rules described below.

8.7.3 Namespace Syntax

8.7.3.1 SEMI Namespaces use Uniform Resource Names (URNs). All URNs have the following syntax:

8.7.3.2 Where <NID> is the namespace identifier and <NSS> is the namespace specific string. The <NID> syntax

is limited to upper or lower characters followed by upper or lower characters including a hyphen “-“.

<NID> ::= <Letter> [<Letter-Number-Hyphen>]*

<Letter-Number-Hyphen> ::= <upper> | <lower> | <number> | “-“

8.7.3.3 The namespace identifier is case insensitive thus “ABC” and “abc” refer to the same namespace. All SEMI

defined namespaces will use <NID> ::= “semi-org”.

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.

<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>