semi合集-English.pdf - 第1559页

SEMI E36-0704  1995, 2004 6 sensitive. (In SGML, names may not be case-sensitive since such na mes may be case-folde d to uppe r case at any time.) Al l element tag names shoul d be in lower case. Entity names and attri…

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,

SEMI E36-0704  1995, 2004

should be optional and considered advisory by the

rendering agent.

5.7 Data Markup Rules - To create SGML documents

that are maximally re-useable and compatible with

XML, the following restrictions are placed upon the

tagged instances produced in accordance with

Semiconductor Equipment Manufacturing Information

Tagging:

• The characters “<” and “&” must always be

escaped as “<” and “&” respectively.

• No Marked Sections will be allowed in data

content.

• The replacement text of general text entities must

be well-formed, for example, an element that starts

within an entity must also end within it.

• All attributes should be present (even default

attributes) and attribute values should be well-

formed, that is with the name, equal sign, and

quotation marks present.

• Processing Instructions are prohibited with the

exception of the XML declaration, for example:

<? XML version=˝1.0˝ RMD=' INTERNAL' >.

6 How Semiconductor Equipment

Manufacturing Information Tagging Should Be

Used

6.1 Conformance - A conforming document is one that

meets the markup rules defined for the document class

in Semiconductor Equipment Manufacturing

Information Tagging. A non-conforming document is

one that does not use the markup properly or follow the

markup rules defined in Semiconductor Equipment

Manufacturing Information Tagging. A conforming

document created by an application must be

interchangeable with another conforming application

without significant information loss. A conforming

application may also deliver the markup rules

(information models) for the document or information

class being interchanged to another system.

Conforming applications are those that create, render,

or work with conforming documents. Such applications

may include browsers and online rendering software,

print and composition engines, editors and authoring

systems, search and retrieval engines, etc. In addition

to strictly conforming applications, it is expected that

many applications will accept conforming documents as

input, converting them to the internal format of the

software.

6.1.1 Conforming Authoring Application - A

conforming authoring application must be able to

produce conforming information. An application may

state that it is conformant with Semiconductor

Equipment Manufacturing Information Tagging if it has

the ability to:

• Create and manipulate conforming documents;

• Create and manipulate one or more classes of

conforming documents;

• Import conforming documents into the application

and output matching conforming documents; or

• Turn non-conforming documents into conforming

documents.

6.1.2 Conforming Rendering Application - There is no

rendering specification stated or required by

Semiconductor Equipment Manufacturing Information

Tagging at this time. This specification does not define

style conventions or endorse any particular language for

the interchange of stylistic information. That said, a

conforming rendering application is one that can render

(print, display, pronounce, etc.) conforming documents

without significant loss of information. The

presentation should be consistent with the intent of the

originating system, but need not be an exact, facsimile-

reproduction match.

To call itself conforming, a rendering application must

be able to take any conforming document, which is by

definition legal according to this base specification and

the models defined and explained in other parts of the

specification, and render that document in some visual

or non-visual fashion. A conforming rendering

application may not impose additional requirements or

constraints such as content requirements. For example,

a rendering engine may not require the presence of an

element that is optional in the models or require a more

restrictive range of values for an attribute than the

models state.

6.1.3 Validation - Documents tagged according to

Semiconductor Equipment Manufacturing Information

Tagging must parse cleanly according to their SGML or

XML models and must follow the rules stated in this

base document and the Tag Library and other

documentation. Tagging validation must be

accomplished through the use of validating SGML or

XML parsers, in standalone form or as incorporated

into other software packages. (Note: Validation of

some of the rules described in this base document and

the Tag Library documentation cannot be accomplished

using only an XML or SGML parser. This does not

mean that such rules can be ignored, merely that other

validation techniques may be required.) SEMI E36

rules include both rules that can be checked with

software and content rules that can only be verified

intellectually; a conforming SEMI E36 document must

conform to both types of rules.