2.1.7. 各種 適合性の類別

この仕様は、次の二つに対する適合性~判定基準を述べる:

  • ~UA(実装者に関連する)
  • 文書(作者/著作~tool実装者に関連する)
◎ This specification describes the conformance criteria for user agents (relevant to implementors) and documents (relevant to authors and authoring tool implementors).

`適合~文書@ は、文書に課されるすべての適合性~判定基準に準拠するものである。 可読性のため、これらの適合性~要件のうち一部は,作者に対する適合性~要件として句される。 そのような要件は、暗黙的に文書に課されるものとされる。 定義により、すべての文書には,その作者があるものと見做される。 (一部の事例では、~UA自身がその作者になることもある — そのような~UAは、下に説明されるように,追加の規則の対象0になる。) ◎ Conforming documents are those that comply with all the conformance criteria for documents. For readability, some of these conformance requirements are phrased as conformance requirements on authors; such requirements are implicitly requirements on documents: by definition, all documents are assumed to have had an author. (In some cases, that author may itself be a user agent — such user agents are subject to additional rules, as explained below.)

例えば、要件にて “作者は `foobar^e 要素を利用しては~MUST_NOT” と定められている場合、それは[ 文書が,名前 `foobar^e の要素を包含することは、許容されない ]ことを含意することになる。 ◎ For example, if a requirement states that "authors must not use the foobar element", it would imply that documents are not allowed to contain elements named foobar.

文書, 実装 に課される適合性~要件の間には、含意される関係性はない。 ~UAは、適合しない文書を好きに取扱う自由はない — この仕様にて述べる処理~modelは、入力~文書が適合するかどうかに関わらず,実装に適用される。 ◎ There is no implied relationship between document conformance requirements and implementation conformance requirements. User agents are not free to handle non-conformant documents as they please; the processing model described in this specification applies to implementations regardless of the conformity of the input documents.

【 別の言い方をするなら,文書が適合でないことは、原則的に,各 実装~間での挙動の一貫性が 仕様からは保障されない(現実の実装では、たまたま一致するかもしれないが)。 場合によっては,適合しない事例に対する挙動も規定されているので、すべてがそうとは限らないが。 】

~UAは、適合性~要件が互いに異なるような,いくつかの(互いに重なり合う)種類に分けられる: ◎ User agents fall into several (overlapping) categories with different conformance requirements.

~web~browserその他の,対話的~UA ◎ Web browsers and other interactive user agents
`~XML構文$を~supportする~web~browserは、`~HTML名前空間$に属する ~XML文書~内に見出された[ 要素, 属性 ]を — 他の仕様により,それらの要素の意味論が上書きされていない限り — この仕様にて述べるように処理して,利用者がそれらと対話できるようにし~MUST。 ◎ Web browsers that support the XML syntax must process elements and attributes from the HTML namespace found in XML documents as described in this specification, so that users can interact with them, unless the semantics of those elements have been overridden by other specifications.
適合~Web~browserは、~XML文書~内に `script$e 要素を見出した際に,その要素に包含されている~scriptを実行することになる。 しかしながら,要素が ~XSLTによる変形結果の中に見出された場合(~UAは~XSLTも~supportするとする)、代わりに~XML処理器は, `script$e 要素を変形結果の一部を形成する不透明な要素として扱うことになる。 ◎ A conforming Web browser would, upon finding a script element in an XML document, execute the script contained in that element. However, if the element is found within a transformation expressed in XSLT (assuming the user agent also supports XSLT), then the processor would instead treat the script element as an opaque element that forms part of the transform.
`~HTML構文$における~scriptingを~supportする~web~browserは、`~HTML~MIME型$に~~識別される文書を,この仕様にて述べるように処理して,利用者がそれらと対話できるようにし~MUST。 ◎ Web browsers that support the HTML syntax must process documents labeled with an HTML MIME type as described in this specification, so that users can interact with them.
~scriptingを~supportする~UAは、この仕様における~IDL片に対しても, `WEBIDL$r 仕様に述べられる適合~実装で~MUST。 ◎ User agents that support scripting must also be conforming implementations of the IDL fragments in this specification, as described in the Web IDL specification. [WEBIDL]
注記: 明示的に定められない限り、~HTML要素の意味論を上書きする仕様であっても,その要素を表現している~DOM~objに課されている要件は上書きしないとする。 例えば,上の例の `script$e 要素は、依然として, `HTMLScriptElement$I ~interfaceを実装することになる。 ◎ Unless explicitly stated, specifications that override the semantics of HTML elements do not override the requirements on DOM objects representing those elements. For example, the script element in the example above would still implement the HTMLScriptElement interface.
対話的でない呈示のみの~UA ◎ Non-interactive presentation user agents
純粋に, ~HTML/~XML 文書の対話的でない~versionを具現化するために処理する~UAは、利用者~対話に関する要件については免除されることを除き,~Web~browserと同じ適合性~判定基準に準拠し~MUST。 ◎ User agents that process HTML and XML documents purely to render non-interactive versions of them must comply to the same conformance criteria as Web browsers, except that they are exempt from requirements regarding user interaction.
注記: 対話的でない呈示~UAの代表的な例として、印刷機(静的~UA)や頭上display(動的~UA)が挙げられる。 静的であって対話的でない呈示~UAのほとんどは、 ~scripting~supportも欠く ことが予期される。 ◎ Typical examples of non-interactive presentation user agents are printers (static UAs) and overhead displays (dynamic UAs). It is expected that most static non-interactive presentation user agents will also opt to lack scripting support.
対話的でないが,動的な呈示~UAは、依然として[ ~scriptを実行する, ~formを動的に提出する, 等々 ]を許容する。 しかしながら、利用者が文書と対話できない下では, “~focus” の概念は無関係なので、~UAは,~focusに関係するどの~DOM~APIも~supportする必要はないことになる。 ◎ A non-interactive but dynamic presentation UA would still execute scripts, allowing forms to be dynamically submitted, and so forth. However, since the concept of "focus" is irrelevant when the user cannot interact with the document, the UA would not need to support any of the focus-related DOM APIs.
示唆される既定の具現化を~supportする視覚的~UA ◎ Visual user agents that support the suggested default rendering
対話的かどうかにかかわらず、~UAは、この仕様に定義され, 示唆される( suggested ),既定の具現化( rendering )を~supportするものとして指名され得る(場合によっては 利用者の任意選択として)。 ◎ User agents, whether interactive or not, may be designated (possibly as a user option) as supporting the suggested default rendering defined by this specification.
このことは要求されてはいない。 特に,~UAには、示唆される既定の具現化を実装するとしても,利用者~体験を改善するためとして,既定の具現化を上書きするような設定群を提供0することが奨励される。 例えば、色の~contrastを変更する, ~focusに異なる~styleを利用する, その他、利用者がより~accessし易く, 利用し易くするものなど。 ◎ This is not required. In particular, even user agents that do implement the suggested default rendering are encouraged to offer settings that override this default to improve the experience for the user, e.g. changing the color contrast, using different focus styles, or otherwise making the experience more accessible and usable to the user.
示唆される既定の具現化を~supportするものと指名された~UAは、そう指名されている間は, 具現化~節 にて[ ~UAに実装することが期待される( expected )挙動 ]として定義されている規則を実装し~MUST。 ◎ User agents that are designated as supporting the suggested default rendering must, while so designated, implement the rules the rendering section defines as the behavior that user agents are expected to implement.
~scriptingを~supportしない~UA ◎ User agents with no scripting support
~scriptingを~supportしない(または,まるごと不能化されている)実装は、この仕様に示される[ ~event&~DOM~interface ]を~supportすることは,免除される。 そのような~UAは、この仕様の~event~modelや~DOMの用語で定義される各部分に対しては、依然として ~event&~DOMを~supportしていたかのように動作し~MUST。 ◎ Implementations that do not support scripting (or which have their scripting features disabled entirely) are exempt from supporting the events and DOM interfaces mentioned in this specification. For the parts of this specification that are defined in terms of an events model or in terms of the DOM, such user agents must still act as if events and the DOM were supported.
注記: ~scriptingが、~appの不可欠な部分を形成することもある。 ~scriptingを~supportしない(または不能化されている)~web~browserは、作者の意向を全部的に伝達できないかもしれない。 ◎ Scripting can form an integral part of an application. Web browsers that do not support scripting, or that have scripting disabled, might be unable to fully convey the author's intent.
適合性~検査器 ◎ Conformance checkers
適合性~検査器は、この仕様にて述べる適合性~判定基準のうち 適用し得るものについて,文書が適合するかどうかを検証0し~MUST。 自動化された適合性~検査器には、作者の意向の解釈を要求するような~errorを検出することは免除される(例えば、[ 内容が引用でない `blockquote$e 要素 ]を含むような文書は,適合しないが、人による判断の下で走らせてない適合性~検査器には, `blockquote$e 要素が引用された素材のみを包含していることを検査する必要はない)。 ◎ Conformance checkers must verify that a document conforms to the applicable conformance criteria described in this specification. Automated conformance checkers are exempt from detecting errors that require interpretation of the author's intent (for example, while a document is non-conforming if the content of a blockquote element is not a quote, conformance checkers running without the input of human judgement do not have to check that blockquote elements only contain quoted material).

適合性~検査器は、入力~文書に対し:

  • `属する閲覧文脈$がない下で(~scriptを走らせてない, かつ 構文解析器の`~scripting~flag$は不能化されていることを意味する)構文解析して、適合するかどうかを検査し~MUST。
  • また,`属する閲覧文脈$がある下で構文解析して、適合するかどうかを — その中で~scriptを実行して,~scriptが適合しない状態を(~script実行の間に一時的にそうなるときを除いて)決して生じさせないかどうかを — 検査するべきである(この要件は “~SHOULD” までに限られ, “~MUST” ではない — それは不可能なことが証明されているので `COMPUTABLE$r )
