semi合集-English.pdf - 第1560页
SEMI E36-0704 1995, 2004 7 should be opt ional and considered adviso ry by the rendering agent. 5.7 Data Markup Rules - To create SGML doc uments that are maximally re-useable and co mpatible with XML, the followi ng r…
SEMI E36-0704 1995, 2004
6
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
7
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.
SEMI E36-0704 1995, 2004
8
6.2 Maintenance of Semiconductor Equipment
Manufacturing Information Tagging - This base portion
of the SEMI E36 specification is intended to be debated
and balloted once and change little over time.
Additional parts of the specification will contain the
actual information models that describe the markup to
be used. New information models may be proposed at
any time. Such models will be distributed, discussed,
and balloted individually or in small groups, in the form
of one or more SEMI E36 modules, as they are created.
Modules that are approved will be appended to
Semiconductor Equipment Manufacturing Information
Tagging. The documentation will be changed and
balloted in parallel, to match any changes in the models.
6.2.1 Module Library - A growing module library
containing all approved modules will be maintained,
adding modules as additional subject areas and
document types are defined. Once a module has been
approved, it will be provided as part of Semiconductor
Equipment Manufacturing Information Tagging. Place-
holding modules may be introduced into the library that
are designated as “Temporary”, for use only until a
formal analysis and balloting process can provide a
more appropriate module. Initially modules will be
XML and SGML DTDs and DTD fragments. As XML
alternative modeling syntaxes such as schema become
supported by software, these may be used to
supplement SEMI E36 information models.
6.2.2 Modules - Each module will be given a unique
short name (to be used as a file name), a version
number, and a unique public identifier written
according to the rules of ISO 8879 and incorporating
the version number.
File names will be all lower case, constructed by
concatenating the following, in order:
• A 3- to 8-character descriptive name;
• A hyphen;
• The file type as “xml” or “sgml”;
• A period; and
• A 3-character descriptive extension that defines the
type of file (such as “dec”, “sgm”, etc.) These
extensions will be defined in the Tag Library.
Each module will contain:
• An initial comment which names the module, states
the purpose of the modules, types the modules as
Temporary or Implemented, and states how the
module should be integrated with other modules;
• A growing change history comment that describes
(in sedimentary order; that is, the most recent at the
top) all modifications made to the model. Each
item in the change history should be numbered,
dated, provide a description of the change, give a
brief rationale, and name the changing agent.
• Whatever syntax is employed, internal comments
should be used throughout the module to name and
describe the elements and provide information that
may not be stated directly in the syntax used.
6.2.3 Consolidated Tag Library - A single,
consolidated Tag Library will be maintained which will
describe the elements, attributes, and entities defined in
all the modules. Each description will contain
sufficient detail to indicate the meaning and correct
usage of the data markup. The library (or changes to
the library) will be reissued whenever a module is
added or modified in a way that affects any of the
elements, attributes, or entities.
Modules should use elements (tags) that are already in
the Tag Library wherever the definition of the element
matches the need. If the definition of an existing tag
does not meet the need, a new tag should be created.
A diagram of the structure of each element will be
included in the Tag Library, except for elements that
are empty, contain only character data, or contain a
simple “or” group in which all contents may appear at
any point in the model.
For each element, the Tag Library will contain:
• Element Title, consisting of its Tag and Name;
• Definition in clear, plain English, including
description of intended use and application when
appropriate;
• Remarks (if needed);
• Related Elements (if needed);
• For each Source, or module in which the element is
defined:
• Attributes Associated with the Element (if
any);
• The model of the Element in SGML syntax
and narrative form;
• Presentation information (if needed);
• Formatted examples of the element (if
needed);
• Tagged examples of the elements (if needed);
and
• The Name of the Source, or module in which
the element is defined.
For each Attribute, the Tag Library will contain: