2008-09 アーカイブ

http://hxxk.jp/2008/09/

XML 宣言の省略と XHTML Media Types の Second Edition についてのまとめ

記事データ

投稿者

真琴

投稿日時

2008-09-30T00:15+09:00

タグ
概要

XML 宣言を省略する記述方法についての問題提起と、 XML の仕様から見た XML 宣言の定義、 XHTML Media Types の Second Edition と前の Edition との違いなどから、 XML 宣言の省略の機会増までの考察。

リプライ

1 件のリプライがあります。

記事本文

IE 6 では XML 宣言を書くと後方互換モードでレンダリングされる→ XML 宣言を省略するソリューション

昨日 DOCTYPE スイッチについてのまとめと一覧表 (HTML 5 や IE 8 Beta 2 のモードスイッチなどの情報も含んだ 2008 年版 ) にて DOCTYPE スイッチについてまとめましたが、 IE 6 では XML 宣言が書かれていると後方互換モードでレンダリングされるというバグがあるため、 IE 6 では XML 宣言を書かないようにして標準準拠モードでレンダリングさせる、という対処が一般的になっていました。

しかし、 XML 1.0 の 2.8 Prolog and Document Type Declaration では、 XML documents SHOULD begin with an XML declaration which specifies the version of XML being used. と、 XML 1.0 文書は XML 宣言で始まるべきであるとされています。 (XML 1.1 文書の場合は XML 1.1 documents MUST begin with an XML declaration which specifies the version of XML being used. と、 XML 宣言で始まらなければならないとされています。 ) IE 6 がバグによってレンダリングモードが切り替わってしまうから、という理由だけで安易に XML 宣言を書かない、という対処をして良いものなのでしょうか。

XML の仕様から XML 宣言を紐解く

さて、XML 宣言を省略できる条件、というのは実は仕様には書かれてありません。 表現の問題でもありますが、「このような条件の場合に省略できる」というよりは、「省略した場合はこのように扱われる」ということだけが示されています。

XML 宣言がどのような構造になっているか見てみましょう。 XML 1.0 の XMLDecl の部分では、 XMLDecl ::= '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>' と示されています。 EncodingDecl( 文字エンコーディング宣言 ) と SDDecl( スタンドアロン文書宣言 ) には ? が付いていますので、ひとつだけ記述するか、あるいは記述しないということになります。

  • EncodingDecl は、 XML 文書の文字エンコーディングが UTF-8 あるいは UTF-16 以外で、かつハイレベルのプロトコルから文字エンコーディングが明示されない場合に記述します。
    • よって、 EncodingDecl を記述しないようにするためには、文字エンコーディングを UTF-8 あるいは UTF-16 とするか、それ以外の文字エンコーディングの場合はよりハイレベルのプロトコルで明示する必要があります。
  • SDDecl は、その XML 文書の外部に参照すべき外部マークアップ宣言が存在するかどうかを指定します。この記述をしなければ、 standalone="no" として扱われます。
    • なお、 XHTML 文書であれば DTD 内で文字実体を参照するため、 standalone="no" ということになります、
  • VersionInfo は、それぞれの XML 文書の仕様内の VersionNum で示されているバージョン番号を記述します。 XML 1.0 文書であれば 1.0 を、 XML 1.1 文書であれば 1.1 を記述します。
    • XML 宣言自体を省略した場合は、 VersionNum は 1.0 となります。

まとめます。 XML 宣言を省略すると、その文書は

  • 文字エンコーディングはハイレベルなプロトコルで明示されている。あるいは UTF-8 か UTF-16 で記述されている。
  • スタンドアロン文書宣言は no である。
  • XML 1.0 文書である。

という文書であるとして取り扱われます。 これを更にまとめると、文字エンコーディングが UTF-8 か UTF-16 か、またはそれ以外の文字コードであればハイレベルなプロトコルで明示されている XHTML 文書であれば XML 宣言が省略されていてもまあ何とか OK かな、ということです。 ( 省略条件が揃っていても、 XML documents SHOULD begin with an XML declaration which specifies the version of XML being used. ということには変わりありませんので。 )

XHTML Media Types の Second Edition の登場

......と、これまではそういった話でまとまっていました。 ところが、最近は DOCTYPE スイッチによる理由以外でも XML 宣言の記述の有無について考慮する動きが起こっています。

XML宣言とDOCTYPE宣言 - vantguarde - web:g に詳しく書いてありますが、 XML宣言とかPIとか書かないように というガイドラインが示されています。

更に遡ると、 XHTML Media Types (2nd Ed.) - vantguarde - web:gXHTML Media Types改訂の動き | Web標準Blog | ミツエーリンクスというリソースに行き当たります。 これを元に考えを深めていくと、 XML 宣言以外にも変更点があるようです。

なお、 XHTML Media Types の Second Edition は現時点では Editor's Draft であり、 W3C 公式の仕様ではありませんが、初版の XHTML Media TypesW3C Notes ( 現在での Working Group Notes) という位置付けであり、 XHTML Document Development Area の XHTML Media Types を見ても、 Last Public Draft None という状態なので、 Editor's Draft ではありますが新しい仕様を参考にします。