◎ Conformance checkers must check that the input document conforms when parsed without a browsing context (meaning that no scripts are run, and that the parser's scripting flag is disabled), and should also check that the input document conforms when parsed with a browsing context in which scripts execute, and that the scripts never cause non-conforming states to occur other than transiently during script execution itself. (This is only a "SHOULD" and not a "MUST" requirement because it has been proven to be impossible. [COMPUTABLE])
この仕様による要件のうち,適用し得るものに適合するような適合性~検査器は、 “~HTML検証器” とも称される。 ◎ The term "HTML validator" can be used to refer to a conformance checker that itself conforms to the applicable requirements of this specification.

注記: ~XML~DTDは、この仕様の適合性~要件すべてを表すことはできない。 したがって、~XML処理器と~DTDだけでは,適合性~検査器として~~不足になる。 また、この仕様にて定義される 二つの著作~形式 のいずれも,~SGMLの応用ではないので、それらを検証する~SGML~systemも,適合性~検査器としては~~不足になる。 ◎ XML DTDs cannot express all the conformance requirements of this specification. Therefore, a validating XML processor and a DTD cannot constitute a conformance checker. Also, since neither of the two authoring formats defined in this specification are applications of SGML, a validating SGML system cannot constitute a conformance checker either.

別の仕方で記すなら、適合性~判定基準には次の三種がある: ◎ To put it another way, there are three types of conformance criteria:

  1. ~DTDで表せるもの。 ◎ Criteria that can be expressed in a DTD.
  2. ~DTDでは表せないが、機械的に検査できるもの。 ◎ Criteria that cannot be expressed by a DTD, but can still be checked by a machine.
  3. 人によってのみ検査できるもの。 ◎ Criteria that can only be checked by a human.

適合性~検査器は、最初の二項目に対しては検査し~MUST。 ~DTDのみに基づく単純な検証器は、最初の類別の~errorしか検査しないので、この仕様に則る適合性~検査器には適合しない。 ◎ A conformance checker must check for the first two. A simple DTD-based validator only checks for the first class of errors and is therefore not a conforming conformance checker according to this specification.

~data-mining~tool ◎ Data mining tools
[ 文書を具現化する, 適合性を検査する ]以外の理由で[ ~HTML/~XML ]文書を処理する~appや~toolは、自身が処理する文書の意味論に則って動作するべきである。 ◎ Applications and tools that process HTML and XML documents for reasons other than to either render the documents or check them for conformance should act in accordance with the semantics of the documents that they process.
`文書の~outline$を生成する~toolであって、入子~levelを 各~段落に対しては増やしつつ,各~節に対しては増やさないものは、適合しない。 ◎ A tool that generates document outlines but increases the nesting level for each paragraph and does not increase the nesting level for each section would not be conforming.
著作~tool/~markup生成器 ◎ Authoring tools and markup generators
著作~tool/~markup生成器 は、`適合~文書$を生成し~MUST。 作者に適用される適合性~判定基準は、適切になる所では,著作~toolにも適用される。 ◎ Authoring tools and markup generators must generate conforming documents. Conformance criteria that apply to authors also apply to authoring tools, where appropriate.
著作~toolには、~tool自身が作者の意向を決定できない範囲0に限り,[ 要素をそれに指定された目的に限って利用するとする,厳格な要件 ]からは免除される。 しかしながら,著作~toolは、要素を自動的に誤用したり,利用者にそうするよう奨励しては~MUST_NOT。 ◎ Authoring tools are exempt from the strict requirements of using elements only for their specified purpose, but only to the extent that authoring tools are not yet able to determine author intent. However, authoring tools must not automatically misuse elements or encourage their users to do so.
例えば、 `address$e 要素を任意の連絡先~情報に利用することは適合でない — その要素は、文書またはその一節の著作者に対する連絡先~情報を~markupするために限って利用できるので。 しかしながら、著作~toolは,およそ その相違は決定できないであろうから、その要件は免除される。 そうであっても,これは、著作~toolが[ (例えば)~italic体の~textのどの~blockにも `address$e 要素を利用できる ]ことを意味するわけではない — それは単に、著作~toolが,[ 利用者が~toolを利用して連絡先~情報を挿入するときに,利用者が本当にそれを行っていて 何か別のものを挿入していない ]ことを検証0する必要はないことを意味する。 ◎ For example, it is not conforming to use an address element for arbitrary contact information; that element can only be used for marking up contact information for the author of the document or section. However, since an authoring tool is likely unable to determine the difference, an authoring tool is exempt from that requirement. This does not mean, though, that authoring tools can use address elements for any block of italics text (for instance); it just means that the authoring tool doesn't have to verify that when the user uses a tool for inserting contact information for a section, that the user really is doing that and not inserting something else instead.
注記: 適合性を検査する点においては、~editorは,[ 適合性~検査器が検証0するのと同じ範囲0までにおいて,適合する ]ような文書を出力する必要がある。 ◎ In terms of conformance checking, an editor has to output documents that conform to the same extent that a conformance checker will verify.
著作~toolが適合しない文書を編集するために利用されるときは、編集~sessionの間に,文書~内の未~編集-部分における適合性~errorを保全しても~MAY(すなわち、編集~toolには、~error含みの内容を往来することは許容される)。 しかしながら,著作~toolは、そのように~errorが保全された出力を,適合するものと主張しては~MUST_NOT。 ◎ When an authoring tool is used to edit a non-conforming document, it may preserve the conformance errors in sections of the document that were not edited during the editing session (i.e. an editing tool is allowed to round-trip erroneous content). However, an authoring tool must not claim that the output is conformant if errors have been so preserved.

