semi合集-English.pdf - 第1558页

SEMI E36-0704  1995, 2004 5 module to m odule, and in fact t hat is the int ent of the parameter entity framework, all name definitions and use will be consisten t throughout the SEMI E36 DTD suite. This means that name…

SEMI E36-0704  1995, 2004

or follow the markup rules defined in Semiconductor

Equipment Manufacturing Information Tagging.

4.15 SGML - SGML is “Standard Generalized Markup

Language.” The Standard Generalized Markup

Language is an International Organization for

Standardization (ISO) standard. The ISO Reference

Number is ISO 8879:1986(E). SGML is a meta-

language for constructing markup. See also XML

(Extensible Markup Language).

4.16 Tag - A tag is a string of characters delimited by

rules set out in the SGML standard (and used in XML

and HTML). Tags are placed in the datastream to

indicate where an element begins and ends. In

Semiconductor Equipment Manufacturing Information

Tagging, tags match as closely as possible the names of

the elements in English.

4.17 XLL (Extensible Linking Language) - When

released, XLL is intended to be the syntax and

semantics for both simple hypertext linking (as

exemplified by HTML) and more complex linking,

providing such functionality as multi-way links, multi-

ended links, and addressing from an external document

based on structure. A W3C Working Group is in the

process of producing a draft specification, which uses

many of the concepts from HyTime

(Hypermedia/Time-based Document Representation

Language ISO/IEC 10744) and the TEI (Text Encoding

Initiative) extended pointers.

4.18 XML (Extensible Markup Language) - XML is a

W3C Recommendation that describes a subset of

SGML syntax and functionality intended for use on the

World Wide Web. XML is, by design, simpler, less

complex, and easier to implement than SGML. XML is

also, by design, far less flexible than SGML because it

includes only the most commonly implemented SGML

features.

XML is a family of Recommendations that includes a

linking specification (XLL); it may in the future include

other specifications such as a stylesheet specification

(XSL). The XLL linking specification will provide the

syntax for hypertext links defined in Semiconductor

Equipment Manufacturing Information Tagging. The

XSL stylesheet language will be neither mandated nor

prohibited in SEMI E36-98.

5 Design and Principles

5.1 Information Markup - For purposes of interchange,

information will be marked-up according to the

conventions established in Semiconductor Equipment

Manufacturing Information Tagging. The defined

markup will:

• Identify the start and end of elements, which may

contain named information content or structural

components;

• Provide information concerning the identified

elements; and

• Specify connections among elements and between

elements and external objects.

Applications will be able to utilize this markup to:

• Select, limit, and organize specific elements for

reuse or interchange;

• Start and stop behavior, such as print formatting,

complex screen display, and the actuation of

programs;

• Limit retrieval (for increased precision);

• Generate navigation aids such as indexes and tables

of contents; and

• Validate document structure or content.

5.2 SGML Standard and XML Family of

Recommendations - The intent of Semiconductor

Equipment Manufacturing Information Tagging is to

define the rules and markup that can be used to create

XML data (which is, by definition, SGML data) for

maximum interchangeability and movement across both

internets and intranets. Therefore all markup and rules

will be designed to be fully conforming with the W3C

XML Recommendation. It is also the intent to describe

hypertext linking in conformance with the XLL

(Extensible Linking Language), as much as it is known,

and to migrate in the direction of that recommendation

as the recommendation is finished.

Since the intent of Semiconductor Equipment

Manufacturing Information Tagging is to create data

that is both valid XML and type-valid SGML:

• The DTDs, which will be written in both SGML

and XML syntax, will conform to the XML subset

of SGML by not using features and syntax that

XML prohibits such as exceptions and #CONREF

attributes;

• Tagged data produced according to Semiconductor

Equipment Manufacturing Information Tagging

will be valid XML. Early implementers using

SGML authoring or conversion tools should check

with their tool suppliers to make sure those tools

will work with their document without

modification.

Names of elements, attributes, and entities will be used

consistently within the SEMI E36 module set. While

some elements may have different content models from

SEMI E36-0704  1995, 2004

module to module, and in fact that is the intent of the

parameter entity framework, all name definitions and

use will be consistent throughout the SEMI E36 DTD

suite. This means that namespace issues, such as those

addressed by the XML Namespace Recommendation

(currently under development), are not relevant within

the scope of SEMI E36. It is likely that mechanisms

such as XML Namespaces will be used to incorporate

parts of the SEMI E36 markup set in other applications;

but this use is outside the scope of SEMI E36 itself.

5.3 Specification for Interchange - Semiconductor

Equipment Manufacturing Information Tagging defines

markup optimized for interchange, not for information

development (authoring) nor for information

presentation (rendering). Thus, some of the capabilities

and functionality that might be desired for authoring or

rendering will not be included in the markup rules, by

design. For example, few elements may be required and

the sequence of elements will not be tightly constrained.

It is anticipated that more specific authoring and

rendering models may be developed by other parties as

part of conforming applications. All conforming

interchange, however, will explicitly follow the markup

and structural rules defined in Semiconductor

Equipment Manufacturing Information Tagging.

5.4 General Modeling Principles

• Document (information) models will be

constructed that name the elements, describe the

relationships among these elements, and impose

certain markup or content constraints. The

information markup will be controlled by these

models.

• All models will be made available by SEMI and

distributed and balloted as additional parts of

Semiconductor Equipment Manufacturing

Information Tagging. Models will be described in

the second part of Semiconductor Equipment

Manufacturing Information Tagging rather than

included in the base document directly because the

models are assumed to be dynamic documents that

will grow and change as requirements alter. The

data models and the Tag Library may be balloted