XML宣言とDOCTYPE宣言 - vantguarde - web:g で参照しているのは XHTML Media Types - Second Edition (Editor's Draft 23 April 2008) ですが、この記事の時点では新たに XHTML Media Types - Second Edition (Editor's Draft 27 August 2008) が公開されています。 ( http://www.w3.org/MarkUp/Drafts/#xhtmlmime を参照すると良いですよ、と id:vantguarde さんに教えていただきました。 )

XHTML Media Types の First EditionSecond Edition (Editor's Draft 27 August 2008) の違い (1)

それでは、 XHTML Media Types の First EditionSecond Edition (Editor's Draft 27 August 2008) の違いを考えてみます。 まず目に付く違いとして、 XHTML の種類によって選択する Media Types が違っています。

まずは First Edition の 3.5. Summary の表です。

Media type HTML 4 XHTML 1.0 (HTML 互換 ) XHTML 1.0 ( その他 ) XHTML Basic / 1.1 XHTML+MathML
text/html 推奨 可能 非推奨 非推奨 非推奨
application/xhtml+xml 禁止 推奨 推奨 推奨 推奨
application/xml 禁止 可能 可能 可能 可能
text/xml 禁止 可能 可能 可能 可能

その表が、 Second Edition (Editor's Draft 27 August 2008) の 3.5. Summary では次のように変わっています。

Media type HTML 4 XHTML ファミリ文書型 (HTML 互換 ) XHTML ファミリ文書型 ( その他 ) XHTML ファミリ文書型 + 拡張
text/html 推奨 可能 非推奨 非推奨
application/xhtml+xml 禁止 可能 推奨 推奨
application/xml 禁止 可能 可能 可能
text/xml 禁止 可能 可能 可能

First Edition では、 XHTML 1.0 (First Edition) の Appendix C. HTML Compatibility Guidelines に沿った XHTML 1.0 であれば text/html の指定が可能application/xhtml+xml の指定を推奨ということだったのですが、 Second Edition (Editor's Draft 27 August 2008) では同一文書内の Appendix A. Compatibility Guidelines に沿った XHTML ファミリ文書型であれば text/html の指定が可能application/xhtml+xml の指定が可能というように変わっています。

これまでは XHTML Media Types First Edition を参考にするならば、 text/html で XHTML 文書を公開する場合に XHTML 1.0 (First Edition) の Appendix C. HTML Compatibility Guidelines に沿った上で、かつ XHTML 1.0 を選択すると示されていたのに対し、 Second Edition (Editor's Draft 27 August 2008) などの Second Edition を参考にするならば Appendix A. Compatibility Guidelines に沿っていれば XHTML Family document type であれば良い、という変更です。

視点を変えると、これまでは XHTML 1.1 では text/html は非推奨で、 application/xhtml+xml が推奨とされていたため、 application/xhtml+xml の表示に対応していない IE に対して XHTML 1.1 の使用が躊躇われていました。 これは text/html と XHTML 1.1 でも触れていた点でもありますし、 XHTML Media Types (2nd Ed.) - vantguarde - web:g でも (ガイドラインに沿えば)XHTML 1.1をある意味「合法的」にIEで表示できるようになりそうです とのコメントが述べられています。

XHTML Media Types の First EditionSecond Edition (Editor's Draft 27 August 2008) の違い (2)

前項では Media Types の違いについて触れましたが、それに合わせて参照するガイドラインも変更になっています。 それは次項にまとめるとして、他に小さな相違点を。

application/xml や application/xhtml+xml として文書を公開する場合の meta http-equiv の指定

First Edition では Note that a meta http-equiv statement will not be recognized by XML processors, and authors SHOULD NOT include such a statement in an XHTML document served as 'application/xml' (and 'application/xhtml+xml' as well for that matter). のように、「 XML プロセサは <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> のような指定を解釈しないこと、よって application/xml および application/xhtml+xml として提供される XHTML 文書に対してそのような指定を行うべきでない」と示されていました。

Second Edition (Editor's Draft 27 August 2008) では Note that a meta http-equiv statement will not be recognized by XML processors, and while authors MAY include such a statement a statement in an XHTML document served as 'application/xml' it will not effect processing of the document since the higher level protocol and the XML PI both take precedence. と、「 XML プロセサは <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> のような指定を解釈しないこと、文書作成者はそのような指定を今なおしてくるかもしれないが、よりハイレベルのプロトコルや XML 処理命令が優先される」 と変更されています。

application/xhtml+xml として文書を公開する場合の xml-stylesheet 処理命令

First Edition では When serving an XHTML document with this media type, authors SHOULD include the XML stylesheet processing instruction [XMLstyle] to associate style sheets. のように、「 application/xhtml+xml を指定する場合は、文書作成者はスタイルシートを関連付けるために xml-stylesheet 処理命令を含むべきである」と示されていました。

Second Edition (Editor's Draft 27 August 2008) では When serving an XHTML document with this media type, authors MAY include the XML stylesheet processing instruction [XMLstyle] to associate style sheets. のように、「 application/xhtml+xml を指定する場合は、文書作成者はスタイルシートを関連付けるために xml-stylesheet 処理命令を含んでもよい」 と変更されています。

XHTML Media Types の First EditionSecond Edition (Editor's Draft 27 August 2008) の違い (3)

さて、いよいよ互換性ガイドラインの変更点です。 最初からここだけまとめておけばよかったような気がしてきました。 この部分は訳文を用意する元気がありません......。

Media type XHTML 1.0 (First Edition) の Appendix C. HTML Compatibility Guidelines XHTML Media Types Second Editon (Editor's Draft 27 August 2008) の Appendix A. Compatibility Guidelines
C.1 Processing Instructions → A.1. Processing Instructions and the XML Declaration

Be aware that processing instructions are rendered on some user agents. However, also note that when the XML declaration is not included in a document, the document can only use the default character encodings UTF-8 or UTF-16.

DO NOT include XML processing instructions NOR the XML declaration.

Rationale: Some HTML user agents render XML processing instructions. Also, some user agents interpret the XML declaration to mean that the document is unrecognized XML rather than HTML. Such user agents may not render the document as expected. For compatibility with these types of HTML browsers, you should avoid using processing instructions and XML declarations.

Consequence: Remember, however, that when the XML declaration is not included in a document, AND the character encoding is not specified by a higher level protocol such as HTTP, the document can only use the default character encodings UTF-8 or UTF-16. See, however, guideline 9 below.

C.2 Empty Elements → A.2. Elements that can never have content

Include a space before the trailing / and > of empty elements, e.g. <br />, <hr /> and <img src="karen.jpg" alt="Karen" />. Also, use the minimized tag syntax for empty elements, e.g. <br />, as the alternative syntax <br></br> allowed by XML gives uncertain results in many existing user agents.

If an element has an EMPTY content model DO use the minimized tag syntax permitted by XML (e.g., <br />). DO NOT use the alternative syntax (e.g., <br></br>) allowed by XML, since this may be unsupported by HTML user agents. Also, DO include a space before the trailing / and >.

Empty elements in the XHTML family include: area, base, basefont, br, col, hr, img, input, isindex, link, meta, and param.

Rationale: HTML user agents ignore the  /> at the end of a tag, but without it they may incorrectly parse the tag or its attributes. HTML user agents also may not recognize the alternate syntax permitted by XML.

C.3 Element Minimization and Empty Element Content → A.3. Elements that have no content

Given an empty instance of an element whose content model is not EMPTY (for example, an empty title or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />).

If an element permits content (e.g., the p element) but an instance of that element has no content (e.g., an empty paragraph), DO NOT use the "minimized" tag syntax (e.g., <p />).

Rationale: HTML user agents may give uncertain results when using the the minimized syntax permitted by XML when an element has no content.

C.4 Embedded Style Sheets and Scripts → A.4. Embedded Style Sheets and Scripts

Use external style sheets if your style sheet uses < or & or ]]> or --. Use external scripts if your script uses < or & or ]]> or --. Note that XML parsers are permitted to silently remove the contents of comments. Therefore, the historical practice of "hiding" scripts and style sheets within comments to make the documents backward compatible is likely to not work as expected in XML-based implementations.

DO use external style sheets if your style sheet uses < or & or ]]> or --. DO NOT use an internal stylesheet if the style rules contain any of the above characters.

DO use external scripts if your script uses < or & or ]]> or --. DO NOT embed a script in a document if it contains any of these characters.

Rationale: XML parsers are permitted to silently remove the contents of comments. Therefore, the historical practice of "hiding" scripts and style sheets within "comments" to make the documents backward compatible may not work as expected in XML-based user agents.

@@@@Put a real example in here that works, and one that does not work@@@@

C.5 Line Breaks within Attribute Values → A.5. Line Breaks within Attribute Values

Avoid line breaks and multiple whitespace characters within attribute values. These are handled inconsistently by user agents.

DO ensure that attribute values are on a single line and only use single whitespace characters. DO NOT use line breaks and multiple consecutive white space characters within attribute values.

Rationale: These are handled inconsistently by user agents.

C.6 Isindex →

Don't include more than one isindex element in the document head. The isindex element is deprecated in favor of the input element.

 
C.7 The lang and xml:lang Attributes → A.7. The lang and xml:lang Attributes

Use both the lang and xml:lang attributes when specifying the language of an element. The value of the xml:lang attribute takes precedence.

DO use both lang and xml:lang attributes when specifying the language of an element in markup languages that support the use of both.

DO NOT use the only the lang attribute, even in languages that include it such as XHTML 1.0.

Rationale: HTML 4 documents use the lang attribute to identify the language of an element. XML documents use the xml:lang attribute. CSS has a "lang" pseudo selector that automatically uses the appropriate attribute depending on the document type. Therefore, specifying both attributes ensures that single CSS selectors will work in both modes.

C.8 Fragment Identifiers → A.8. Fragment Identifiers

In XML, URIs [RFC2396] that end with fragment identifiers of the form "#foo" do not refer to elements with an attribute name="foo"; rather, they refer to elements with an attribute defined to be of type ID, e.g., the id attribute in HTML 4. Many existing HTML clients don't support the use of ID-type attributes in this way, so identical values may be supplied for both of these attributes to ensure maximum forward and backward compatibility (e.g., <a id="foo" name="foo">...</a>).

Further, since the set of legal values for attributes of type ID is much smaller than for those of type CDATA, the type of the name attribute has been changed to NMTOKEN. This attribute is constrained such that it can only have the same values as type ID, or as the Name production in XML 1.0 Section 2.5, production 5. Unfortunately, this constraint cannot be expressed in the XHTML 1.0 DTDs. Because of this change, care must be taken when converting existing HTML documents. The values of these attributes must be unique within the document, valid, and any references to these fragment identifiers (both internal and external) must be updated should the values be changed during conversion.

Finally, note that XHTML 1.0 has deprecated the name attribute of the a, applet, form, frame, iframe, img, and map elements, and it will be removed from XHTML in subsequent versions.

DO use the id attribute to identify elements.

DO ensure that the values used for the id attribute are limited to the pattern [A-Za-z][A-Za-z0-9:_.-]*.

DO NOT use the name attribute to identify elements, even in languages that permit the use of name such as XHTML 1.0.

Rationale: In HTML 3.2 and earlier the name attribute on some elements could be used to define an anchor, but HTML 4 introduced the id attribute. In an XML dialect, only attributes with type ID are permitted to be used as anchors, and the id attribute is defined to be of type ID. Relying upon the id attribute as an anchor will work well in modern HTML and XHTML-aware user agents.

C.9 Character Encoding → A.9. Character Encoding

To specify a character encoding in the document, use both the encoding attribute specification on the xml declaration (e.g. <?xml version="1.0" encoding="EUC-JP"?>) and a meta http-equiv statement (e.g. <meta http-equiv="Content-type" content='text/html; charset="EUC-JP"' />). The value of the encoding attribute of the xml processing instruction takes precedence.

DO encode your document in UTF-8 or UTF-16. When delivering the document from a server, DO set the character encoding for a document via the charset parameter of the HTTP Content-Type header. When not delivering the document from a server, DO set the encoding via a "meta http-equiv" statement in the document (e.g., <meta http-equiv="Content-Type" content="text/html; charset=EUC-JP" />). However, note that doing so will explicitly bind the document to an a single content type.

Rationale: Since these guidelines already recommend that documents NOT contain the XML declaration, setting the encoding via the HTTP header is the only reliable mechanism compatible with HTML and XML user agents. When that mechanism is not available, the only portable fallback is the "meta http-equiv" statement.

C.10 Boolean Attributes → A.10. Boolean Attributes

Some HTML user agents are unable to interpret boolean attributes when these appear in their full (non-minimized) form, as required by XML 1.0. Note this problem doesn't affect user agents compliant with HTML 4. The following attributes are involved: compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer.

DO use the full form for boolean attributes, as required by XML (e.g., disabled="disabled"). Such attributes include: compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, and defer.

Rationale: The compact form of these attributes is not well formed XML, and therefore invalid.

C.11 Document Object Model and XHTML → A.11. Document Object Model and XHTML

The Document Object Model level 1 Recommendation [DOM] defines document object model interfaces for XML and HTML 4. The HTML 4 document object model specifies that HTML element and attribute names are returned in upper-case. The XML document object model specifies that element and attribute names are returned in the case they are specified. In XHTML 1.0, elements and attributes are specified in lower-case. This apparent difference can be addressed in two ways:

  1. Applications that access XHTML documents served as Internet media type text/html via the DOM can use the HTML DOM, and can rely upon element and attribute names being returned in upper-case from those interfaces.
  2. Applications that access XHTML documents served as Internet media types text/xml or application/xml can also use the XML DOM. Elements and attributes will be returned in lower-case. Also, some XHTML elements may or may not appear in the object tree because they are optional in the content model (e.g. the tbody element within table). This occurs because in HTML 4 some elements were permitted to be minimized such that their start and end tags are both omitted (an SGML feature). This is not possible in XML. Rather than require document authors to insert extraneous elements, XHTML has made the elements optional. Applications need to adapt to this accordingly.

DO rely upon the HTML 4 DOM as defined in The Document Object Model level 1 Recommendation [DOM] for scripting. This means, in particular, that the names of elements and attributes will be returned (from functions that return such things) in upper case.

Rationale: Using the HTML DOM will result in maximum portability of scripts, since the HTML DOM is supported in both HTML and XHTML documents in modern user agents.

C.12 Using Ampersands in Attribute Values → A.12. Using Ampersands

When an attribute value contains an ampersand, it must be expressed as a character entity reference (e.g. "&amp;"). For example, when the href attribute of the a element refers to a CGI script that takes parameters, it must be expressed as http://my.site.dom/cgi-bin/myscript.pl?class=guest&amp;name=user rather than as http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user.

DO ensure that when content or attribute values contain the reserved character & it is used in its escaped form &amp;.

Rationale: If ampersands are not encoded, the characters after them up to the next semi-colon can be interpreted as the name of a entity by the user agent.

@@@@add example@@@@

C.13 Cascading Style Sheets (CSS) and XHTML → A.13. Cascading Style Sheets (CSS) and XHTML

The Cascading Style Sheets level 2 Recommendation [CSS2] defines style properties which are applied to the parse tree of the HTML or XML document. Differences in parsing will produce different visual or aural results, depending on the selectors used. The following hints will reduce this effect for documents which are served without modification as both media types:

  1. CSS style sheets for XHTML should use lower case element and attribute names.
  2. In tables, the tbody element will be inferred by the parser of an HTML user agent, but not by the parser of an XML user agent. Therefore you should always explicitly add a tbody element if it is referred to in a CSS selector.
  3. Within the XHTML name space, user agents are expected to recognize the "id" attribute as an attribute of type ID. Therefore, style sheets should be able to continue using the shorthand "#" selector syntax even if the user agent does not read the DTD.
  4. Within the XHTML name space, user agents are expected to recognize the "class" attribute. Therefore, style sheets should be able to continue using the shorthand "." selector syntax.
  5. CSS defines different conformance rules for HTML and XML documents; be aware that the HTML rules apply to XHTML documents delivered as HTML and the XML rules apply to XHTML documents delivered as XML.

DO use lower case element and attribute names in style sheets. DO create rules that include inferred elements (e.g., the tbody element in a table).

Rationale: These simple rules will help increase the portability of CSS rules regardless of the media type the document is processed as.

@@@@add examples@@@@

→ A.14. Referencing Style Elements when serving as XML  

DO NOT use xml stylesheet declarations to identify style sheets.

DO use the style or link elements to define stylesheets.

Rationale: Since XML processing instructions may be rendered by some HTML user agents, using the standard XML stylesheet declaration mechanism may not work well. However, since XHTML user agents are required to process style and link elements and interpret stylesheets referenced from those elements, documents constructed to use them will work as expected.

→ A.15. Formfeed Character in HTML vs. XML  

Rationale: This character is recognized as white space in HTML 4, but is NOT considered white space in XML.

→ A.16. The Named Character Reference &apos;  

DO use &#39; to specify an escaped apostrophe. DO NOT use &apos;.

Rationale: The entity &apos; is not defined in HTML 4.

XHTML Media Types Second Edition が今後ドラフトになれば XML 宣言を省略する機会も増える ?

......さて、だいぶ話がそれましたが、冒頭で「 IE 6 がバグによってレンダリングモードが切り替わってしまうから、という理由だけで安易に XML 宣言を書かない、という対処をして良いものなのでしょうか」と自問していましたが、今後 XHTML Media Types Second Edition が Recommendation track に乗るようになっていけば、 XML 宣言の記述を行う・行わないの選択の理由が増えますね。

今回は自分の拙い解釈・邦訳で考えている部分があるので、「いや その解釈は おかしい」とか「それ邦訳じゃなくて超訳やん」といったご指摘をよろしくお願いします。

あと勘のいい方なら気が付いているかもしれませんが、今回の内容や昨日の DOCTYPE スイッチについてのまとめと一覧表 (HTML 5 や IE 8 Beta 2 のモードスイッチなどの情報も含んだ 2008 年版 ) は、以前実践 Web Standards Design に執筆した内容です。

リプライ

1 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2008-10-01T20:34+09:00 - No beer, No Name!

「XML 宣言を省略できる条件、というのは実は仕様には書かれてありません」とありますが、各XHTMLの仕様書の適合条件のセクションに書いてありますね。仕様ごとにutf-8/utf-16以外の文字エンコーディングをHTTPヘッダで示す方法が可能だったりいけなかったりしてややこしいのですが。

DOCTYPE スイッチについてのまとめと一覧表 (HTML 5 や IE 8 Beta 2 のモードスイッチなどの情報も含んだ 2008 年版 )

記事データ

投稿者

真琴

投稿日時

2008-09-29T01:18+09:00

タグ
概要

以前 DOCTYPE スイッチについてはまとめましたが、あれから 2 年弱が経過したので、改めてまとめてみようと思います。 DOCTYPE スイッチとは何か、でどうレンダリングが変わるのか、 HTML 5 の DOCTYPE 宣言、 IE 8 のモードスイッチなどを踏まえ、最後には一覧表を作成しています。

リプライ

2 件のリプライがあります。

記事本文

DOCTYPE スイッチについて再度まとめ

以前 DOCTYPE スイッチについての検証とまとめと一覧表という記事で DOCTYPE スイッチについてまとめましたが、あれから 2 年弱が経過したので、改めてまとめてみようと思います。

まとめるまでの話がけっこう長いので、一覧表だけ参照したい ! という場合は DOCTYPE スイッチの一覧表をご覧ください。

DOCTYPE スイッチとは何か

そもそも DOCTYPE スイッチとは何か、というのがまず書くべきところですが、これは私が書かずとも良質のリソースが各種ありますのでそのリンクのみまとめておきます。

DOCTYPE 宣言の記述によって、過去のブラウザのレンダリングを行うモード ( 後方互換モード ) と、より最新の仕様に基づいたレンダリングを行うモード ( 標準準拠モード ) を切り替えることができる、というものです。 ( 厳密には標準準拠モードを更に細分化できるのですが、ここではまとめて標準準拠モードとして扱います。 )

例えば、 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> という、システム識別子が無い DOCTYPE 宣言が記述された HTML 4.01 Transitional 文書は、ほとんどのブラウザで後方互換モードでレンダリングされます。

DOCTYPE スイッチでどうレンダリングが変わるのか

では、そのレンダリングの違いとは実際にどういったものでしょうか。 これも私が書かずとも、 2xup.org の上ノ郷谷さんが恐ろしく充実したリソースを作ってあるので、そちらを紹介します。

HTML 5 の DOCTYPE 宣言

hxxk.jp ではちょうど休止時期に入ったこともあって取り上げていませんでしたが、最近は HTML 5 に関する話題もホットになっています。 では、その HTML 5 の DOCTYPE 宣言はどうなっているのでしょうか。 仕様を追ってみましょう。

  1. 現時点での最新の Working Draft である W3C Working Draft 10 June 20088.1.1 The DOCTYPE を見ると、非常にあっさりとした記述があります。
  2. これは HTML 5 における定義を書いているだけなので、むしろ HTML 5 differences from HTML 42.2 The DOCTYPE を参照する方が良いでしょう。
  3. この文書は、ミツエーリンクスの矢倉さんが HTML 5 における HTML 4 からの変更点として翻訳されてあるので、そちらを見てみます。
  4. 2.2 DOCTYPE に、HTML 5 の HTML 構文では、ブラウザがページを標準モードで描画することを保証するため、DOCTYPE が必須となります。DOCTYPE はこのほかに何も目的を持っていないため、XML 構文での記述は任意となります。これは、XML の MIME 型で供給される文書は常に標準モードで扱われるためです。[DOCTYPE] DOCTYPE 宣言は <!DOCTYPE html> となります。HTML 構文では、大文字と小文字を区別しません。以前の HTML は SGML であり、DTD を参照する必要があったため DOCTYPE は長くなっていました。しかし、これは HTML 5 において異なり、DOCTYPE は HTML 構文において標準モードを有効にする手段として必要となっています。なお、ブラウザは現段階において既に、<!DOCTYPE html> を標準モードのトリガーとして解釈しています。とあります。

HTML 5 の場合は DOCTYPE 宣言は (XML 構文を使わないのであれば。 XML の MIME 型で供給される文書は常に標準モードで扱われますし。 ) モード切り替えのみに使われるようですね。 ちなみにこの辺りの情報は HTML5 の DOCTYPE 宣言って IE6 でも標準モードになるんですね - IT戦記でのやり取りから得ることができました。

なお、 <!DOCTYPE html> は、 In other words, <!DOCTYPE HTML>, case-insensitively. のように、大文字と小文字は区別しないとされています。

IE 8 のモードスイッチ

こちらもミツエーリンクスが提供する Web標準Blog からの情報の紹介になりますが、 IE8のモードスイッチという記事で DOCTYPE スイッチとはまた異なるモード切り替えのことが紹介されています。

IE 8 は現時点で Beta 2 ですが、 meta 要素に特定の記述をすることで、 DOCTYPEを上書きする モードスイッチを実現できます。

IE 6 では DOCTYPE 宣言より前にコメント以外の記述があれば ( それが記述することを認められている XML 宣言であっても ) 後方互換モードになるというバグが、 IE 7 では XML 宣言の区切り文字に半角スペース文字以外を用いると後方互換モードとしてレンダリングするというバグがあったのですが、これで (IE 以外には全く無意味な meta 要素を記述することにはなりますが ) 確実なモードスイッチが実現できますね。

......と思ったら、はてなブックマーク - Les cafe's blancs / 2008年09月05日にて IE8ではIE=8でもIE=7でも直ってる。ただIE=EmulateIE7にすると互換モードに。なぜー という情報も。 確かに <meta http-equiv="X-UA-Compatible" content="IE=emulateIE7" /> と指定したサンプルを作成して、 IE 8 Beta 2 で確認してみると、 半角スペース区切りの XML 宣言の XHTML 1.0 Strict では IE 7 モードでレンダリングされるのに対し、タブ文字区切りの XML 宣言の XHTML 1.0 Strict では IE 5 モードでレンダリングされました。

ちなみに、 <meta http-equiv="X-UA-Compatible" content="IE=7" /> と指定したタブ文字区切りの XML 宣言の XHTML 1.0 Strict でも <meta http-equiv="X-UA-Compatible" content="IE=8" /> と指定したタブ文字区切りの XML 宣言の XHTML 1.0 Strict でも、それぞれ本来の指定したモードでレンダリングされます。

DOCTYPE スイッチの一覧表

これまでの節で書いたことと、以前の記事の DOCTYPE スイッチについての検証とまとめと一覧表をもとに、一覧表を再作成しました。 DOCTYPE 宣言の列は、確認用のサンプルページにリンクしていますので、一覧表の記述だけではなく、実際に各種ブラウザでアクセスして確認してみてください。 なお、確認用サンプルページでは先ほど取り上げた HTML5 の DOCTYPE 宣言って IE6 でも標準モードになるんですね - IT戦記で作られた HTML5 の DOCTYPE 宣言とレンダリングモードのテストの記述を参考にさせていただきました。

DOCTYPE 宣言 Firefox 3 Firefox 2 Firefox 1 IE 8 Beta2 IE 7 IE 6 Opera 9 Opera 8 Safari 3 Safari 2 Safari 1 Google Chrome NN 8 NN 7 MacIE 5
DOCTYPE 宣言 Firefox 3 Firefox 2 Firefox 1 IE 8 Beta2 IE 7 IE 6 Opera 9 Opera 8 Safari 3 Safari 2 Safari 1 Google Chrome NN 8 NN 7 MacIE 5
DOCTYPE宣言なし 後方互換 後方互換 後方互換 IE 5 後方互換 後方互換 後方互換 後方互換 後方互換 後方互換 後方互換 後方互換 後方互換 後方互換 後方互換
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> 後方互換 後方互換 後方互換 IE 5 後方互換 後方互換 後方互換 後方互換 後方互換 後方互換 後方互換 後方互換 後方互換 後方互換 後方互換
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 標準準拠 標準準拠 標準準拠 IE 8 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"> 標準準拠 標準準拠 標準準拠 IE 8 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 後方互換
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> 標準準拠 標準準拠 標準準拠 IE 8 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 標準準拠 標準準拠 標準準拠 IE 8 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 標準準拠 標準準拠 標準準拠 IE 8 標準準拠 後方互換 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 標準準拠 標準準拠 標準準拠 IE 8 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 標準準拠 標準準拠 標準準拠 IE 8 標準準拠 後方互換 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> 標準準拠 標準準拠 標準準拠 IE 8 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> 標準準拠 標準準拠 標準準拠 IE 8 標準準拠 後方互換 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> の XML 宣言の区切りをタブ文字にしたもの 標準準拠 標準準拠 標準準拠 IE 5 後方互換 後方互換 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 テスト環境がなかったので未確認
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> の XML 宣言の区切りをタブ文字にし、 meta 要素で IE 8 モードを指定したもの 標準準拠 標準準拠 標準準拠 IE 8 後方互換 後方互換 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 テスト環境がなかったので未確認
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> の XML 宣言の区切りをタブ文字にし、 meta 要素で IE 7 モードを指定したもの 標準準拠 標準準拠 標準準拠 IE 7 後方互換 後方互換 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 テスト環境がなかったので未確認
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> の XML 宣言の区切りをタブ文字にし、 meta 要素で emulate IE 7 モードを指定したもの 標準準拠 標準準拠 標準準拠 IE 5 後方互換 後方互換 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 テスト環境がなかったので未確認
<!DOCTYPE html> 標準準拠 標準準拠 標準準拠 IE 8 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 標準準拠 テスト環境がなかったので未確認

リプライ

2 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2008-10-07T19:06+09:00 -

Gecko の場合、「標準準拠」でひとくくりにされている中に "full standards mode" と "almost standards mode" という、だいたい同じだけど一部違う区別があります。この区別もわかるような表になっているとうれしいです。

2009-02-20T16:31+09:00 - No beer, No Name!

DOCTYPEの一覧表にリンクされているXML宣言なしのXHTML 1.1のDOCTYPEのサンプルページをIE6で表示したところ、Javascriptの2つ目のアラートにundefinedが表示されました。

埼玉県内の市町村における、住民税の一括納付報奨金制度の有無のまとめ

記事データ

投稿者

真琴

投稿日時

2008-09-27T01:45+09:00

タグ
概要

ふとしたきっかけで市民税の話になり、報奨金制度が友人の住む市に存在するか、また同じ県内での状況はどうなっているかをまとめました。

リプライ

リプライはまだありません。

記事本文

友人と税について話した

lh3.jp - ホップ本の打ち合わせと HEMEL オフ会でも書いていたとおり、先週は打ち合わせと休暇を兼ねて上京していました。 上京している間は、埼玉県に住んでいる親しい友人の厚意でその家に滞在させてもらっていたのですが、何気ない会話の中で 「あれ、今月末までの税金払ったっけ......」 と思い出したことから、互いの住んでいる市町村の税について少し話しました。

私の住んでいる町では、住民税を年度最初の時点で一括して前納すると、その額に対して前納分の期に応じた率をかけた分を「一括納付報奨金」あるいは「前納報奨金」として相殺し、実質的には「割引」を行う制度が残っています。 自分の町がそうであるから、てっきりどこでもそういうものだろうと思って言ってみたら 「いやこっちはそんな制度ないみたいだよ ? 」 という答えが返ってきました。 もしその制度が友人の住む市でもあるのであれば、翌年からはそっちを選ぶよということだったので、後学も兼ねてその市および同一県内の市町村について調べてみることにしました。

埼玉県の市町村における市税の一括納付報奨金の有無の一覧表

市町村コード 市町村名 「前納」でサイト内検索 「報奨金」でサイト内検索 備考
市町村コード 市町村名 「前納」でサイト内検索 「報奨金」でサイト内検索 備考
11100 さいたま市 さいたま市サイト内で「前納」を検索 さいたま市サイト内で「報奨金」を検索  
11101   西区      
11102   北区      
11103   大宮区      
11104   見沼区      
11105   中央区      
11106   桜区      
11107   浦和区      
11108   南区      
11109   緑区      
11110   岩槻区      
11201 川越市 川越市サイト内で「前納」を検索 川越市サイト内で「報奨金」を検索  
11202 熊谷市 熊谷市サイト内で「前納」を検索 熊谷市サイト内で「報奨金」を検索  
11203 川口市 川口市サイト内で「前納」を検索 川口市サイト内で「報奨金」を検索  
11206 行田市 行田市サイト内で「前納」を検索 行田市サイト内で「報奨金」を検索  
11207 秩父市 秩父市サイト内で「前納」を検索 秩父市サイト内で「報奨金」を検索  
11208 所沢市 所沢市サイト内で「前納」を検索 所沢市サイト内で「報奨金」を検索  
11209 飯能市 飯能市サイト内で「前納」を検索 飯能市サイト内で「報奨金」を検索  
11210 加須市 加須市サイト内で「前納」を検索 加須市サイト内で「報奨金」を検索  
11211 本庄市 本庄市サイト内で「前納」を検索 本庄市サイト内で「報奨金」を検索  
11212 東松山市 東松山市サイト内で「前納」を検索 東松山市サイト内で「報奨金」を検索  
11214 春日部市 春日部市サイト内で「前納」を検索 春日部市サイト内で「報奨金」を検索  
11215 狭山市 狭山市サイト内で「前納」を検索 狭山市サイト内で「報奨金」を検索  
11216 羽生市 羽生市サイト内で「前納」を検索 羽生市サイト内で「報奨金」を検索  
11217 鴻巣市 鴻巣市サイト内で「前納」を検索 鴻巣市サイト内で「報奨金」を検索  
11218 深谷市 深谷市サイト内で「前納」を検索 深谷市サイト内で「報奨金」を検索  
11219 上尾市 上尾市サイト内で「前納」を検索 上尾市サイト内で「報奨金」を検索  
11221 草加市 草加市サイト内で「前納」を検索 草加市サイト内で「報奨金」を検索  
11222 越谷市 越谷市サイト内で「前納」を検索 越谷市サイト内で「報奨金」を検索  
11223 蕨市 蕨市サイト内で「前納」を検索 蕨市サイト内で「報奨金」を検索  
11224 戸田市 戸田市サイト内で「前納」を検索 戸田市サイト内で「報奨金」を検索  
11225 入間市 入間市サイト内で「前納」を検索 入間市サイト内で「報奨金」を検索  
11226 鳩ヶ谷市 鳩ヶ谷市サイト内で「前納」を検索 鳩ヶ谷市サイト内で「報奨金」を検索  
11227 朝霞市 朝霞市サイト内で「前納」を検索 朝霞市サイト内で「報奨金」を検索  
11228 志木市 志木市サイト内で「前納」を検索 志木市サイト内で「報奨金」を検索  
11229 和光市 和光市サイト内で「前納」を検索 和光市サイト内で「報奨金」を検索  
11230 新座市 新座市サイト内で「前納」を検索 新座市サイト内で「報奨金」を検索 広聴 67 前納報奨金制度の復活をによると、平成 11 年度までは報奨金制度があったことがうかがえる
11231 桶川市 桶川市サイト内で「前納」を検索 桶川市サイト内で「報奨金」を検索  
11232 久喜市 久喜市サイト内で「前納」を検索 久喜市サイト内で「報奨金」を検索  
11233 北本市 北本市サイト内で「前納」を検索 北本市サイト内で「報奨金」を検索  
11234 八潮市 八潮市サイト内で「前納」を検索 八潮市サイト内で「報奨金」を検索 八潮市税条例第 25 条によると、昭和 56 年度分のみ報奨金制度があった模様
11235 富士見市 富士見市サイト内で「前納」を検索 富士見市サイト内で「報奨金」を検索  
11237 三郷市 三郷市サイト内で「前納」を検索 三郷市サイト内で「報奨金」を検索  
11238 蓮田市 蓮田市サイト内で「前納」を検索 蓮田市サイト内で「報奨金」を検索  
11239 坂戸市 坂戸市サイト内で「前納」を検索 坂戸市サイト内で「報奨金」を検索  
11240 幸手市 幸手市サイト内で「前納」を検索 幸手市サイト内で「報奨金」を検索  
11241 鶴ヶ島市 鶴ヶ島市サイト内で「前納」を検索 鶴ヶ島市サイト内で「報奨金」を検索  
11242 日高市 日高市サイト内で「前納」を検索 日高市サイト内で「報奨金」を検索  
11243 吉川市 吉川市サイト内で「前納」を検索 吉川市サイト内で「報奨金」を検索  
11245 ふじみ野市 ふじみ野市サイト内で「前納」を検索 ふじみ野市サイト内で「報奨金」を検索  
11300 北足立郡
11301 伊奈町 伊奈町サイト内で「前納」を検索 伊奈町サイト内で「報奨金」を検索  
11320 入間郡
11324 三芳町 三芳町サイト内で「前納」を検索 三芳町サイト内で「報奨金」を検索  
11326 毛呂山町 毛呂山町サイト内で「前納」を検索 毛呂山町サイト内で「報奨金」を検索  
11327 越生町 越生町サイト内で「前納」を検索 越生町サイト内で「報奨金」を検索  
11340 比企郡
11341 滑川町 滑川町サイト内で「前納」を検索 滑川町サイト内で「報奨金」を検索  
11342 嵐山町 嵐山町サイト内で「前納」を検索 嵐山町サイト内で「報奨金」を検索  
11343 小川町 小川町サイト内で「前納」を検索 小川町サイト内で「報奨金」を検索  
11346 川島町 川島町サイト内で「前納」を検索 川島町サイト内で「報奨金」を検索  
11347 吉見町 吉見町サイト内で「前納」を検索 吉見町サイト内で「報奨金」を検索  
11348 鳩山町 鳩山町サイト内で「前納」を検索 鳩山町サイト内で「報奨金」を検索  
11349 ときがわ町 ときがわ町サイト内で「前納」を検索 ときがわ町サイト内で「報奨金」を検索  
11360 秩父郡
11361 横瀬町 横瀬町サイト内で「前納」を検索 横瀬町サイト内で「報奨金」を検索  
11362 皆野町 皆野町サイト内で「前納」を検索 皆野町サイト内で「報奨金」を検索 皆野町税条例の経過措置により、以前は報奨金制度があった模様
11363 長瀞町 長瀞町サイト内で「前納」を検索 長瀞町サイト内で「報奨金」を検索 長瀞町税条例には報奨金の記載は無いが、長瀞町税条例施行規則にある納付書様式には報奨金の欄がある
11365 小鹿野町 小鹿野町サイト内で「前納」を検索 小鹿野町サイト内で「報奨金」を検索  
11369 東秩父村 東秩父村サイト内で「前納」を検索 東秩父村サイト内で「報奨金」を検索  
11380 児玉郡
11381 美里町 美里町サイト内で「前納」を検索 美里町サイト内で「報奨金」を検索  
11383 神川町 神川町サイト内で「前納」を検索 神川町サイト内で「報奨金」を検索  
11385 上里町 上里町サイト内で「前納」を検索 上里町サイト内で「報奨金」を検索  
11400 大里郡
11408 寄居町 寄居町サイト内で「前納」を検索 寄居町サイト内で「報奨金」を検索  
11420 北埼玉郡
11421 騎西町 騎西町サイト内で「前納」を検索 騎西町サイト内で「報奨金」を検索  
11424 北川辺町 北川辺町サイト内で「前納」を検索 北川辺町サイト内で「報奨金」を検索  
11425 大利根町 大利根町サイト内で「前納」を検索 大利根町サイト内で「報奨金」を検索  
11440 南埼玉郡
11442 宮代町 宮代町サイト内で「前納」を検索 宮代町サイト内で「報奨金」を検索 シリーズ行政改革/第4回 宮代町の税金は高い?/宮代町によると、平成 9 年度に町税、平成 12 年度に固定資産税の報奨金制度を廃止した模様
11445 白岡町 白岡町サイト内で「前納」を検索 白岡町サイト内で「報奨金」を検索  
11446 菖蒲町 菖蒲町サイト内で「前納」を検索 菖蒲町サイト内で「報奨金」を検索  
11460 北葛飾郡
11461 栗橋町 栗橋町サイト内で「前納」を検索 栗橋町サイト内で「報奨金」を検索
11462 鷲宮町 鷲宮町サイト内で「前納」を検索 鷲宮町サイト内で「報奨金」を検索  
11464 杉戸町 杉戸町サイト内で「前納」を検索 杉戸町サイト内で「報奨金」を検索  
11465 松伏町 松伏町サイト内で「前納」を検索 松伏町サイト内で「報奨金」を検索 松伏町サイト内で「報奨金」を検索すると、平成 11 年度に松伏町集中改革プランにて報奨金制度を廃止した旨の .doc ファイルがヒットする

住民税に対する報奨金制度は廃止の方向 ?

結果はこの表の通りで、ほとんどの市町村で住民税に対する報奨金制度は存在しないか、あるいは過去に存在していたが廃止されているかのどちらかのようです。 詳しい解説は省きますが、特別徴収 ( いわゆる給与天引き ) の場合はその都度天引きされて納付する形になるため、サラリーマン等の場合は一括前納したくてもできず、不公平が生じるという理由によって廃止が相次いでいるようです。

対して、給与天引きではない類のもの、例えば下水道事業受益者負担金や、国民年金の保険料などは現在でも報奨金制度が残っています。 下水道事業受益者負担金は市町村によって条例が違いますので、国民年金前納割引制度の方を参考にすると良いでしょう。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

「存在しないはてなキーワード」の適切なレスポンスや、そのキーワードが生成される理由などの考察

記事データ

投稿者

真琴

投稿日時

2008-09-26T00:30+09:00

タグ
概要

解説が書かれていないはてなキーワードは、ユーザがリクエストした文字列に対する情報を返せていないので、 404 Not Found のレスポンスを返すのが適切だと考えました。また、書籍の著者名などでこういったキーワードが生成されるようなので、それについての考察も行っています。

リプライ

6 件のリプライがあります。

記事本文

404 Not Found で良いんじゃないかなあ

はてなのキーワードページに関して起こっているここ数日のやり取りについては、私も色々と思うことがあるのですが、関連リソースを全て追えていません。 そのためそれまでの経緯は書きませんが、昨日公開された存在しないキーワードへのリンクに nofollow 属性を追加しました - はてなダイアリー日記という記事のコメント欄のやり取りでちょっと気になった点があり、 RFC を読み返すことになったのでメモ。

phaedra 2008/09/24 22:18 存在しないのに404じゃないんですか?

yukichi99 2008/09/24 23:22 これからキーワードの中身を作るんだから、404じゃないでしょう。ウィキペディアで存在しない記事を指定するのと同じですよ。

この存在しないキーワードというのは、はてなキーワードにその時点で登録されていないキーワードであって、作成予定のキーワードではないと思うんですが......。 はてなキーワードのトップページの検索ボックスに適当な文字列を入力してもこのキーワードはまだ作成されていません。という結果が返ってきますし、その全てが作成予定の文字列ではないと思います。

もっとも、「このキーワードはまだ作成されていません。」という表現だけを見れば これからキーワードの中身を作る と考えられなくもありません。 これは「このキーワードはまだ作成されていません。」ではなくて「このキーワードは存在していません。」などの言い回しであれば起こらない勘違いでありますが。 ( 後述しますが、「まだ作成されていません」と書かざるを得ない事情がはてなキーワードには存在します。 )

さて、これから作るのか作らないのかは置いておいて、リクエストされた内容 ( ユーザが求めるキーワード文字列に対する解説 ) が実際には存在していない状態を RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 と照らし合わせてみました。

200 OK だと、

10.2.1 200 OK

The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

GET

an entity corresponding to the requested resource is sent in the response;

HEAD

the entity-header fields corresponding to the requested resource are sent in the response without any message-body;

POST

an entity describing or containing the result of the action;

とあるように、 The information returned with the response 、すなわちリクエストに応じた情報がレスポンスとして返されることです。

404 Not Found だと、

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

とあるように、 The server has not found anything matching the Request-URI. 、すなわち Request-URI にマッチするものが無かったということです。 それは一時的なものか恒久的なものかということは関係ないため、キーワードとして作成されていないのか、あるいは作成予定のキーワードであるがまだ解説が書かれていないのかという区別をしなくても、 200 OK ではなく 404 Not Found を返される方が適切かと思います。

解説が無い状態のキーワードに対して 200 OK を返す今の現状を恣意的な書き方をすると、

  1. ユーザが「望月真琴」って誰なのさ ? と思ってはてなキーワードの望月真琴にアクセスする (Request)
  2. はてなのサーバが Request に応じてはてなキーワードの望月真琴のページをユーザに返す (Response: 200 OK)
  3. ユーザ「いや俺が知りたいのはその人の情報であって『このキーワードはまだ作成されていません。』っていうガッカリ回答じゃないんだよ ! 」
  4. はてなのサーバ「うっせばが ! 今こっちが持っているソイツの情報はないけどオマエが聞いてくるもんだから答えてやったんだよ ! 」
  5. ユーザ「無いなら無いでそう (404 Not Found) 言えよ ! 一瞬だけ『はいはいその人の情報あるよーあるよー』 (200 OK) とか思わせぶりなことすんな ! 」

という感じですよね。 まあ、これは Wikipedia の存在しない記事の表示でも同じことが言えますが......

そもそも何故そのようなキーワードページが生成されるか

望月真琴とは - はてなキーワードを先ほど例に出しましたが、このキーワードも ( この記事執筆時点では ) 「このキーワードはまだ作成されていません。」なキーワードです。 これは次に示す順序で自動で生成されたものと思われます。

  1. 書籍を執筆する
  2. Amazon に実践 Web Standards Design - Web 標準の基本と CSS レイアウト &Tips が登録される
  3. 実践Web Standards Design―Web標準の基本とCSSレイアウト&Tips - はてなダイアリーが生成される
  4. 著者名は自動的にキーワードとして作成され、望月真琴とは - はてなキーワードが生成される

少なくとも、 ASIN コードが存在する書籍の著者名はこのようにしてキーワードページが生成されています。 もしかしたら著者名以外でも「このキーワードはまだ作成されていません。」なキーワードがあるかもしれませんが、今回は自分の名前のキーワードが「このキーワードはまだ作成されていません。」なキーワードだったので、それを例にとりました。

有名な著者であればはてなユーザによってキーワードとしての解説がされているため、自動生成で作成されたキーワードについては「このキーワードはまだ作成されていません。」という言い回しになっているのではないか、と推測しています。

現時点では「 ASIN ページ→著者名キーワード」という方向でキーワードリンクが存在するのみで、逆方向の「著者名キーワード→その著者が関わった ASIN ページ」へのリンクがありません。 自動生成の際に、そのリンクを解説欄に自動で記述していれば「このキーワードはまだ作成されていません。」よりは印象が違っていたと思うのですが......。 ( ちなみに、解説欄ではなくて関連商品のサムネイルという形で ASIN ページへのリンクがあるにはありますが、望月真琴とは - はてなキーワードのように、名前が被っているだけで著者本人には全く関係の無い商品も表示されています。 )

トラックバック送信先

存在しないキーワードへのリンクに nofollow 属性を追加しました - はてなダイアリー日記

解説が書かれていないはてなキーワードは、ユーザがリクエストした文字列に対する情報を返せていないので、 404 Not Found のレスポンスを返すのが適切だと考えました。

リプライ

6 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2008-09-26T07:15+09:00 - 瑠璃

はてなキーワードの仕組みを理解しているわけじゃないのでアレですが。「作成されていないキーワード」はあくまでも「作成されていない」のであって、自動生成されたという書き方は語弊があるような気がします。なぜなら、キーワードとして登録されてはいるが説明文のない「説明待ちのキーワード」というものがありますので、「作成されていない~」とは明確に異なります。参考→http://d.hatena.ne.jp/keywordlist?s=empty

2008-09-26T07:20+09:00 - 瑠璃

本題の、作成されていないキーワードページに対しては「キーワードして存在していない」のだから404でいいんじゃない?派(何)です。

2008-09-26T08:06+09:00 - 瑠璃

連投すみません。最初のコメントで「語弊がある」と書いたものの、「作成されていません」と表示されるものは出鱈目な語句を入力した場合とは異なる表示をするので、「自動生成された」というのも間違っているわけではないですね。すみません。(そのあたりが議論をややこしくしている一因なのでしょうが)

2008-09-26T12:33+09:00 - nagise

キーワード参照のURLと新規キーワード登録のURLが違えばいいんじゃないですかね。http://d.hatena.ne.jp/Nagise/20080925/1222346563

2008-10-07T23:50+09:00 - 望月真琴

>瑠璃さん 今回は書籍の著者を例に出しましたけど、他にも自動生成されるパターンはありますね( Wikipedia に存在していてはてなキーワードにない語句とか)。そういったキーワードに対するはてな側の表現がややこしさを増大させているような気がします。

2008-10-07T23:55+09:00 - 望月真琴

> nagise さん たとえば私の名前のキーワードだと http://d.hatena.ne.jp/keyword?mode=edit&word=%CB%BE%B7%EE%BF%BF%B6%D7 になっていますね。<キーワード登録

Twitter のアカウント ( 融合 | 混線 ) および DM の消去に関するまとめ

記事データ

投稿者

真琴

投稿日時

2008-09-23T22:51+09:00

タグ
概要

Twitter でアカウントの ( 融合 | 混線 ) が起こっているようで、他のユーザのセンシティブじな情報が見えてしまう不具合が発生しています。また、 DM を送信側が消すと、相手の受信ボックスからも該当する DM が消えるようです。

リプライ

リプライはまだありません。

記事本文

Twitter でアカウントの ( 融合 | 混線 ) が起こっているもよう

weblog の更新が激減する代わりに、 Twitter で簡単な近況報告を繰り返していたのですが、この Twitter というサービス、不具合が頻繁に起こるのが特徴という側面も持っています。 表示が重いとか他人の投稿が見られないといったことはしょっちゅうで、そのへんも Twitter の「味」みたいなものだとユーザも理解して使っているのですが。

今日は大きなバグが発生したらしく、アカウントの融合、あるいは混線と表現するような事態が起こっています。 Twitter混線した人集まれ - はてなグループ::ついったー部といったスレッドも立っているもよう。 私の follower 中にも何名かいらっしゃったのですが、これまでのような悠長な不具合ではないようです。

@LeapYear のページを表示しようとしても、 @denimu のページが表示されるといったように、

  1. あ......ありのまま 今 起こった事を話すぜ!
  2. おれは自分の twitter アカウントにログインしたと思ったらいつのまにか他人になってログインしていた
  3. な......何を言ってるのか わからねーと思うが おれも何をされたのかわからなかった......
  4. 頭がどうにかなりそうだった......
  5. ゼロデイ(0day)攻撃だとかセッションハイジャックだとか そんなチャチなもんじゃあ 断じてねえ
  6. もっと恐ろしいものの片鱗を味わったぜ......

みたいな感じでしょうか。 AA ネタで軽く言っていますが、これって

  • 混線した相手に代わってユーザの (follow|remove|block) ができる
  • 混線した相手の Direct Messages を読むことができる
  • 混線した相手が follow しているユーザであれば、本来自分が follow していない protected なユーザの発言を見ることができる

ということですよね。 もし混線が起こった場合は相手に何らかの手段で連絡してあげた方がよいでしょう。 そして混線相手のセンシティブな情報は見ないようにする、ということも忘れずに。

アカウントの ( 融合 | 混線 ) 騒ぎで分かった DM の仕様

混線した相手の DM を読むことができる、ということで、混線が今起こっていない、あるいは起こっているかもしれないがそういった連絡が来ていないユーザも、携帯電話の番号などの個人情報を含む DM を念のため消去する動きがありました。

私もそれに倣って DM を消したのですが、今度はその DM を送っていた相手から「いつの間にか DM が消えていた」という反応がありました。

これって自分が送信したものを消すと相手の受信箱からも消える、ってことは流石にないですよね?と呟いていたら、他のユーザから確か消えるんじゃなかったかな、と思います。という答えが返ってきたので、その方に協力してもらってテストをしてみました。

  1. @Nekomimi にテストで DM を送ってみました。おうさまのみみはー?
  2. @hxxk ねこのみみー
  3. @Nekomimi おお、どもー。で、 DM 消してみました。残っていますか?
  4. @hxxk 先ほどのDMが、消えましたー。

結果はこの通り。 今回のバグに限らず、自分から送信した DM を消すと、相手の DM の受信ボックスからも消えるようです。 今回の件で初めて気付きましたが、相手の受信ボックスの分まで消せる仕様ってすごいですね......

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

そろそろアウトプットを増やしていきたい

記事データ

投稿者

真琴

投稿日時

2008-09-23T17:08+09:00

タグ
概要

web の話題以外も、自分のパーソナル weblog なんだからどんどん書いていこう、と思いました。あと最近はクイズマジックアカデミーDSをプレイしているので、ユーザデータを公開しておきます。

リプライ

リプライはまだありません。

記事本文

web じゃない話題も書いていこう

lh3.jp - ホップ本の打ち合わせと HEMEL オフ会に、今回東京に行ったことについて少しだけ触れていますが、その時 ( と言ってもそのオフ会中ではなくて、滞在先の夜など ) に今後このサイトや自分をどのように動かしていくのかなあと考えました。

ここ 1 年以上の更新頻度からも分かるように、 web に対する興味は以前より大幅に少なくなっています。 web 制作系にキャリアチェンジするつもりは元来ありませんでしたが、それならこのサイトももうちょっとパーソナル寄りにしてもいいのではないかなと考えました。 もちろん今後全く web の話題に触れないというつもりではありませんが、もう少し肩の力を抜いてアウトプットの頻度を上げていこうかなと思っています。

クイズマジックアカデミーDS の友達コードを公開しておく

そして早速軽い話題を振るのですが、最近は寝る前にクイズマジックアカデミーDS を少しだけプレイする、というのが日課になっています。 帰宅後もやることは色々ありますし、常に Wi-Fi 接続でプレイしているわけではありません ( Wi-Fi 接続してプレイすると、どうしても出題時などに多少もたつくのです ) が、もし見かけたらよろしくお願いします。

プレイヤー名・学校名
  • まこち
  • 私立ホップ学園
使用キャラクター
友達コード
  • 253563735793

ゲームセンターでも時々クイズマジックアカデミーはプレイしていたのですが、待ち合わせの時間調整の時にプレイする、といった程度だったのでレベルは低いと思います。 「こんな簡単な問題で間違えるかよふつー」なんて思わないでくださいね......。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

補足情報

著作、講演、制作実績など