著作~toolは、次の二つに大別されることが予期される:

  • 構造~上のまたは意味論上の~dataに対し働くもの。
  • 媒体~特有の WYSIWYG( What-You-See-Is-What-You-Get )編集に基づいて働くもの。
◎ Authoring tools are expected to come in two broad varieties: tools that work from structure or semantic data, and tools that work on a What-You-See-Is-What-You-Get media-specific editing basis (WYSIWYG).

前者は、~HTMLを著作する~toolに選好される仕組みである — 最も適切な~HTML要素/属性を選ぶ際の判断材料に,~source情報~内の構造を利用できるので。 ◎ The former is the preferred mechanism for tools that author HTML, since the structure in the source information can be used to make informed choices regarding which HTML elements and attributes are most appropriate.

しかしながら, WYSIWYG ~toolは legitimate である `?^tnote 。 WYSIWYG ~toolは、適切であると知る要素のみを利用するべきであり,そうでない要素は利用するべきでない。 これは、ある種の極端な事例では,~flow要素の利用を[ `div$e, `b$e, `i$e, `span$e ]の様な,ごく少数のものに制限した上で, `style$a 属性を最大限に活用することを意味するかもしれない。 ◎ However, WYSIWYG tools are legitimate. WYSIWYG tools should use elements they know are appropriate, and should not use elements that they do not know to be appropriate. This might in certain extreme cases mean limiting the use of flow elements to just a few elements, like div, b, i, and span and making liberal use of the style attribute.