separately without requiring a re-balloting of this

part of the specification.

• The models will initially be in the form of SGML

and XML Document Type Definitions (DTDs) and

may later include other XML-defining schema.

• There will be no all-inclusive general information

models; each DTD or other collection of rules will

model specific elements or specific document

types.

• Markup will be primarily designed according to the

nature of the information being described; such

considerations as data volume and ease of

implementation will only be considered

secondarily.

• DTDs will be constructed in a modular fashion,

with content-related or structurally-related

modules. The purpose of such modularization is to

reuse existing information content models as much

as possible. New element structures should be

created only when new content is analyzed.

5.5 Information Modeling

5.5.1 Types of Elements - SGML and XML elements

can identify many types of information. There are

situations in which each of the following element types

are appropriate, and many situations in which several

could be used. In designing structures and tagging

documents, elements should be designed using the

following hierarchy of types, from most- to least-

preferred. Only if the information cannot be

satisfactorily identified using one type of element

should those below it in the following list be

considered.

• Content Elements — those that identify the

information content, such as Warning, Procedural

Step, Part Number, Installation Manual, or Bill of

Materials.

• Structural Elements — those that identify the

structural role of a part of a document, such as

Title, Paragraph, or List Item.

• Pointer Elements — those that point to other

locations, either in this document or another, such

as Cross-reference, Footnote Reference, or URL.

• Format Elements — those that identify portions of

a document that are to be formatted differently

from surrounding text and for which there is no

Content, Structural, or Pointing reason that they

should be so formatted, for example a Bold

element. Format elements are to be used as a last

resort; use of a content, structure, or pointer

element with a format-related attribute is preferable

to use of a format element.

5.5.2 Naming Elements - Markup in the DTDs will be

named consistently across contexts. That is, the same

element name will be used for an element that can

occur in many places with the same function, regardless

of the location. For example, there is only one element

for Title, not many separate elements for Section Title,

Table Title, Figure Title, etc.

In XML, names are case-sensitive. In the interest of

keeping compliant with XML, all names will be case-

SEMI E36-0704  1995, 2004

sensitive. (In SGML, names may not be case-sensitive

since such names may be case-folded to upper case at

any time.) All element tag names should be in lower

case. Entity names and attribute names may be mixed

case, lower case, or upper case to match common usage

of the name involved. If there is no such consideration,

lower case should be used. Attribute values should be

in lower case unless there is a good reason to make

them another case, such as a list of state or country

codes which would naturally appear in upper case.

5.5.3 Recursive Structures - In cases where an element

may contain one or more of the same elements within

itself, there are several styles of modeling the solution:

• Use recursive structures. (In recursion, an element

would be allowed to contain itself, thus a <section>

could contain one or more <section>s, which could

themselves contain <section>s, etc.);

• Create an explicit hierarchy by naming the top

level and lower levels. (Thus a <section> could

contain one or more <subsections>, which could

themselves contain one or more <sub-subsections>,

etc.); or

• Create an explicit hierarchy by numbering the top

level as “1”, and subsequent levels as “2”, “3”, etc.

(Thus a <section1> could contain one or more

<section2>s, which could themselves contain one

or more <section3>s, etc.).

In such cases, recursion should be used to model an

element because it is optimal for authoring, editing, and

data reuse; in such an environment an editor can move a

section from one level to another without needing to

modify the tagging inside the section.

5.5.4 Content Modeling - To create SGML elements

that are maximally re-useable and compatible with

XML, there are several SGML modeling capabilities

that are prohibited in SEMI E36:

• RCDATA and CDATA declared content (character

data in which elements and entities cannot be

recognized) are prohibited.

• The “AND” connector (which specifies that all the

elements so connected are required but that order is

irrelevant) is prohibited.

• Inclusions and Exclusions to content models are

prohibited.

• Pernicious mixed element content is prohibited.

This means that if an element model contains

character data it must allow character data at any

place in the model. In practice this means that any

mixed content model groups should be repeatable

“| ” (or) groups.

In addition, the following rules also will apply:

• Each element must be declared separately;

• No inline comments or empty comments will be

permitted; only full comment declarations may be

used;

• The replacement text for external parameter entities

must be well-formed, as per the XML specification

declarations;

• The entity types CDATA, PI, and bracketed text

are prohibited;

• No Marked Sections are allowed in the DTDs; and

• External entities must include both a SYSTEM and

a PUBLIC identifier.

5.5.5 Attributes - The attribute list for each element

must be declared separately. Attribute values must not

contain references to external entities. If a Declared

Value is not a specified list, only the following

Declared Value keywords may be used:

• CDATA (character data);

• ID (a unique identifier for the element within its

current document);

• IDREF and IDREFS (one or more pointer to the

IDs of other elements within the same document);

• ENTITY or ENTITIES (the name of one or more

defined entities); and

• NMTOKEN or NMTOKENS (one or more words

that consist entirely of name characters).

On all attribute declarations, attribute values specified

as defaults must be literals. Only the following Default

Values keywords may be used:

• #REQUIRED (must be present);

• #IMPLIED (optional, may be implied by the

application); and

• #FIXED (set, not able to be changed).

5.6 Formatting from Element Context versus from

Attributes - The use of formatting attributes to indicate

preferred rendition in display or print should be limited

to situations in which no other mechanism is available.

That is, if the desired formatting can be accomplished

by use of the element name alone, or based on the

context in which the element appears, no formatting

attributes should be used. Elements should only carry

formatting attributes such as “type-size” if there is no

other mechanism to pass this information or if an author

or editor, rather than the output system, must control the

presentation directly. Formatting attributes, when used,