WYSIWYG かどうかにかかわらず,すべての著作~toolは、利用者が[ きちんと構造~化され, 意味論的に多彩な,媒体依存の内容 ]を作成できるようにすべく,でき得る限り努めるべきである。 ◎ All authoring tools, whether WYSIWYG or not, should make a best effort attempt at enabling users to create well-structured, semantically rich, media-independent content.

~UAは、さもなければ拘束されない入力に,実装~特有の制限-を課して~MAY。 例えば[ ~DOS攻撃を防止する / ~memoryの枯渇に抗して防護する / ~platform特有の制限に対処する ]など。 ~FINGERPRINTING ◎ User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.

[ 既存の内容や, 先立つ仕様 ]との互換性をとるため、この仕様は,次の二つの著作~形式を述べる:

  • `~XML構文$に基づくもの。
  • ~SGMLに~~由来する`~custom形式$を利用するもの(`~HTML構文$とも称される)。

実装は、これら二つの形式のうち,少なくとも一方は~supportし~MUST — 両者とも~supportすることが奨励されるが。

◎ For compatibility with existing content and prior specifications, this specification describes two authoring formats: one based on XML, and one using a custom format inspired by SGML (referred to as the HTML syntax). Implementations must support at least one of these two formats, although supporting both is encouraged.

適合性~要件のうち一部は、[ 要素 / 属性 / ~method / ~obj ]に課される要件として句される。 そのような要件は、次の二つに~~分類される:

  • 内容~modelに対する制約について述べるもの。 これは、[ 文書/著作~tool ]に課される要件になる。
  • 実装の挙動について述べるもの。 これは、~UAに課される要件になる。

同様に,適合性~要件のうち一部は、作者に課される要件として句される。 そのような要件は、作者が生産する文書に課される適合性~要件として解釈されることになる(言い換えれば、この仕様は,作者に課される適合性~判定基準と, 文書に課されるそれとを区別しない)。

◎ Some conformance requirements are phrased as requirements on elements, attributes, methods or objects. Such requirements fall into two categories: those describing content model restrictions, and those describing implementation behavior. Those in the former category are requirements on documents and authoring tools. Those in the second category are requirements on user agents. Similarly, some conformance requirements are phrased as requirements on authors; such requirements are to be interpreted as conformance requirements on the documents that authors produce. (In other words, this specification does not distinguish between conformance criteria on authors and conformance criteria on documents.)

2.1.8. 依存関係

【 この節の和訳は 別ページにて

2.1.9. 拡張性

この仕様に対する~vendor特有の~proprietaryな~UA拡張は、強く忌避される。 文書は、そのような拡張を利用しては~MUST_NOT。 そのような行為は、当の内容への~accessが特定の~UAの利用者に限られてしまい,相互運用性の悪化と利用者~層の細分化を招くことになるので。 ◎ Vendor-specific proprietary user agent extensions to this specification are strongly discouraged. Documents must not use such extensions, as doing so reduces interoperability and fragments the user base, allowing only users of specific user agents to access the content in question.

すべての拡張は、その利用が,この仕様にて定義される機能性に矛盾したり不適合にしないように定義され~MUST。 ◎ All extensions must be defined so that the use of extensions neither contradicts nor causes the non-conformance of functionality defined in the specification.

例えば,そうすることは強く忌避されてはいるが、実装は,ある~controlに[ 利用者が その~controlの現在の値を選択するときにかかった時間 ]を返すような,新たな~IDL属性 `typeTime^m を追加することもできる。 一方で、~formの `elements$m 配列に出現するような,新たな~controlを定義することは、上の要件に対する違反になる — それは、この仕様が与える `elements$m の定義に違反するので。 ◎ For example, while strongly discouraged from doing so, an implementation could add a new IDL attribute "typeTime" to a control that returned the time it took the user to select the current value of a control (say). On the other hand, defining a new control that appears in a form's elements array would be in violation of the above requirement, as it would violate the definition of elements given in this specification.


この仕様に対し ~vendorに中立的な拡張が必要されるときは、それに則って,この仕様が更新されるか,この仕様の要件を上書きするような拡張~仕様が記され得る。 自身の活動にこの仕様を適用している誰かが、そのような拡張~仕様の要件を認めるものと決めたとき、それは,この仕様に対する適合性~要件の目的において `適用し得る仕様@ になる。 ◎ When vendor-neutral extensions to this specification are needed, either this specification can be updated accordingly, or an extension specification can be written that overrides the requirements in this specification. When someone applying this specification to their activities decides that they will recognize the requirements of such an extension specification, it becomes an applicable specification for the purposes of conformance requirements in this specification.

注記: 誰かが,[ 任意の~byte~streamは適合である ]と定義するような仕様を書いた上で,そのような無作為な~junkを適合であると主張することもできる。 しかしながらそれは、その無作為な~junkが皆の目的に適合であることを実際に意味するものではない。 他の誰かが,その仕様を自身の仕事に適用しないものと決めたなら、その誰かは,全く正当に[ 前述の~junkは,単に~junkであり全く適合でない ]と言える。 特定0の~communityにおいて何が問題0とされるかは,その~communityが何に同意するかであり、適合性が適用し得るのは,その限りにおいてである。 ◎ Someone could write a specification that defines any arbitrary byte stream as conforming, and then claim that their random junk is conforming. However, that does not mean that their random junk actually is conforming for everyone's purposes: if someone else decides that that specification does not apply to their work, then they can quite legitimately say that the aforementioned random junk is just that, junk, and not conforming at all. As far as conformance goes, what matters in a particular community is what that community agrees is applicable.


~UAは、自身が解さない要素や属性を,次のように意味論的に中立的であるものと扱わ~MUST:

  • ~DOM処理器においては、それらを~DOM内に残すこと。
  • ~CSS処理器においては、~CSSに則ってそれらに~styleをあてがうこと。
  • それらから いかなる意味も推定しないこと。
◎ User agents must treat elements and attributes that they do not understand as semantically neutral; leaving them in the DOM (for DOM processors), and styling them according to CSS (for CSS processors), but not inferring any meaning from them.

~UAは、特色機能の~supportを不能化するときは(例: 保安~問題を軽減するための緊急の措置として / 開発を援助するため / 処理能~上の理由から),[ その特色機能をまったく~supportしていなかった / その特色機能は,この仕様に示されていなかった ]かのように動作し~MUST。 例えば、特定0の特色機能が ~Web~IDL~interface内の属性を介して~accessされる場合、属性~自身は,その~interfaceを実装する~objから外されることになる — ~obj上にその属性を残した上で,~NULL を返したり, 例外を投出させるのでは、不十分である。 ◎ When support for a feature is disabled (e.g. as an emergency measure to mitigate a security problem, or to aid in development, or for performance reasons), user agents must act as if they had no support for the feature whatsoever, and as if the feature was not mentioned in this specification. For example, if a particular feature is accessed via an attribute in a Web IDL interface, the attribute itself would be omitted from the objects that implement that interface — leaving the attribute on the object but making it return null or throw an exception is insufficient.

2.1.10. XPath&XSLT との相互作用

この仕様に述べる方式で[ 構文解析される/作成される `~HTML文書$ ]上で演算する XPath 1.0 実装(例: `document.evaluate()^c ~APIの一部で)は、 XPath 1.0 仕様に,次の編集-が適用されたかのように動作し~MUST: ◎ Implementations of XPath 1.0 that operate on HTML documents parsed or created in the manners described in this specification (e.g. as part of the document.evaluate() API) must act as if the following edit was applied to the XPath 1.0 specification.

先ず,次の段落を除去した上で: ◎ First, remove this paragraph:

A QName in the node test is expanded into an expanded-name using the namespace declarations from the expression context. This is the same way expansion is done for element type names in start and end-tags except that the default namespace declared with xmlns is not used: if the QName does not have a prefix, then the namespace URI is null (this is the same way attribute names are expanded). It is an error if the QName has a prefix for which there is no namespace declaration in the expression context.

~node-testにおける `QName^P は、~XPath式~文脈( the expression context )からの名前空間~宣言を利用して, `expanded-name$P に展開される。 これは、[ `xmlns^a により宣言される,既定の名前空間 ]は利用されないことは除いて, 開始~tag/終了~tag における要素~型~名に対する展開と同じ仕方で行われる:

  • `QName$P に接頭辞( prefix )がない場合、名前空間 URI ( namespace URI )は ~NULL とする(これは、属性~名( attribute name )が展開されるときと同じ仕方になる)。
  • `QName$P に接頭辞がある場合、対する~XPath式~文脈に名前空間~宣言がないならば,~errorとする。

その場所に次を挿入する: ◎ Then, insert in its place the following:

A QName in the node test is expanded into an expanded-name using the namespace declarations from the expression context. If the QName has a prefix, then there must be a namespace declaration for this prefix in the expression context, and the corresponding namespace URI is the one that is associated with this prefix. It is an error if the QName has a prefix for which there is no namespace declaration in the expression context.

If the QName has no prefix and the principal node type of the axis is element, then the default element namespace is used. Otherwise if the QName has no prefix, the namespace URI is null. The default element namespace is a member of the context for the XPath expression. The value of the default element namespace when executing an XPath expression through the DOM3 XPath API is determined in the following way:

  1. If the context node is from an HTML DOM, the default element namespace is "http://www.w3.org/1999/xhtml".
  2. Otherwise, the default element namespace URI is null.

~node-testにおける `QName^P は、~XPath式~文脈からの名前空間~宣言を利用して `expanded-name$P に展開される。

  • `QName^P に接頭辞がある場合、~XPath式~文脈に,この接頭辞に対する名前空間~宣言が~~存在し~MUST — 存在しない場合は~errorとする。 この接頭辞には、その宣言により宣言される名前空間 URI が結付けられる。
  • `QName^P に接頭辞がない場合の名前空間 URI は:

    • the axis の the principal ~node型は要素である場合、要素に対する既定の名前空間が利用される。
    • 他の場合、~NULL とする。

要素に対する既定の名前空間は、~XPath式が属する文脈の一員である。 DOM3 XPath API を通して~XPath式を実行するときの,要素に対する既定の名前空間の値は、次に従って決定される:

  1. 文脈~nodeが~HTML~DOMに属するならば: `http://www.w3.org/1999/xhtml^l
  2. 他の場合: ~NULL

注記: これは、 XPath 2.0 の特色機能である[ 要素に対する既定の名前空間( the default element namespace ) ]を XPath 1.0 に追加した上で、~HTML文書においては,~HTML名前空間を[ 要素に対する既定の名前空間 ]として利用することに等価である。 それは、次が欲されることが動機にある:

  • 実装が旧来の~HTML内容と互換であり続けること。
  • この仕様により~HTMLに導入される,~HTML要素に利用される名前空間に関する変更点を~supportすること。
  • XPath 2.0 ではなく XPath 1.0 を利用すること。
◎ This is equivalent to adding the default element namespace feature of XPath 2.0 to XPath 1.0, and using the HTML namespace as the default element namespace for HTML documents. It is motivated by the desire to have implementations be compatible with legacy HTML content while still supporting the changes that this specification introduces to HTML regarding the namespace used for HTML elements, and by the desire to use XPath 1.0 rather than XPath 2.0.

注記: この変更は、上述の最初の 2 項目を動機とする, `XPATH10$r 仕様に対する`故意的な違反$である。 ◎ This change is a willful violation of the XPath 1.0 specification, motivated by desire to have implementations be compatible with legacy content while still supporting the changes that this specification introduces to HTML regarding which namespace is used for HTML elements. [XPATH10]


~XSLT 1.0 処理器が,( 明示的に, または XSLT 1.0 の規則による既定法を介して)出力~method `html^l の下で~DOMを出力するときは、次のように影響される: ◎ XSLT 1.0 processors outputting to a DOM when the output method is "html" (either explicitly or via the defaulting rule in XSLT 1.0) are affected as follows:

変形~programが 名前空間に属さない要素を出力する場合、処理器は,対応する~DOM要素~nodeを構築するに先立って,次を行わ~MUST:

  • 要素の名前空間を`~HTML名前空間$に変更する
  • 要素の局所~名を`~ASCII小文字~化$する
  • 要素~上のどの属性 %A に対しても、 %A が名前空間に属さないならば, %A の名前を`~ASCII小文字~化$する。
◎ If the transformation program outputs an element in no namespace, the processor must, prior to constructing the corresponding DOM element node, change the namespace of the element to the HTML namespace, ASCII-lowercase the element's local name, and ASCII-lowercase the names of any non-namespaced attributes on the element.

注記: この要件は、 `XSLT10$r に対する`故意的な違反$である — これが要求されるのは、そうしなければ,この仕様による~HTMLの名前空間と文字大小区別の有無に関する変更が,~DOMに基づく~XSLT変形と非互換になるためである。 (出力を直列化する処理器は影響されない。) ◎ This requirement is a willful violation of the XSLT 1.0 specification, required because this specification changes the namespaces and case-sensitivity rules of HTML in a manner that would otherwise be incompatible with DOM-based XSLT transformations. (Processors that serialize the output are unaffected.) [XSLT10]


この仕様は、~XSLT処理と`~HTML構文解析器$ 基盤とがどう相互作用するかについては、精確に指定しない(例えば、~XSLT処理器は,要素を`~open要素の~stack$の中へ~置いたかのように動作するのかどうか)。 しかしながら,~XSLT処理器は:

  • 成功裡に完了したときには、`構文解析を停止-$し~MUST。
  • 加えて,`文書の現在の準備度$は、先ず `interactive^l に設定した上で,中止された場合は `complete^l に設定し~MUST。
◎ This specification does not specify precisely how XSLT processing interacts with the HTML parser infrastructure (for example, whether an XSLT processor acts as if it puts any elements into a stack of open elements). However, XSLT processors must stop parsing if they successfully complete, and must set the current document readiness first to "interactive" and then to "complete" if they are aborted.

この仕様は、次については指定しない:

  • ~XSLTと`~navi$~algoとが,どう相互作用するか。
  • ~XSLTが`~event-loop$内にどう収まるか。
  • ~error頁がどう取扱われることになるか(例:~XSLT~errorは,~XSLTによる増分的~出力を置換するのか, ~inlineに具現化されるのか, 等々)。
◎ This specification does not specify how XSLT interacts with the navigation algorithm, how it fits in with the event loop, nor how error pages are to be handled (e.g. whether XSLT errors are to replace an incremental XSLT output, or are rendered inline, etc).

注記: ~HTMLとの相互作用に関する,追加の非~規範的~commentもある:

◎ There are also additional non-normative comments regarding the interaction of XSLT and HTML in the script element section, and of XSLT, XPath, and HTML in the template element section.