Bug #3990: tests of rexml/rss reports many errors and failures without iconv

• Status: Closed
• Assignee: kou (Kouhei Sutou)
• Target version: 2.0.0
• ruby -v: -

[usa (Usaku NAKAMURA)]

=begin
iconv.soがない環境でtest-allを実行すると、rexmlとrssのテストで
結構な数のEとFが発生します。
ひどいテストになると require "iconv" とかいきなり書いてあったり
とかします。

そもそも現代だとiconvを使う必然性がほとんどないと思うのですが、
どうでしょうか?(代わりにString#encodeを使う)
それが叶わないなら、せめてテストでiconv必須なものはiconvがないなら
skipするようにしてほしいです。
=end

[kou (Kouhei Sutou)]

=begin

iconv.soがない環境でtest-allを実行すると、rexmlとrssのテストで
結構な数のEとFが発生します。
ひどいテストになると require "iconv" とかいきなり書いてあったり
とかします。

そもそも現代だとiconvを使う必然性がほとんどないと思うのですが、
どうでしょうか?(代わりにString#encodeを使う)
それが叶わないなら、せめてテストでiconv必須なものはiconvがないなら
skipするようにしてほしいです。

週末にでもそんな感じにしておきます！

=end

[nobu (Nobuyoshi Nakada)]

=begin
なかだです。

At Wed, 27 Oct 2010 20:48:08 +0900,
Usaku NAKAMURA wrote in [ruby-dev:42464]:

そもそも現代だとiconvを使う必然性がほとんどないと思うのですが、
どうでしょうか?(代わりにString#encodeを使う)

さっくりext/iconv削除しますか。

--
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
中田 伸悦

=end

[naruse (Yui NARUSE)]

=begin
(2010/10/27 23:40), Nobuyoshi Nakada wrote:

なかだです。

At Wed, 27 Oct 2010 20:48:08 +0900,
Usaku NAKAMURA wrote in [ruby-dev:42464]:

そもそも現代だとiconvを使う必然性がほとんどないと思うのですが、
どうでしょうか?(代わりにString#encodeを使う)

さっくりext/iconv削除しますか。

まだその時じゃないでしょう。
2.0 での消滅は既定路線だとも思っていますが。

--
NARUSE, Yui [e-mail]

=end

[usa (Usaku NAKAMURA)]

=begin
こんにちは、なかむら(う)です。

In message "[ruby-dev:42466] Re: [Ruby 1.9-Bug#3990][Assigned] tests of rexml/rss reports many errors and failures without iconv"
on Oct.27,2010 23:40:38, [e-mail] wrote:

そもそも現代だとiconvを使う必然性がほとんどないと思うのですが、
どうでしょうか?(代わりにString#encodeを使う)

さっくりext/iconv削除しますか。

iconv要らない派の私ではありますが、プラットフォーム間互換性の
維持の観点から、いきなりの削除には強く反対します。
1.9.3までは「もうすぐ消すよ」警告くらいが適切ではないでしょう
か。

あとまあ、ext/iconvが標準で添付されるべきかどうかには強い疑念
を抱いてはいますが、敢えてそれを使う場面もありえるとは思って
います。

それでは。

U.Nakamura [e-mail]

=end

[sorah (Sorah Fukumori)]

=begin
Shota Fukumori (sora_h)です。

rexmlのテストはとりあえずiconvを回避するようにしてみましたがいかがでしょうか。

diff --git test/rexml/test_changing_encoding.rb test/rexml/test_changing_encoding.rb
index f83247a..7bb465b 100644
--- test/rexml/test_changing_encoding.rb
+++ test/rexml/test_changing_encoding.rb
@@ -1,15 +1,13 @@
#!/usr/bin/ruby -Ku

-- coding: utf-8 --

-require 'kconv'
-require 'iconv'
require 'rexml/encoding'

class ChangingEncodings < Test::Unit::TestCase
def initialize a
@u = 'テスト ほげ ふが 美しい'

• @e = Kconv.toeuc(@u)

• @e = @u.encode('euc-jp')
  @f = Foo.new
  super
  end
  diff --git test/rexml/test_core.rb test/rexml/test_core.rb
  index 48a31ae..461f7f2 100644
  --- test/rexml/test_core.rb
  +++ test/rexml/test_core.rb
  @@ -1123,7 +1123,6 @@ EOL
  end

def test_repeated_writes

• require 'iconv'
  a = IO.read(fixture_path("iso8859-1.xml"))
  f = REXML::Formatters::Pretty.new

=end

[kou (Kouhei Sutou)]

=begin

iconv.soがない環境でtest-allを実行すると、rexmlとrssのテストで
結構な数のEとFが発生します。
ひどいテストになると require "iconv" とかいきなり書いてあったり
とかします。

手元でiconv.soを消して試してみたのですが、rssのテストは失敗
しませんでした。（rexmlは失敗しました。）

結構な数のEとFの結果を見せてもらえますか？

=end

[kou (Kouhei Sutou)]

=begin

rexmlのテストはとりあえずiconvを回避するようにしてみましたがいかがでしょうか。

テストだけじゃなくて本体も直さないといけないので、これだけだ
と足りないと思います。

=end

[kou (Kouhei Sutou)]

• Status changed from Assigned to Closed
• % Done changed from 0 to 100

=begin
This issue was solved with changeset r29646.
Usaku, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

=end

[ko1 (Koichi Sasada)]

=begin
　ささだです。

(2010/10/30 10:33), Kouhei Sutou wrote:

iconv.soがない環境でtest-allを実行すると、rexmlとrssのテストで
結構な数のEとFが発生します。
ひどいテストになると require "iconv" とかいきなり書いてあったり
とかします。

手元でiconv.soを消して試してみたのですが、rssのテストは失敗
しませんでした。（rexmlは失敗しました。）

結構な数のEとFの結果を見せてもらえますか？

　mswin32 で iconv.so （とか、zlib とか openssl とか）の無い環境でやって
みました。skip を除いた結果を送ります。

ruby 1.9.3dev (2010-10-30 trunk 29647) [i386-mswin32_100]

1. Error:
   test_pos(ContribTester):
   Errno::ENOENT: No such file or directory - /tmp/tidal7916
   C:/ko1/src/ruby/clean-trunk/test/rexml/test_contrib.rb:524:in
   initialize' C:/ko1/src/ruby/clean-trunk/test/rexml/test_contrib.rb:524:in open'
   C:/ko1/src/ruby/clean-trunk/test/rexml/test_contrib.rb:524:in `test_pos'

2. Failure:
   test_utime(TestFileExhaustive)
   [C:/ko1/src/ruby/clean-trunk/test/ruby/test_file_
   exhaustive.rb:347]:
   <2000-01-01 00:00:01 +0000> expected but was
   <1999-12-31 23:00:01 +0000>.

3. Error:
   test_install_check_dependencies_install_dir(TestGemInstaller):
   Errno::EACCES: Permission denied -
   (C:/Users/ko1/AppData/Local/Temp/test_rubygem
   s_7916/gemhome, C:/Users/ko1/AppData/Local/Temp/test_rubygems_7916/gemhome2)

C:/ko1/src/ruby/clean-trunk/test/rubygems/test_gem_installer.rb:598:in test _install_check_dependencies_install_dir' C:/ko1/src/ruby/clean-trunk/test/runner.rb:19:in '

41. Failure:
    test_utime(TestPathname)
    [C:/ko1/src/ruby/clean-trunk/test/pathname/test_pathnam
    e.rb:928]:
    <2000-01-01 00:00:00 UTC> expected but was
    <1999-12-31 23:00:00 +0000>.

8143 tests, 1871492 assertions, 2 failures, 2 errors, 53 skips

Test run options: --seed 17133 --verbose
NMAKE : fatal error U1077: '.\ruby.exe' : リターン コード '0x4'
Stop.

　1 は、何か変えてもらったほうがいいかも。

　8、41 は、今、環境がが夏時間だからかなぁ？

　25 は、なぜ Permission denied か。

--
// SASADA Koichi at atdot dot net

=end

[usa (Usaku NAKAMURA)]

=begin
こんにちは、なかむら(う)です。

In message "[ruby-dev:42498] Re: [Ruby 1.9-Bug#3990][Assigned] tests of rexml/rss reports many errors and failures without iconv"
on Oct.30,2010 18:33:34, [e-mail] wrote:

iconv.soがない環境でtest-allを実行すると、rexmlとrssのテストで
結構な数のEとFが発生します。
ひどいテストになると require "iconv" とかいきなり書いてあったり
とかします。

手元でiconv.soを消して試してみたのですが、rssのテストは失敗
しませんでした。（rexmlは失敗しました。）

結構な数のEとFの結果を見せてもらえますか？

え、そんな馬鹿な、と思ったら、今のtrunkだと発生しなくなってい
ますね...
って順序前後だけどr29646のおかげじゃないのかしら。
とりあえず、そういうわけなので現状で問題はないような気がしま
す。
必要なら前のリビジョンまで巻き戻して確認しますけど、要ります?

それでは。

U.Nakamura [e-mail]

=end

[kou (Kouhei Sutou)]

=begin

手元でiconv.soを消して試してみたのですが、rssのテストは失敗
しませんでした。（rexmlは失敗しました。）

結構な数のEとFの結果を見せてもらえますか？

え、そんな馬鹿な、と思ったら、今のtrunkだと発生しなくなってい
ますね...
って順序前後だけどr29646のおかげじゃないのかしら。

あ、それは、たぶんそうです。
直したつもりなので。

とりあえず、そういうわけなので現状で問題はないような気がしま
す。
必要なら前のリビジョンまで巻き戻して確認しますけど、要ります?

いえ、現状で問題ないのであれば必要ないです。

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

(2010/10/30 21:17), Kouhei Sutou wrote:

チケット #3990 が更新されました。 (by Kouhei Sutou)
This issue was solved with changeset r29646.

Author: kou kou@b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Date: Sat Oct 30 12:10:56 2010 +0000

* lib/rexml/encoding.rb: use Ruby native encoding mechnism.  [ruby-dev:42464]
* lib/rexml/encodings/: remove.

* lib/rexml/document.rb, lib/rexml/formatters/default.rb,
  lib/rexml/output.rb, lib/rexml/parseexception.rb,
  lib/rexml/parsers/baseparser.rb, lib/rexml/source.rb,
  lib/rexml/xmldecl.rb: use Ruby's native Encoding object.

* test/rexml/, test/rss/: follow the above encoding chagnes.

* NEWS: add REXML's incompatible change about encoding.

この変更では、Ruby M17N の encoding system を使うようにしていますが、
導入した非互換変更には反対です。

総論として、REXML は Ruby 的に非推奨という扱いになりつつあるというのは
合意がとれていると思われるところ、この状況下で非互換変更をするのは
避けるべきだと思います。

また、今回の REXML::Document#encoding, REXML::XMLdecl#encoding,
REXML::Output#encoding and REXML::Source#encoding は、
ドキュメントが自称しているエンコーディングと、Ruby が解釈し使っている
エンコーディングは分離するべきでしょう。
直近では UTF-16BE/UTF-16LE は BOM なしを意味するので、
BOM 付きの UTF-16 が欲しいときに困ります。
（なお、UTF-16 は ASCII incompatible なので色々バグってる気がする）

というわけで、encoding メソッドは以前のままにして、Encoding オブジェクトを
返すメソッドを新設した方がよいのではないかと思います。

--
NARUSE, Yui [e-mail]

=end

[kou (Kouhei Sutou)]

=begin
須藤です。

In [e-mail]
"[ruby-dev:42510] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Tue, 2 Nov 2010 03:15:40 +0900,
"NARUSE, Yui" [e-mail] wrote:

この変更では、Ruby M17N の encoding system を使うようにしていますが、
導入した非互換変更には反対です。

その意見はわからなくもわからなくもないです。
私も迷いました。

ただ、反対の理由として以下は弱いと感じます。
非推奨とかいつなくなるとかが確定しているくらい必要だと感じま
す。

総論として、REXML は Ruby 的に非推奨という扱いになりつつあるというのは
合意がとれていると思われるところ、この状況下で非互換変更をするのは
避けるべきだと思います。

個人的には標準添付されているXMLパーサはRubyのみで書かれたも
のの方がいいと思っています。Nokogiriとかはgemでいいと思って
います。

また、今回の REXML::Document#encoding, REXML::XMLdecl#encoding,
REXML::Output#encoding and REXML::Source#encoding は、
ドキュメントが自称しているエンコーディングと、Ruby が解釈し使っている
エンコーディングは分離するべきでしょう。

意図していることを理解できている自信がないのですが、エンコー
ディングを表すのにEncodingオブジェクトを使うのはよくない、と
いうことですか？

直近では UTF-16BE/UTF-16LE は BOM なしを意味するので、
BOM 付きの UTF-16 が欲しいときに困ります。
（なお、UTF-16 は ASCII incompatible なので色々バグってる気がする）

もともとREXMLは出力時にBOMをつけないのですが、BOM付きの
UTF-16が必要になるのはどういう場面を想定していますか？

ここも意図を理解している自信がないのですが、RubyのEncodingは
まだIconvの代わりには使えないということですか？

というわけで、encoding メソッドは以前のままにして、Encoding オブジェクトを
返すメソッドを新設した方がよいのではないかと思います。

encodingよりもEncodingオブジェクトを返すのに適切な名前を思い
つけないので、そういうAPIにはしない方がよいと思っています。

=end

[naruse (Yui NARUSE)]

=begin
(2010/11/02 21:50), Kouhei Sutou wrote:

須藤です。

[e-mail]
"[ruby-dev:42510] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports
many errors and failures without iconv" on Tue, 2 Nov 2010 03:15:40 +0900,
"NARUSE, Yui"[e-mail] wrote:

この変更では、Ruby M17N の encoding system を使うようにしていますが、
導入した非互換変更には反対です。

その意見はわからなくもわからなくもないです。
私も迷いました。

ただ、反対の理由として以下は弱いと感じます。
非推奨とかいつなくなるとかが確定しているくらい必要だと感じます。

わざわざ非互換を入れるようなライブラリではないという趣旨です。
必然性のある物ならばしょうがないですが、これは違うと思います。

総論として、REXML は Ruby 的に非推奨という扱いになりつつあるというのは
合意がとれていると思われるところ、この状況下で非互換変更をするのは
避けるべきだと思います。

個人的には標準添付されているXMLパーサはRubyのみで書かれたも
のの方がいいと思っています。Nokogiriとかはgemでいいと思って
います。

Nokogiri を添付すべきだとは言っていません。

また、今回の REXML::Document#encoding, REXML::XMLdecl#encoding,
REXML::Output#encoding and REXML::Source#encoding は、
ドキュメントが自称しているエンコーディングと、Ruby が解釈し使っている
エンコーディングは分離するべきでしょう。

意図していることを理解できている自信がないのですが、エンコー
ディングを表すのにEncodingオブジェクトを使うのはよくない、と
いうことですか？

はい。
それぞれのエンコーディングの実際上の射程範囲は文脈によって代わります。
そして、HTTP や HTML、XML などのエンコーディングと、Ruby M17N の
エンコーディングは一部射程範囲が異なります。

直近では UTF-16BE/UTF-16LE は BOM なしを意味するので、
BOM 付きの UTF-16 が欲しいときに困ります。
（なお、UTF-16 は ASCII incompatible なので色々バグってる気がする）

もともとREXMLは出力時にBOMをつけないのですが、BOM付きの
UTF-16が必要になるのはどういう場面を想定していますか？

BOM をつけないのは UTF-8 の話ではありませんか。
たとえば、1.9.2 までは以下で BOM 付き big endian な UTF-16 で出力しますね。

require 'rexml/document'
doc = REXML::Document.new
doc << REXML::XMLDecl.new('1.0', 'UTF-16')
doc.write(s="")
=> "\xFE\xFF\x00<\x00?\x00x\x00m\x00l\xFE\xFF\x00 \x00v\x00e\x00r\x00s\x00i\x00o\x00n\x00=\x00'\x00"

これの結果は、現在以下の通りになってしまっています。
=> ""

これによって、少なくとも XMLDecl#encoding の戻り値の意味は、
XML 宣言の encoding 属性で用いられる値であって、内容の Ruby の文脈における
encoding とは異なる物であるといえるのではないでしょうか。
そもそも、UTF-16 の場合 UTF-8 に変換して扱うし。

ここも意図を理解している自信がないのですが、RubyのEncodingは
まだIconvの代わりには使えないということですか？

まず、文字列のエンコーディングを扱う部分と、変換を司る transcode を
分けて考える必要があります。
で、iconv の代わりになる物は transcode であって Encoding は別の話です。

というわけで、encoding メソッドは以前のままにして、Encoding オブジェクトを
返すメソッドを新設した方がよいのではないかと思います。

encodingよりもEncodingオブジェクトを返すのに適切な名前を思い
つけないので、そういうAPIにはしない方がよいと思っています。

Encoding オブジェクトバージョンの名前をどうするか、というのは、
それはそれで難しいのですが、上述の理由からそうせざるをえないと思います。
私案では string の encoding なので str_encoding かなぁ。

--
NARUSE, Yui [e-mail]

=end

[kou (Kouhei Sutou)]

=begin
須藤です。

In [e-mail]
"[ruby-dev:42515] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Tue, 2 Nov 2010 22:34:53 +0900,
"NARUSE, Yui" [e-mail] wrote:

この変更では、Ruby M17N の encoding system を使うようにしていますが、
導入した非互換変更には反対です。

その意見はわからなくもわからなくもないです。
私も迷いました。

ただ、反対の理由として以下は弱いと感じます。
非推奨とかいつなくなるとかが確定しているくらい必要だと感じます。

わざわざ非互換を入れるようなライブラリではないという趣旨です。

確定していない現段階ではそのような対象ではないということを主
張しています。

必然性のある物ならばしょうがないですが、これは違うと思います。

Ruby 1.9ではEncodingまわりの機能と統合されるのは必然の流れだ
と考えています。

総論として、REXML は Ruby 的に非推奨という扱いになりつつあるというのは
合意がとれていると思われるところ、この状況下で非互換変更をするのは
避けるべきだと思います。

個人的には標準添付されているXMLパーサはRubyのみで書かれたも
のの方がいいと思っています。Nokogiriとかはgemでいいと思って
います。

Nokogiri を添付すべきだとは言っていません。

合意がとれているわけではないこと（少なくとも反対意見があると
いうこと）主張しています。

意図していることを理解できている自信がないのですが、エンコー
ディングを表すのにEncodingオブジェクトを使うのはよくない、と
いうことですか？

はい。
それぞれのエンコーディングの実際上の射程範囲は文脈によって代わります。
そして、HTTP や HTML、XML などのエンコーディングと、Ruby M17N の
エンコーディングは一部射程範囲が異なります。

今はXMLだけ考えています。
具体的にはどこが異なるのでしょうか。

私の認識は以下の通りです。

• XMLのエンコーディングはIANAに登録されているchaset名をベース
  にしている。x-はじまりのものなども使えまるが、REXMLでは
  サポート対象外。

• RubyのEncodingもIANAをベースにしている。

なので、REXMLで使う範囲では十分カバーしていると認識していま
す。

直近では UTF-16BE/UTF-16LE は BOM なしを意味するので、
BOM 付きの UTF-16 が欲しいときに困ります。
（なお、UTF-16 は ASCII incompatible なので色々バグってる気がする）

もともとREXMLは出力時にBOMをつけないのですが、BOM付きの
UTF-16が必要になるのはどういう場面を想定していますか？

BOM をつけないのは UTF-8 の話ではありませんか。
たとえば、1.9.2 までは以下で BOM 付き big endian な UTF-16 で出力しますね。

require 'rexml/document'
doc = REXML::Document.new
doc << REXML::XMLDecl.new('1.0', 'UTF-16')
doc.write(s="")
=> "\xFE\xFF\x00<\x00?\x00x\x00m\x00l\xFE\xFF\x00 \x00v\x00e\x00r\x00s\x00i\x00o\x00n\x00=\x00'\x00"

たしかにそうですね。（big endianではなくlittle endianですが。）
失礼しました。

ただ、これはiconvを利用している場合でiconvがない場合はBOMな
しになっていたはずです。

今のままでもBOMをつけるくらい簡単なので、必要であればつけて

しまってもいいとは思っています。

これの結果は、現在以下の通りになってしまっています。
=> ""

このように表示されるのは適切にencodingが設定するようになった
からだと思っています。trunkだとちゃんとUTF-16BEが設定されてい
て（なので\xXXにならないで表示される）、以前は（UTF-16なの
に）UTF-8が設定されていたと思います。

これによって、少なくとも XMLDecl#encoding の戻り値の意味は、
XML 宣言の encoding 属性で用いられる値であって、内容の Ruby の文脈における
encoding とは異なる物であるといえるのではないでしょうか。

すみません、「内容の Ruby の文脈における encoding」が何を指し
ているのかが分かりませんでした。テキストのencodingとか、そう
いう意味ですか？そうだとして、異なる場合はどうした方がよいと
いうことでしょうか。

ちなみに、「XMLDecl#encoding の戻り値の意味は、」XMLとして文
字列化したときに使われるencodingでもあります。まとめると、今
はこうなっていると思っています。

• REXMLのオブジェクトを作るときのencodingはXML宣言で指定
• REXMLのオブジェクトを操作するときの入出力はUTF-8
• REXMLのオブジェクトをXMLとして出力する時はXMLDecl#encoding

そもそも、UTF-16 の場合 UTF-8 に変換して扱うし。

UTF-16以外の場合でもREXML内部では常にUTF-8で扱っています。

ここも意図を理解している自信がないのですが、RubyのEncodingは
まだIconvの代わりには使えないということですか？

まず、文字列のエンコーディングを扱う部分と、変換を司る transcode を
分けて考える必要があります。
で、iconv の代わりになる物は transcode であって Encoding は別の話です。

えーと、もともとiconvの代わりにEncodingをという話から始まって
いたのでEncodingを使っていたのですが、使い分けた方がよいので
しょうか？

使い分けたとして、transcodeがiconvの代替として使うにはまだ早
いということであれば今回の変更は時期尚早だった気がします。

というわけで、encoding メソッドは以前のままにして、Encoding オブジェクトを
返すメソッドを新設した方がよいのではないかと思います。

encodingよりもEncodingオブジェクトを返すのに適切な名前を思い
つけないので、そういうAPIにはしない方がよいと思っています。

Encoding オブジェクトバージョンの名前をどうするか、というのは、
それはそれで難しいのですが、上述の理由からそうせざるをえないと思います。
私案では string の encoding なので str_encoding かなぁ。

うーん、上述の理由を受け入れられないのは別としても、その名前
は受け入れられないです。適切でない場所にはみ出してしまった感
じがします。

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

まず、用語を整理すると、
iconv:
ext/iconv のこと、文字コード変換器
glibc iconv とか GNU libiconv とか Citrus iconv とかを呼ぶ

transcode:
transcode.c と enc/trans/* あたりで実装され、
String#encode とかで使われる物

Encoding:
encoding.c や enc/* で実装され、Encoding クラスとして現れたり、
String や正規表現の裏で文字を操る。

(2010/11/02 23:38), Kouhei Sutou wrote:

えーと、もともとiconvの代わりにEncodingをという話から始まって
いたのでEncodingを使っていたのですが、使い分けた方がよいので
しょうか？

というわけで、ここは「iconv の代わりに transcode を」です。

使い分けたとして、transcodeがiconvの代替として使うにはまだ早
いということであれば今回の変更は時期尚早だった気がします。

これは問題ないと思います。

それぞれのエンコーディングの実際上の射程範囲は文脈によって代わります。
そして、HTTP や HTML、XML などのエンコーディングと、Ruby M17N の
エンコーディングは一部射程範囲が異なります。

今はXMLだけ考えています。

後述の通り、事情は同じです。

具体的にはどこが異なるのでしょうか。

私の認識は以下の通りです。

• XMLのエンコーディングはIANAに登録されているchaset名をベース
  にしている。x-はじまりのものなども使えまるが、REXMLでは
  サポート対象外。

建前はそうです。
しかし、現実問題としては ISO-8859-1 と称しつつ中身は Windows-1252 だったりします。
(例えば未使用であるはずの 0x80 がなぜか使われていて、それがユーロ記号を期待している)
日本で言えば円記号問題や波ダッシュ問題がそうですな。

歴史的経緯を説明すると、当初の IANA Charsets は情報交換用符号の名前登録簿だったので、
その内容について詳細な合意は取られていませんでした。
charset という名前自体が、符号化文字集合と文字符号化方式が分化する前のもの
であることを物語っているとも言えます。
ISO-8859-1 と Windows-1252 の違いや、EUC-JP が含む補助漢字を CP51932 が含まない
こともこの辺の一環でしょう。

で、現実はと言えば、インターネット上においてほとんどのデータは Windows ベースの
ものとなっています。また、Windows のデファクト化につられてインターネット関連の
ソフトウェアは Windows の定義にあわせるようになりつつあります。

また、Unicode 登場時に既存の文字コードとの変換表を統一することに失敗した事も
乖離を増大させています。日本においては波ダッシュ問題がそれです。
こちらも、変換表を Windows にあわせることになりつつあります。

以上をまとめると、「IANA Charsets における名前とその正式な定義」と、
Windows 由来のデファクトは乖離している、と言うことになります。

具体的にどの charset が乖離し、その実態は何なのかは HTML5 の人々がまとめています。
http://www.w3.org/TR/html5/parsing.html#character-encodings-0

で、REXML の扱う XML データがインターネット上のデータ同様に正式な定義から乖離しているか、
が一つの論点ですが、REXML の主たる用途が RSS で、RSS のデータ元が blog 等の Web 媒体で、
それらが元々は Web ブラウザ経由で入力されているであろう事を考えると、
上述の状況と同じなんじゃないですかね。

• RubyのEncodingもIANAをベースにしている。

「ベースにしている」は正しいんですが、Ruby では IANA のある名称の実装には、
正式な定義を一致させ、デファクトに対しては Windows 由来の名前を与えています。
例えば、ISO-8859-1 と Windows-1252、Shift_JIS と Windows-31J、
EUC-JP と CP51932 などです。

なので、一連の名称群の空間は一致していますが、意味づけにずれがあります。

そもそも論を申しますと、この違いは情報交換用符号と内部処理用符号の違いだったりします。

なので、REXMLで使う範囲では十分カバーしていると認識しています。

というわけで、概ね範囲としてはカバーされているのですが、意味論が違うわけです。
カバーしきれてない例を挙げると、例えば UTF-16 とかですか。

もっとも、ここで述べた違いを REXML でまともに扱うかはまた別の話です。

ただ、これはiconvを利用している場合でiconvがない場合はBOMな
しになっていたはずです。

今のままでもBOMをつけるくらい簡単なので、必要であればつけて

しまってもいいとは思っています。

BOM をつける場合は encoding は UTF-16 でなければいけません。
一方で、UTF-16BE を名乗るならばそれに BOM をつけてはいけません。

これの結果は、現在以下の通りになってしまっています。
=> ""

このように表示されるのは適切にencodingが設定するようになった
からだと思っています。trunkだとちゃんとUTF-16BEが設定されてい
て（なので\xXXにならないで表示される）、以前は（UTF-16なの
に）UTF-8が設定されていたと思います。

表示結果に関しては確かにご指摘の通りです。
これで、encoding='UTF-16BE' ならばこの結果単体は問題ありませんね。

これによって、少なくとも XMLDecl#encoding の戻り値の意味は、
XML 宣言の encoding 属性で用いられる値であって、内容の Ruby の文脈における
encoding とは異なる物であるといえるのではないでしょうか。

すみません、「内容の Ruby の文脈における encoding」が何を指し
ているのかが分かりませんでした。テキストのencodingとか、そう
いう意味ですか？

具体例ですと例えば、
'<xml version="1.0" encoding="Shift_JIS"?>'.encode("Windows-31")
とか。ここでの「内容の Ruby の文脈における encoding」は Windows-31J です。

そうだとして、異なる場合はどうした方がよいと
いうことでしょうか。

XMLDec#encoding は文字列にして、XML 宣言に入っているものを
そのまま使うべきです。

ちなみに、「XMLDecl#encoding の戻り値の意味は、」XMLとして文
字列化したときに使われるencodingでもあります。まとめると、今
はこうなっていると思っています。

• REXMLのオブジェクトを作るときのencodingはXML宣言で指定
• REXMLのオブジェクトを操作するときの入出力はUTF-8
• REXMLのオブジェクトをXMLとして出力する時はXMLDecl#encoding

「XMLとして文字列化したときに使われるencoding」が上述の、
「内容の Ruby の文脈における encoding」です。
で、これは XMLDecl#encoding とは分離する必要があります（長期的には）。
そこまでやらない場合は XMLDecl#encoding 側に
「XMLとして文字列化したときに使われるencoding」をあわせるべきです。

これは言い換えると、

• 情報交換用符号側に内部処理用符号をあわせるべき
• XML の公称しているエンコーディング名にあわせるべき
• Ruby の Encoding オブジェクトでなく、エンコーディング名を文字列のまま使うべき
  などとなります。

そもそも、UTF-16 の場合 UTF-8 に変換して扱うし。

UTF-16以外の場合でもREXML内部では常にUTF-8で扱っています。

仰るとおりです。

というわけで、encoding メソッドは以前のままにして、Encoding オブジェクトを
返すメソッドを新設した方がよいのではないかと思います。

encodingよりもEncodingオブジェクトを返すのに適切な名前を思い
つけないので、そういうAPIにはしない方がよいと思っています。

Encoding オブジェクトバージョンの名前をどうするか、というのは、
それはそれで難しいのですが、上述の理由からそうせざるをえないと思います。
私案では string の encoding なので str_encoding かなぁ。

うーん、上述の理由を受け入れられないのは別としても、その名前
は受け入れられないです。適切でない場所にはみ出してしまった感
じがします。

Encoding オブジェクトバージョンが必要なのは、上述の
REXML オブジェクトからXMLソース文字列に変換する際に用いるエンコーディングを、
XML 宣言の encoding 属性の値とは別に持ち続けたい場合の話なので、
冒頭に述べた IANA Charsets の定義と Ruby の各エンコーディングの定義の違いを
置いておくのであれば不要ですね。
また、XML ソースに変換する際に別に与えるという方法もあります。

--
NARUSE, Yui [e-mail]

=end

[kou (Kouhei Sutou)]

=begin
須藤です。

現時点でどうなっているのかを確認させてください。それによって
進める順番が変わってくると思っています。

以下のように認識していますがあっていますか？

1. 成瀬さんは「XMLDecl#enocdingなどは文字列にすべき」と主
   張している。

2. 1.の理由はXML宣言用のencodingとtranscode用のencodingは
   異なるから。（XML宣言はShift_JISでtranscode用はCP932と
   か）

3. 当初の1.の理由は2.ではなくREXMLのAPIの互換性を失わせる
   べきではない、だったが、今はその理由はなくなり、2.だけ
   になっている。

In [e-mail]
"[ruby-dev:42517] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Wed, 3 Nov 2010 02:41:35 +0900,
"NARUSE, Yui" [e-mail] wrote:

成瀬です。

まず、用語を整理すると、
iconv:
ext/iconv のこと、文字コード変換器
glibc iconv とか GNU libiconv とか Citrus iconv とかを呼ぶ

transcode:
transcode.c と enc/trans/* あたりで実装され、
String#encode とかで使われる物

Encoding:
encoding.c や enc/* で実装され、Encoding クラスとして現れたり、
String や正規表現の裏で文字を操る。

(2010/11/02 23:38), Kouhei Sutou wrote:

えーと、もともとiconvの代わりにEncodingをという話から始まって
いたのでEncodingを使っていたのですが、使い分けた方がよいので
しょうか？

というわけで、ここは「iconv の代わりに transcode を」です。

使い分けたとして、transcodeがiconvの代替として使うにはまだ早
いということであれば今回の変更は時期尚早だった気がします。

これは問題ないと思います。

それぞれのエンコーディングの実際上の射程範囲は文脈によって代わります。
そして、HTTP や HTML、XML などのエンコーディングと、Ruby M17N の
エンコーディングは一部射程範囲が異なります。

今はXMLだけ考えています。

後述の通り、事情は同じです。

具体的にはどこが異なるのでしょうか。

私の認識は以下の通りです。

• XMLのエンコーディングはIANAに登録されているchaset名をベース
  にしている。x-はじまりのものなども使えまるが、REXMLでは
  サポート対象外。

建前はそうです。
しかし、現実問題としては ISO-8859-1 と称しつつ中身は Windows-1252 だったりします。
(例えば未使用であるはずの 0x80 がなぜか使われていて、それがユーロ記号を期待している)
日本で言えば円記号問題や波ダッシュ問題がそうですな。

歴史的経緯を説明すると、当初の IANA Charsets は情報交換用符号の名前登録簿だったので、
その内容について詳細な合意は取られていませんでした。
charset という名前自体が、符号化文字集合と文字符号化方式が分化する前のもの
であることを物語っているとも言えます。
ISO-8859-1 と Windows-1252 の違いや、EUC-JP が含む補助漢字を CP51932 が含まない
こともこの辺の一環でしょう。

で、現実はと言えば、インターネット上においてほとんどのデータは Windows ベースの
ものとなっています。また、Windows のデファクト化につられてインターネット関連の
ソフトウェアは Windows の定義にあわせるようになりつつあります。

また、Unicode 登場時に既存の文字コードとの変換表を統一することに失敗した事も
乖離を増大させています。日本においては波ダッシュ問題がそれです。
こちらも、変換表を Windows にあわせることになりつつあります。

以上をまとめると、「IANA Charsets における名前とその正式な定義」と、
Windows 由来のデファクトは乖離している、と言うことになります。

具体的にどの charset が乖離し、その実態は何なのかは HTML5 の人々がまとめています。
http://www.w3.org/TR/html5/parsing.html#character-encodings-0

で、REXML の扱う XML データがインターネット上のデータ同様に正式な定義から乖離しているか、
が一つの論点ですが、REXML の主たる用途が RSS で、RSS のデータ元が blog 等の Web 媒体で、
それらが元々は Web ブラウザ経由で入力されているであろう事を考えると、
上述の状況と同じなんじゃないですかね。

• RubyのEncodingもIANAをベースにしている。

「ベースにしている」は正しいんですが、Ruby では IANA のある名称の実装には、
正式な定義を一致させ、デファクトに対しては Windows 由来の名前を与えています。
例えば、ISO-8859-1 と Windows-1252、Shift_JIS と Windows-31J、
EUC-JP と CP51932 などです。

なので、一連の名称群の空間は一致していますが、意味づけにずれがあります。

そもそも論を申しますと、この違いは情報交換用符号と内部処理用符号の違いだったりします。

なので、REXMLで使う範囲では十分カバーしていると認識しています。

というわけで、概ね範囲としてはカバーされているのですが、意味論が違うわけです。
カバーしきれてない例を挙げると、例えば UTF-16 とかですか。

もっとも、ここで述べた違いを REXML でまともに扱うかはまた別の話です。

ただ、これはiconvを利用している場合でiconvがない場合はBOMな
しになっていたはずです。

今のままでもBOMをつけるくらい簡単なので、必要であればつけて

しまってもいいとは思っています。

BOM をつける場合は encoding は UTF-16 でなければいけません。
一方で、UTF-16BE を名乗るならばそれに BOM をつけてはいけません。

これの結果は、現在以下の通りになってしまっています。
=> ""

このように表示されるのは適切にencodingが設定するようになった
からだと思っています。trunkだとちゃんとUTF-16BEが設定されてい
て（なので\xXXにならないで表示される）、以前は（UTF-16なの
に）UTF-8が設定されていたと思います。

表示結果に関しては確かにご指摘の通りです。
これで、encoding='UTF-16BE' ならばこの結果単体は問題ありませんね。

これによって、少なくとも XMLDecl#encoding の戻り値の意味は、
XML 宣言の encoding 属性で用いられる値であって、内容の Ruby の文脈における
encoding とは異なる物であるといえるのではないでしょうか。

すみません、「内容の Ruby の文脈における encoding」が何を指し
ているのかが分かりませんでした。テキストのencodingとか、そう
いう意味ですか？

具体例ですと例えば、
'<xml version="1.0" encoding="Shift_JIS"?>'.encode("Windows-31")
とか。ここでの「内容の Ruby の文脈における encoding」は Windows-31J です。

そうだとして、異なる場合はどうした方がよいと
いうことでしょうか。

XMLDec#encoding は文字列にして、XML 宣言に入っているものを
そのまま使うべきです。

ちなみに、「XMLDecl#encoding の戻り値の意味は、」XMLとして文
字列化したときに使われるencodingでもあります。まとめると、今
はこうなっていると思っています。

• REXMLのオブジェクトを作るときのencodingはXML宣言で指定
• REXMLのオブジェクトを操作するときの入出力はUTF-8
• REXMLのオブジェクトをXMLとして出力する時はXMLDecl#encoding

「XMLとして文字列化したときに使われるencoding」が上述の、
「内容の Ruby の文脈における encoding」です。
で、これは XMLDecl#encoding とは分離する必要があります（長期的には）。
そこまでやらない場合は XMLDecl#encoding 側に
「XMLとして文字列化したときに使われるencoding」をあわせるべきです。

これは言い換えると、

• 情報交換用符号側に内部処理用符号をあわせるべき
• XML の公称しているエンコーディング名にあわせるべき
• Ruby の Encoding オブジェクトでなく、エンコーディング名を文字列のまま使うべき
  などとなります。

そもそも、UTF-16 の場合 UTF-8 に変換して扱うし。

UTF-16以外の場合でもREXML内部では常にUTF-8で扱っています。

仰るとおりです。

というわけで、encoding メソッドは以前のままにして、Encoding オブジェクトを
返すメソッドを新設した方がよいのではないかと思います。

encodingよりもEncodingオブジェクトを返すのに適切な名前を思い
つけないので、そういうAPIにはしない方がよいと思っています。

Encoding オブジェクトバージョンの名前をどうするか、というのは、
それはそれで難しいのですが、上述の理由からそうせざるをえないと思います。
私案では string の encoding なので str_encoding かなぁ。

うーん、上述の理由を受け入れられないのは別としても、その名前
は受け入れられないです。適切でない場所にはみ出してしまった感
じがします。

Encoding オブジェクトバージョンが必要なのは、上述の
REXML オブジェクトからXMLソース文字列に変換する際に用いるエンコーディングを、
XML 宣言の encoding 属性の値とは別に持ち続けたい場合の話なので、
冒頭に述べた IANA Charsets の定義と Ruby の各エンコーディングの定義の違いを
置いておくのであれば不要ですね。
また、XML ソースに変換する際に別に与えるという方法もあります。

--
NARUSE, Yui [e-mail]

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

(2010/11/03 8:24), Kouhei Sutou wrote:

現時点でどうなっているのかを確認させてください。それによって
進める順番が変わってくると思っています。

以下のように認識していますがあっていますか？

1. 成瀬さんは「XMLDecl#enocdingなどは文字列にすべき」と主
   張している。

はい。

2. 1.の理由はXML宣言用のencodingとtranscode用のencodingは
   異なるから。（XML宣言はShift_JISでtranscode用はCP932と
   か）

はい。

3. 当初の1.の理由は2.ではなくREXMLのAPIの互換性を失わせる
   べきではない、だったが、今はその理由はなくなり、2.だけ
   になっている。

ここは他の人にもわかりにくいと指摘されたのですが
当初から 2. と API 互換性の両方が理由です。

なぜ互換性を挙げたかというと、XMLDecl#encoding を、
XML 宣言用と transcode 用のどちらの意味にするかを考える際、
互換性的には XML 宣言用だと理解するべきだからです。

transcode 用では指定自体を CP932 とかに変えないといけない

というか iconv の時でも Shift_JIS を使うと波ダッシュとかではまる

わたしの視点も説明した方がよい気がするのですると、

a. 以前から REXML の変換周りは前述の理由から地雷があった
b. 今回 iconv から transcode へ変換エンジンが変わった
c. 併せて XMLDecl#encoding 等の戻り値が変わった→非互換

で、b. には賛成です
a. は問題だとは思っていますが、かといって綺麗な解決策があるわけでも
ないので、強い意見は持っていません。
（変換で使うエンコーディングを渡せるといいかなぁ、くらい）
c. は非互換という明快な欠点がある一方、今回その欠点を打ち消すほどのメリットが
あるとは思っていません。
String#encode のエンコーディング指定のための引数には String も渡せますし、
渡す直前に Shift-JIS (ハイフンのやつ) のようなものでも、
string.encode(REXML.find_encoding("Shift-JIS")) などとかませるとか、
方法は あるだろうので。

--
NARUSE, Yui [e-mail]

=end

[kou (Kouhei Sutou)]

=begin
須藤です。

In [e-mail]
"[ruby-dev:42519] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Wed, 3 Nov 2010 17:49:16 +0900,
"NARUSE, Yui" [e-mail] wrote:

現時点でどうなっているのかを確認させてください。それによって
進める順番が変わってくると思っています。

以下のように認識していますがあっていますか？

1. 成瀬さんは「XMLDecl#enocdingなどは文字列にすべき」と主
   張している。

はい。

2. 1.の理由はXML宣言用のencodingとtranscode用のencodingは
   異なるから。（XML宣言はShift_JISでtranscode用はCP932と
   か）

はい。

3. 当初の1.の理由は2.ではなくREXMLのAPIの互換性を失わせる
   べきではない、だったが、今はその理由はなくなり、2.だけ
   になっている。

ここは他の人にもわかりにくいと指摘されたのですが
当初から 2. と API 互換性の両方が理由です。

なんと、そうだったのですか。

なぜ互換性を挙げたかというと、XMLDecl#encoding を、
XML 宣言用と transcode 用のどちらの意味にするかを考える際、
互換性的には XML 宣言用だと理解するべきだからです。

transcode 用では指定自体を CP932 とかに変えないといけない

というか iconv の時でも Shift_JIS を使うと波ダッシュとかではまる

では、2.を解決する方法（XML宣言用とtranscode用のencodingを別
に管理する方法）をいくつか考えて、その中で一番よさそうなもの
についてそれが妥当かをあらためて考える、という流れでいいです
か？

あと、一応確認したいのですが、私がメンテナンスすることになっ
たので、REXMLの変更については私の判断が最優先でいいんですよ
ね？私の判断がよくなさそうな場合は、私が納得できるように説明
してもらって、それで私が納得したら変更する、ということでいい
んですよね？

わたしの視点も説明した方がよい気がするのですると、

ありがとうございます。

=end

[naruse (Yui NARUSE)]

=begin
(2010/11/06 12:10), Kouhei Sutou wrote:

3. 当初の1.の理由は2.ではなくREXMLのAPIの互換性を失わせる
   べきではない、だったが、今はその理由はなくなり、2.だけ
   になっている。

ここは他の人にもわかりにくいと指摘されたのですが
当初から 2. と API 互換性の両方が理由です。

なんと、そうだったのですか。

一応一番最初の投稿から指摘はしていますよね。
見直すと確かにわかりづらいとは思うので、反省するところではあります。

なぜ互換性を挙げたかというと、XMLDecl#encoding を、
XML 宣言用と transcode 用のどちらの意味にするかを考える際、
互換性的には XML 宣言用だと理解するべきだからです。

transcode 用では指定自体を CP932 とかに変えないといけない

というか iconv の時でも Shift_JIS を使うと波ダッシュとかではまる

では、2.を解決する方法（XML宣言用とtranscode用のencodingを別
に管理する方法）をいくつか考えて、その中で一番よさそうなもの
についてそれが妥当かをあらためて考える、という流れでいいです
か？

わかりました、後ほどとパッチを投げます。

あと、一応確認したいのですが、私がメンテナンスすることになっ
たので、REXMLの変更については私の判断が最優先でいいんですよ
ね？私の判断がよくなさそうな場合は、私が納得できるように説明
してもらって、それで私が納得したら変更する、ということでいい
んですよね？

はい、説得できなかったらわたしの説明が悪い、と。

--
NARUSE, Yui [e-mail]

=end

[kou (Kouhei Sutou)]

=begin
須藤です。

In [e-mail]
"[ruby-dev:42548] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Sun, 7 Nov 2010 19:14:39 +0900,
"NARUSE, Yui" [e-mail] wrote:

なぜ互換性を挙げたかというと、XMLDecl#encoding を、
XML 宣言用と transcode 用のどちらの意味にするかを考える際、
互換性的には XML 宣言用だと理解するべきだからです。

transcode 用では指定自体を CP932 とかに変えないといけない

というか iconv の時でも Shift_JIS を使うと波ダッシュとかではまる

では、2.を解決する方法（XML宣言用とtranscode用のencodingを別
に管理する方法）をいくつか考えて、その中で一番よさそうなもの
についてそれが妥当かをあらためて考える、という流れでいいです
か？

わかりました、後ほどとパッチを投げます。

ありがとうございます。
私も思うところはあるので案を出すつもりです。
ただ、少なくとも年末までわりとやることがあるので、そんなに反
応はよくないと思います。すみません。

あと、一応確認したいのですが、私がメンテナンスすることになっ
たので、REXMLの変更については私の判断が最優先でいいんですよ
ね？私の判断がよくなさそうな場合は、私が納得できるように説明
してもらって、それで私が納得したら変更する、ということでいい
んですよね？

はい、説得できなかったらわたしの説明が悪い、と。

できるだけ、ここがこうわからない、とかは伝えるつもりなのでよ
ろしくお願いします。

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

(2010/11/07 20:10), Kouhei Sutou wrote:

[e-mail]
"[ruby-dev:42548] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Sun, 7 Nov 2010 19:14:39 +0900,
"NARUSE, Yui"[e-mail] wrote:

なぜ互換性を挙げたかというと、XMLDecl#encoding を、
XML 宣言用と transcode 用のどちらの意味にするかを考える際、
互換性的には XML 宣言用だと理解するべきだからです。

transcode 用では指定自体を CP932 とかに変えないといけない

というか iconv の時でも Shift_JIS を使うと波ダッシュとかではまる

では、2.を解決する方法（XML宣言用とtranscode用のencodingを別
に管理する方法）をいくつか考えて、その中で一番よさそうなもの
についてそれが妥当かをあらためて考える、という流れでいいです
か？

わかりました、後ほどとパッチを投げます。

ありがとうございます。
私も思うところはあるので案を出すつもりです。
ただ、少なくとも年末までわりとやることがあるので、そんなに反
応はよくないと思います。すみません。

パッチを作ってみました。
https://github.com/nurse/ruby/compare/trunk...rexml

83a66d67 が encoding を String に戻すもののうち、主要なもの。
8d20327b が 83a66d67 に含まれるべき変更のうち、主要でないものを、
わかりやすさのため今回別にしています
2de823bd が warning 消し
14187b46 が transcode 用の文字コード指定を追加するコードです。

これによって例えば以下のような違いが出ます。

% cat test.rb
require 'rexml/document'
src = <<end

\u3042\uFF5E
end
x = REXML::Document.new(src)

o = REXML::Output.new(s="", "EUC-JP", "CP51932")
x.write(o)
p s

o = REXML::Output.new(s="", "EUC-JP")
x.write(o)
% ./ruby test.rb
"\n\x{A4A2}\x{A1C1}\n"
/home/naruse/local/ruby/lib/ruby/1.9.1/rexml/encoding.rb:34:in encode': U+FF5E from UTF-8 to EUC-JP (Encoding::UndefinedConversionError) from /home/naruse/local/ruby/lib/ruby/1.9.1/rexml/encoding.rb:34:in encode'
from /home/naruse/local/ruby/lib/ruby/1.9.1/rexml/output.rb:22:in <<' from /home/naruse/local/ruby/lib/ruby/1.9.1/rexml/formatters/default.rb:87:in write_text'
from /home/naruse/local/ruby/lib/ruby/1.9.1/rexml/formatters/default.rb:50:in write' from /home/naruse/local/ruby/lib/ruby/1.9.1/rexml/formatters/default.rb:79:in block in write_element'
from /home/naruse/local/ruby/lib/ruby/1.9.1/rexml/formatters/default.rb:78:in each' from /home/naruse/local/ruby/lib/ruby/1.9.1/rexml/formatters/default.rb:78:in write_element'
from /home/naruse/local/ruby/lib/ruby/1.9.1/rexml/formatters/default.rb:31:in write' from /home/naruse/local/ruby/lib/ruby/1.9.1/rexml/formatters/default.rb:60:in block in write_document'
from /home/naruse/local/ruby/lib/ruby/1.9.1/rexml/formatters/default.rb:60:in each' from /home/naruse/local/ruby/lib/ruby/1.9.1/rexml/formatters/default.rb:60:in write_document'
from /home/naruse/local/ruby/lib/ruby/1.9.1/rexml/formatters/default.rb:28:in write' from /home/naruse/local/ruby/lib/ruby/1.9.1/rexml/document.rb:199:in write'
from test.rb:13:in `'

REXML::Document#write でも transcode encoding を指定できた方がいいかなぁ
とも思っているのですが、とりあえず方向としてはこんな感じです。

--
NARUSE, Yui [e-mail]

=end

[kou (Kouhei Sutou)]

=begin
須藤です。

In [e-mail]
"[ruby-dev:42572] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Sat, 13 Nov 2010 18:23:36 +0900,
"NARUSE, Yui" [e-mail] wrote:

パッチを作ってみました。
https://github.com/nurse/ruby/compare/trunk...rexml

ありがとうございます。
REXML::EncodingクラスとかREXML::XMLEncodingクラスとかを作ろ
うかと思っていたのですが、文字列でもいいような気もしてきまし
た。（XML宣言のエンコーディングを比較しているところが分散し
ていていろんなところでupcaseがでてくるのが嫌だった。）
実際にコードを書き出したらまた考えが変わるかもしれません
が。。。

83a66d67 が encoding を String に戻すもののうち、主要なもの。
8d20327b が 83a66d67 に含まれるべき変更のうち、主要でないものを、
わかりやすさのため今回別にしています
2de823bd が warning 消し
14187b46 が transcode 用の文字コード指定を追加するコードです。

えーっと、warning消しとかは混ぜないで欲しかったです。
あと、warningを消そうとするのはよいと思うのですが、消すこと
が目的な変更はよくないと思っています。ダメなところに気づきに
くくなるので。
直すならちゃんとしたコードに直した方がよいと思っています。
例えば、こういうのにはちゃんとassertをつけた方がよいと思って
います。

def test_oses_with_bad_EOLs

• d = Document.new("\n\n\n\n\n\n\n\n")

• Document.new("\n\n\n\n\n\n\n\n")
  end

ということで、エッセンスだけ参考にして書き直しておきますね。

あ、そういえば、decodeのところで必ずBOMをチェックするように
していますが、これは必要なんでしょうか？BOMはファイルの先頭
でだけチェックすればいいのだと思っていました。

これによって例えば以下のような違いが出ます。

これは何による違いですか？

14187b46 が transcode 用の文字コード指定を追加するコードです。

の話でしょうか？

% cat test.rb
require 'rexml/document'
src = <<end

\u3042\uFF5E
end
x = REXML::Document.new(src)

o = REXML::Output.new(s="", "EUC-JP", "CP51932")
x.write(o)
p s

o = REXML::Output.new(s="", "EUC-JP")
x.write(o)
% ./ruby test.rb
"\n\x{A4A2}\x{A1C1}\n"
/home/naruse/local/ruby/lib/ruby/1.9.1/rexml/encoding.rb:34:in `encode': U+FF5E from UTF-8 to EUC-JP (Encoding::UndefinedConversionError)
...

REXML::Document#write でも transcode encoding を指定できた方がいいかなぁ
とも思っているのですが、とりあえず方向としてはこんな感じです。

この機能は私はいらないと思っています。
出力時に指定するのではなく、XML宣言を書き換えて変更するAPIの
方がよいと思っています。（なので今のままでよい。）

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

(2010/11/18 22:46), Kouhei Sutou wrote:

[e-mail]
"[ruby-dev:42572] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Sat, 13 Nov 2010 18:23:36 +0900,
"NARUSE, Yui"[e-mail] wrote:

パッチを作ってみました。
https://github.com/nurse/ruby/compare/trunk...rexml

ありがとうございます。
REXML::EncodingクラスとかREXML::XMLEncodingクラスとかを作ろ
うかと思っていたのですが、文字列でもいいような気もしてきまし
た。（XML宣言のエンコーディングを比較しているところが分散し
ていていろんなところでupcaseがでてくるのが嫌だった。）
実際にコードを書き出したらまた考えが変わるかもしれません
が。。。

比較対象は全て UTF-8 なので、REXML::Encoding モジュールに
decode 済み or UTF-8 か否か、を示すインスタンス変数を追加というのは考えました。

83a66d67 が encoding を String に戻すもののうち、主要なもの。
8d20327b が 83a66d67 に含まれるべき変更のうち、主要でないものを、
わかりやすさのため今回別にしています
2de823bd が warning 消し
14187b46 が transcode 用の文字コード指定を追加するコードです。

えーっと、warning消しとかは混ぜないで欲しかったです。

git では別のコミットにしてあるので、「Showing 4 commits by 1 author.」
の下に出ている4つのコミットのリンクを選択すれば、例えば
https://github.com/nurse/ruby/commit/83a66d679a788022bdcc7ecf0f7414437d8d175c
などと個別の差分を見れますよ。
また、warningだけ別にした plain な diff も出せますが−、いらないかな

あと、warningを消そうとするのはよいと思うのですが、消すこと
が目的な変更はよくないと思っています。ダメなところに気づきに
くくなるので。
直すならちゃんとしたコードに直した方がよいと思っています。
例えば、こういうのにはちゃんとassertをつけた方がよいと思って
います。

def test_oses_with_bad_EOLs

• d = Document.new("\n\n\n\n\n\n\n\n")

• Document.new("\n\n\n\n\n\n\n\n")
  end

ということで、エッセンスだけ参考にして書き直しておきますね。

確かに。
ここはよろしくです。

あ、そういえば、decodeのところで必ずBOMをチェックするように
していますが、これは必要なんでしょうか？BOMはファイルの先頭
でだけチェックすればいいのだと思っていました。

む、確かにご指摘の通り誤っていますね。

これによって例えば以下のような違いが出ます。

これは何による違いですか？

14187b46 が transcode 用の文字コード指定を追加するコードです。

の話でしょうか？

おっと、また説明が不足していますね、そうです。

REXML::Document#write でも transcode encoding を指定できた方がいいかなぁ
とも思っているのですが、とりあえず方向としてはこんな感じです。

この機能は私はいらないと思っています。
出力時に指定するのではなく、XML宣言を書き換えて変更するAPIの
方がよいと思っています。（なので今のままでよい。）

XML 宣言で用いるエンコーディングと、変換で用いるエンコーディングを別に
したいケースがあるのですよ。
代表例が Windows-31J と Shift_JIS、CP51932 と EUC-JP です。

--
NARUSE, Yui [e-mail]

=end

[kou (Kouhei Sutou)]

=begin
須藤です。

In [e-mail]
"[ruby-dev:42593] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Thu, 18 Nov 2010 23:43:14 +0900,
"NARUSE, Yui" [e-mail] wrote:

比較対象は全て UTF-8 なので、REXML::Encoding モジュールに
decode 済み or UTF-8 か否か、を示すインスタンス変数を追加というのは考えました。

内部ではそれでもよいと思いますが、利用者がXML宣言のエンコー
ディングを使いたいときに不便だと思っています。例えば、日本語っ
ぽいものだけ扱い時にエンコーディングがShift_JISかEUC-JPか
UTF-8以外のものは使わないとか、というケースを考えていました。
このとき、利用者がいちいちREXMLから返されるエンコーディング
を正規化して比較しなければいけないのは面倒だと考えています。

えーっと、warning消しとかは混ぜないで欲しかったです。

git では別のコミットにしてあるので、「Showing 4 commits by 1 author.」
の下に出ている4つのコミットのリンクを選択すれば、例えば
https://github.com/nurse/ruby/commit/83a66d679a788022bdcc7ecf0f7414437d8d175c
などと個別の差分を見れますよ。
また、warningだけ別にした plain な diff も出せますが−、いらないかな

あ、そういうことではなく、エンコーディングまわりのことは別ト
ピックとして扱ってくれた方が対応しやすかったということです。
1つのパッチを採用するかどうか判断するのを4回やるのと、4つあ
るパッチからどのパッチだけを採用するかを判断するのだと、前者
の方が楽だと思っています。途中まで処理する（2つめのパッチま
では判断した）とかがやりやすいので。

これによって例えば以下のような違いが出ます。

これは何による違いですか？

14187b46 が transcode 用の文字コード指定を追加するコードです。

の話でしょうか？

おっと、また説明が不足していますね、そうです。

わかりました。
ありがとうございます。

XML 宣言で用いるエンコーディングと、変換で用いるエンコーディングを別に
したいケースがあるのですよ。
代表例が Windows-31J と Shift_JIS、CP51932 と EUC-JP です。

私は、Windows-31JとShift_JISが違うとかはわかるのですが、↑の
ことをしたいケースがどういう場合かがわかっていません。

また、XML宣言で用いるエンコーディングと変換で用いるエンコーディ
ングは同じものにするべきだと思っています。そうしないと、
REXMLが出力したXMLをパースする他のXMLパーサが困ると思っていま
す。XML宣言のエンコーディングがShift_JISなのにXMLの中に
Shift_JISにはない文字が入ってしまうかもしれないということです
よね？

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

(2010/11/20 11:36), Kouhei Sutou wrote:

[e-mail]
"[ruby-dev:42593] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports
many errors and failures without iconv" on Thu, 18 Nov 2010 23:43:14 +0900,
"NARUSE, Yui"[e-mail] wrote:

比較対象は全て UTF-8 なので、REXML::Encoding モジュールに
decode 済み or UTF-8 か否か、を示すインスタンス変数を追加というのは考えました。

内部ではそれでもよいと思いますが、利用者がXML宣言のエンコー
ディングを使いたいときに不便だと思っています。例えば、日本語っ
ぽいものだけ扱い時にエンコーディングがShift_JISかEUC-JPか
UTF-8以外のものは使わないとか、というケースを考えていました。
このとき、利用者がいちいちREXMLから返されるエンコーディング
を正規化して比較しなければいけないのは面倒だと考えています。

そういう要求が出てくることまでは想像できますが、「日本語っぽいものだけ扱い時」
には、現状 UTF-8, Shift_JIS, Windows-31J, EUC-JP, CP51932, eucJP-ms を
見ないといけないんですよね。

現実的にはエンコーディングで判定するよりも、そのニーズの場合、
XML 全体が CP932 に変換できるかで判定した方がベターだと思います。

また、生の文字列から encoding object にするのは Encoding.find(str)
だけでいけますが、Encoding オブジェクトになってしまうともう戻せない、
というのと、後述の理由で IANA の canonical name 以外を指定したい場合も
あったりして。

あ、そういうことではなく、エンコーディングまわりのことは別ト
ピックとして扱ってくれた方が対応しやすかったということです。

確かに仰るとおりです、以後そうします。

XML 宣言で用いるエンコーディングと、変換で用いるエンコーディングを別に
したいケースがあるのですよ。
代表例が Windows-31J と Shift_JIS、CP51932 と EUC-JP です。

私は、Windows-31JとShift_JISが違うとかはわかるのですが、↑の
ことをしたいケースがどういう場合かがわかっていません。

また、XML宣言で用いるエンコーディングと変換で用いるエンコーディ
ングは同じものにするべきだと思っています。そうしないと、
REXMLが出力したXMLをパースする他のXMLパーサが困ると思っていま
す。XML宣言のエンコーディングがShift_JISなのにXMLの中に
Shift_JISにはない文字が入ってしまうかもしれないということです
よね？

「他のXMLパーサ」のためにまさにこれが必要なのです。

Windows の API、kernel32 の MultiByteToWideChar や、Mlang.dll の
ConvertINetString、.NET Framework の Encoding は"Shift_JIS" を
与えると Windows-31J として、"EUC-JP" を与えると CP51932 として解釈します。

なので、これらの API を使う XML パーサを送信する時は、Ruby 側では
XML 宣言で用いるエンコーディングと、変換で用いるエンコーディングを
変える必要があります。

この辺と先の XML 宣言で用いるエンコーディング名を複合的に踏んじゃったのが、
例えばJava などから Windows 向けの XML をどうやって書き出すか、というお話です。
http://www.artonx.org/diary/20050614.html
http://d.hatena.ne.jp/Kazzz/20050614/p1

--
NARUSE, Yui [e-mail]

=end

[kou (Kouhei Sutou)]

=begin
須藤です。

In [e-mail]
"[ruby-dev:42608] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Sat, 20 Nov 2010 15:58:16 +0900,
"NARUSE, Yui" [e-mail] wrote:

内部ではそれでもよいと思いますが、利用者がXML宣言のエンコー
ディングを使いたいときに不便だと思っています。例えば、日本語っ
ぽいものだけ扱い時にエンコーディングがShift_JISかEUC-JPか
UTF-8以外のものは使わないとか、というケースを考えていました。
このとき、利用者がいちいちREXMLから返されるエンコーディング
を正規化して比較しなければいけないのは面倒だと考えています。

そういう要求が出てくることまでは想像できますが、「日本語っぽいものだけ扱い時」
には、現状 UTF-8, Shift_JIS, Windows-31J, EUC-JP, CP51932, eucJP-ms を
見ないといけないんですよね。

現実的にはエンコーディングで判定するよりも、そのニーズの場合、
XML 全体が CP932 に変換できるかで判定した方がベターだと思います。

私はそのあたりはよくわからないのですが、CP932は日本語の全部
の文字を含んでいるんでしたっけ？（EUC-JPとCP932を相互に変換
しても欠落する情報がないかどうか）

含んでいないのであれば、上記のエンコーディングかどうかを判断
した方がよさそうな気がします。

また、XML宣言で用いるエンコーディングと変換で用いるエンコーディ
ングは同じものにするべきだと思っています。そうしないと、
REXMLが出力したXMLをパースする他のXMLパーサが困ると思っていま
す。XML宣言のエンコーディングがShift_JISなのにXMLの中に
Shift_JISにはない文字が入ってしまうかもしれないということです
よね？

「他のXMLパーサ」のためにまさにこれが必要なのです。

Windows の API、kernel32 の MultiByteToWideChar や、Mlang.dll の
ConvertINetString、.NET Framework の Encoding は"Shift_JIS" を
与えると Windows-31J として、"EUC-JP" を与えると CP51932 として解釈します。

なので、これらの API を使う XML パーサを送信する時は、Ruby 側では
XML 宣言で用いるエンコーディングと、変換で用いるエンコーディングを
変える必要があります。

.NET FrameworkのXMLパーサ以外は困らないのでしょうか？
REXMLは.NET Frameworkの実装に合わせるよりはXMLの仕様に合わせ
るべきだと思っています。
（XMLパーサじゃなくてSGMLパーサとかならどっちでもいいや、と
思いますが。）

この辺と先の XML 宣言で用いるエンコーディング名を複合的に踏んじゃったのが、
例えばJava などから Windows 向けの XML をどうやって書き出すか、というお話です。
http://www.artonx.org/diary/20050614.html
http://d.hatena.ne.jp/Kazzz/20050614/p1

「Javaと.NETのXMLパーサの挙動の違いではまらないようにするに
はUTF-8を使おうね」ということのように読めました。

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

[e-mail]
"[ruby-dev:42608] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Sat, 20 Nov 2010 15:58:16 +0900,
"NARUSE, Yui"[e-mail] wrote:

内部ではそれでもよいと思いますが、利用者がXML宣言のエンコー
ディングを使いたいときに不便だと思っています。例えば、日本語っ
ぽいものだけ扱い時にエンコーディングがShift_JISかEUC-JPか
UTF-8以外のものは使わないとか、というケースを考えていました。
このとき、利用者がいちいちREXMLから返されるエンコーディング
を正規化して比較しなければいけないのは面倒だと考えています。

そういう要求が出てくることまでは想像できますが、「日本語っぽいものだけ扱い時」
には、現状 UTF-8, Shift_JIS, Windows-31J, EUC-JP, CP51932, eucJP-ms を
見ないといけないんですよね。

現実的にはエンコーディングで判定するよりも、そのニーズの場合、
XML 全体が CP932 に変換できるかで判定した方がベターだと思います。

私はそのあたりはよくわからないのですが、CP932は日本語の全部
の文字を含んでいるんでしたっけ？（EUC-JPとCP932を相互に変換
しても欠落する情報がないかどうか）

含んでいないのであれば、上記のエンコーディングかどうかを判断
した方がよさそうな気がします。

EUC-JP から CP932 に変換すると、補助漢字が落ちますね。

しかし、わたしの知る限り「日本語っぽいものだけを扱いたい時」というのは、
(1) 日本語の文字だけを扱いたい
(2) 日本語しか想定していない処理がある
(3) 右から左に書くような文字やゼロ幅文字等を蹴りたい
くらいなので、その場合エンコーディングで判定するよりも、
内容で判定した方が妥当だと思っています。

一方で、特に理由無く日本語に限定したいというのならば、それはわざわざ
気遣うべき処理でも無いので、upcase なり Encoding.find なりを
使って頂いた方がよいでしょう。

また、XML宣言で用いるエンコーディングと変換で用いるエンコーディ
ングは同じものにするべきだと思っています。そうしないと、
REXMLが出力したXMLをパースする他のXMLパーサが困ると思っていま
す。XML宣言のエンコーディングがShift_JISなのにXMLの中に
Shift_JISにはない文字が入ってしまうかもしれないということです
よね？

「他のXMLパーサ」のためにまさにこれが必要なのです。

Windows の API、kernel32 の MultiByteToWideChar や、Mlang.dll の
ConvertINetString、.NET Framework の Encoding は"Shift_JIS" を
与えると Windows-31J として、"EUC-JP" を与えると CP51932 として解釈します。

なので、これらの API を使う XML パーサを送信する時は、Ruby 側では
XML 宣言で用いるエンコーディングと、変換で用いるエンコーディングを
変える必要があります。

.NET FrameworkのXMLパーサ以外は困らないのでしょうか？
REXMLは.NET Frameworkの実装に合わせるよりはXMLの仕様に合わせ
るべきだと思っています。
（XMLパーサじゃなくてSGMLパーサとかならどっちでもいいや、と
思いますが。）

.NET Framework だけでなく、Win32API や IE の MLang を使っている XML パーサです。
Web 系は MS 実装にあわせているので、Gecko や WebKit もそうですかね。

また、常に変えるわけではなく「変えられるようにする」なので、
MS の実装にあわせるわけでもありません。

この辺と先の XML 宣言で用いるエンコーディング名を複合的に踏んじゃったのが、
例えばJava などから Windows 向けの XML をどうやって書き出すか、というお話です。
http://www.artonx.org/diary/20050614.html
http://d.hatena.ne.jp/Kazzz/20050614/p1

「Javaと.NETのXMLパーサの挙動の違いではまらないようにするに
はUTF-8を使おうね」ということのように読めました。

UTF-8 でいいじゃんという割り切り路線だと、当初のわたしの
「他のエンコーディングのために互換性を壊すべきではないので revert すべき」
と主張に帰着するかと思います。

--
NARUSE, Yui [e-mail]

=end

[kou (Kouhei Sutou)]

=begin
須藤です。

うーん、うーん、複数のことが同時に進められている気がするので
すが、成瀬さんはそのつもりで進めていますか？私は1つずつがいい
のですが。。。

ふたつのことが同時に進んでいる気がしています。

1. XML宣言をエンコーディングを文字列で表現すること。
2. XML書き出し時にエンコーディングを変更できるようにするこ
   と。

1.と2.は独立していると思っているので、もし、同時に進めようと
しているなら別々にしてほしいです。

と、私は↑のように思っているのですが、これってあっていますか？
あっているのなら、どちらから進めるのがよいか教えてもらえます
か？あっていないなら、現在、何が進んでいるのかを教えてほしい
です。。。

In [e-mail]
"[ruby-dev:42611] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Sat, 20 Nov 2010 17:56:12 +0900,
"NARUSE, Yui" [e-mail] wrote:

成瀬です。

[e-mail]
"[ruby-dev:42608] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Sat, 20 Nov 2010 15:58:16 +0900,
"NARUSE, Yui"[e-mail] wrote:

内部ではそれでもよいと思いますが、利用者がXML宣言のエンコー
ディングを使いたいときに不便だと思っています。例えば、日本語っ
ぽいものだけ扱い時にエンコーディングがShift_JISかEUC-JPか
UTF-8以外のものは使わないとか、というケースを考えていました。
このとき、利用者がいちいちREXMLから返されるエンコーディング
を正規化して比較しなければいけないのは面倒だと考えています。

そういう要求が出てくることまでは想像できますが、「日本語っぽいものだけ扱い時」
には、現状 UTF-8, Shift_JIS, Windows-31J, EUC-JP, CP51932, eucJP-ms を
見ないといけないんですよね。

現実的にはエンコーディングで判定するよりも、そのニーズの場合、
XML 全体が CP932 に変換できるかで判定した方がベターだと思います。

私はそのあたりはよくわからないのですが、CP932は日本語の全部
の文字を含んでいるんでしたっけ？（EUC-JPとCP932を相互に変換
しても欠落する情報がないかどうか）

含んでいないのであれば、上記のエンコーディングかどうかを判断
した方がよさそうな気がします。

EUC-JP から CP932 に変換すると、補助漢字が落ちますね。

しかし、わたしの知る限り「日本語っぽいものだけを扱いたい時」というのは、
(1) 日本語の文字だけを扱いたい
(2) 日本語しか想定していない処理がある
(3) 右から左に書くような文字やゼロ幅文字等を蹴りたい
くらいなので、その場合エンコーディングで判定するよりも、
内容で判定した方が妥当だと思っています。

一方で、特に理由無く日本語に限定したいというのならば、それはわざわざ
気遣うべき処理でも無いので、upcase なり Encoding.find なりを
使って頂いた方がよいでしょう。

また、XML宣言で用いるエンコーディングと変換で用いるエンコーディ
ングは同じものにするべきだと思っています。そうしないと、
REXMLが出力したXMLをパースする他のXMLパーサが困ると思っていま
す。XML宣言のエンコーディングがShift_JISなのにXMLの中に
Shift_JISにはない文字が入ってしまうかもしれないということです
よね？

「他のXMLパーサ」のためにまさにこれが必要なのです。

Windows の API、kernel32 の MultiByteToWideChar や、Mlang.dll の
ConvertINetString、.NET Framework の Encoding は"Shift_JIS" を
与えると Windows-31J として、"EUC-JP" を与えると CP51932 として解釈します。

なので、これらの API を使う XML パーサを送信する時は、Ruby 側では
XML 宣言で用いるエンコーディングと、変換で用いるエンコーディングを
変える必要があります。

.NET FrameworkのXMLパーサ以外は困らないのでしょうか？
REXMLは.NET Frameworkの実装に合わせるよりはXMLの仕様に合わせ
るべきだと思っています。
（XMLパーサじゃなくてSGMLパーサとかならどっちでもいいや、と
思いますが。）

.NET Framework だけでなく、Win32API や IE の MLang を使っている XML パーサです。
Web 系は MS 実装にあわせているので、Gecko や WebKit もそうですかね。

また、常に変えるわけではなく「変えられるようにする」なので、
MS の実装にあわせるわけでもありません。

この辺と先の XML 宣言で用いるエンコーディング名を複合的に踏んじゃったのが、
例えばJava などから Windows 向けの XML をどうやって書き出すか、というお話です。
http://www.artonx.org/diary/20050614.html
http://d.hatena.ne.jp/Kazzz/20050614/p1

「Javaと.NETのXMLパーサの挙動の違いではまらないようにするに
はUTF-8を使おうね」ということのように読めました。

UTF-8 でいいじゃんという割り切り路線だと、当初のわたしの
「他のエンコーディングのために互換性を壊すべきではないので revert すべき」
と主張に帰着するかと思います。

--
NARUSE, Yui [e-mail]

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

(2010/11/21 18:36), Kouhei Sutou wrote:

うーん、うーん、複数のことが同時に進められている気がするので
すが、成瀬さんはそのつもりで進めていますか？私は1つずつがいい
のですが。。。

えーっと、2つと言えば2つですかね。

ふたつのことが同時に進んでいる気がしています。

1. XML宣言をエンコーディングを文字列で表現すること。
2. XML書き出し時にエンコーディングを変更できるようにするこ
   と。

2. はXML書き出し時の変換用エンコーディングを、ということですよね。

1.と2.は独立していると思っているので、もし、同時に進めようと
しているなら別々にしてほしいです。

独立とは違いますかね、2. は 1. に依存していると思います。

より正確には、
まず XMLDecl#encoding がいて、
XML 宣言のエンコーディング属性は XMLDecl#encoding を使っている。
XML書き出し時の変換用エンコーディングも XMLDecl#encoding を用いている。
になりますか。

と、私は↑のように思っているのですが、これってあっていますか？
あっているのなら、どちらから進めるのがよいか教えてもらえます
か？あっていないなら、現在、何が進んでいるのかを教えてほしい
です。。。

依存関係が上記の通りなので、まず XMLDecl#encoding を決める必要があります。

XMLDecl#encoding 単体での論点は、

• 型
• 型が String の場合、正規化するかどうか
  でしょう。

わたしは、[ruby-dev:42608] で挙げた csWindows31J を指定したい例を考えるに、
String でかつ正規化しない必要があると考えています。

--
NARUSE, Yui [e-mail]

=end

[kou (Kouhei Sutou)]

=begin
須藤です。

In [e-mail]
"[ruby-dev:42614] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Sun, 21 Nov 2010 21:49:07 +0900,
"NARUSE, Yui" [e-mail] wrote:

依存関係が上記の通りなので、まず XMLDecl#encoding を決める必要があります。

XMLDecl#encoding 単体での論点は、

• 型
• 型が String の場合、正規化するかどうか
  でしょう。

わたしは、[ruby-dev:42608] で挙げた csWindows31J を指定したい例を考えるに、
String でかつ正規化しない必要があると考えています。

わかりました！
では、XMLDecl#encodingの方からで！

ただ、少なくとも札幌Ruby会議03が終わるころまでは手をつけられ
ないのでそれからでお願いします。。。

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

(2010/11/22 21:07), Kouhei Sutou wrote:

[e-mail]
"[ruby-dev:42614] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss
reports many errors and failures without iconv" on Sun, 21 Nov 2010 21:49:07 +0900,
"NARUSE, Yui"[e-mail] wrote:

依存関係が上記の通りなので、まず XMLDecl#encoding を決める必要があります。

XMLDecl#encoding 単体での論点は、

• 型
• 型が String の場合、正規化するかどうか
  でしょう。

わたしは、[ruby-dev:42608] で挙げた csWindows31J を指定したい例を考えるに、
String でかつ正規化しない必要があると考えています。

わかりました！
では、XMLDecl#encodingの方からで！

はい。

わたしの主張だけまとめておくと、

• XMLDecl#encoding は String であるべき
• XMLDecl#encoding= や初期化等では正規化しない
• XMLDecl#canonical_encoding_name 等を追加することには反対しない
  (けど、いらないんじゃないかなぁ、要ユースケース)

理由は XML 宣言のエンコーディング属性は正規名以外を入れたい時があるから。
その「入れたい時」とは想定している受信パーサが解釈可能な
エンコーディング名がその正規名と異なる場合。

と言ったところでしょうか。

--
NARUSE, Yui [e-mail]

=end

[kou (Kouhei Sutou)]

=begin
須藤です。

ここ1,2ヶ月は手をつけられそうなので、今、考えている分だけ書
いておきます。

In [e-mail]
"[ruby-dev:42618] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Tue, 23 Nov 2010 02:56:41 +0900,
"NARUSE, Yui" [e-mail] wrote:

依存関係が上記の通りなので、まず XMLDecl#encoding を決める必要があります。

XMLDecl#encoding 単体での論点は、

• 型
• 型が String の場合、正規化するかどうか
  でしょう。

わたしは、[ruby-dev:42608] で挙げた csWindows31J を指定したい例を考えるに、
String でかつ正規化しない必要があると考えています。

わかりました！
では、XMLDecl#encodingの方からで！

はい。

わたしの主張だけまとめておくと、

• XMLDecl#encoding は String であるべき
• XMLDecl#encoding= や初期化等では正規化しない
• XMLDecl#canonical_encoding_name 等を追加することには反対しない
  (けど、いらないんじゃないかなぁ、要ユースケース)

理由は XML 宣言のエンコーディング属性は正規名以外を入れたい時があるから。
その「入れたい時」とは想定している受信パーサが解釈可能な
エンコーディング名がその正規名と異なる場合。

と言ったところでしょうか。

時間がたって忘れかけているのですが、

XMLDecl#encoding は String であるべき

というよりは、

XML宣言に記述するエンコーディング（=情報交換用符号ですよ
ね？）と内部処理に使うエンコーディング（=内部処理用符号
=transcode ですよね？）を別々に管理できるようにするべき

ですよね？

で、別々にしないと困る例がUTF-16とUTF-32なんですよね。
当時のRubyにはUTF-16とUTF-32というEncodingがなかったので「情
報交換用符号」を表現できないからEncodingを使っちゃだめで、
UTF-16とUTF-32に対応するためには代わりにStringを使うこと、と
いうことだと認識しています。あっていますか？

今、trunkをみてみると、UTF-16/UTF-32というEncodingが追加され
ていたので、「情報交換用符号」の表現としてEncodingを使えると
思っています。

それとは別に「内部処理用符号」を持つようにしようと思っていま
す。名前はXMLDecl#transcode, XMLDecl#transcode=がいいんじゃな
いかと思っています。これにもEncodingを使うつもりです。

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

2011年2月21日22:50 Kouhei Sutou [e-mail]:

XMLDecl#encoding は String であるべき

というよりは、

XML宣言に記述するエンコーディング（=情報交換用符号ですよ
ね？）と内部処理に使うエンコーディング（=内部処理用符号
=transcode ですよね？）を別々に管理できるようにするべき

ですよね？

「別々に管理できる」に加えて、どのような名を名乗るかまで必要です。
で、Encodingを用いるとEncoding#nameを実際に記述するエンコーディング名に
用いると思いますが、この場合名前の正規化が走ってしまうのでまずいのです。
具体例としては 「csWindows31J」を用いたい時とか。

で、別々にしないと困る例がUTF-16とUTF-32なんですよね。
当時のRubyにはUTF-16とUTF-32というEncodingがなかったので「情
報交換用符号」を表現できないからEncodingを使っちゃだめで、
UTF-16とUTF-32に対応するためには代わりにStringを使うこと、と
いうことだと認識しています。あっていますか？

今、trunkをみてみると、UTF-16/UTF-32というEncodingが追加され
ていたので、「情報交換用符号」の表現としてEncodingを使えると
思っています。

というわけで、UTF-16 と UTF-32 は追加しましたがそれだけでは不十分なのです。

それとは別に「内部処理用符号」を持つようにしようと思っていま
す。名前はXMLDecl#transcode, XMLDecl#transcode=がいいんじゃな
いかと思っています。これにもEncodingを使うつもりです。

内部処理用符号を持つことには賛成します。

けれども「transcode」はCRubyのエンコーディング変換エンジンの実装名で、
Rubyレイヤにはその名は出していないはずです。
よって、ここで「transcode」というメソッド名を用いるのは不適だと考えます。

私だったら長くても internal_encoding を使うかなぁ、IO とかでも使ってるので。

--
NARUSE, Yui [e-mail]

=end

[kou (Kouhei Sutou)]

=begin
須藤です。

あとでまた考えるのですが、今、考えていることをメモがわりに送っ
ておきます。

In AANLkTimCVoPzMzKjnj8WPOEU-aBx=[e-mail]
"[ruby-dev:43246] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Tue, 22 Feb 2011 18:13:38 +0900,
"NARUSE, Yui" [e-mail] wrote:

XMLDecl#encoding は String であるべき

というよりは、

XML宣言に記述するエンコーディング（=情報交換用符号ですよ
ね？）と内部処理に使うエンコーディング（=内部処理用符号
=transcode ですよね？）を別々に管理できるようにするべき

ですよね？

「別々に管理できる」に加えて、どのような名を名乗るかまで必要です。
で、Encodingを用いるとEncoding#nameを実際に記述するエンコーディング名に
用いると思いますが、この場合名前の正規化が走ってしまうのでまずいのです。
具体例としては 「csWindows31J」を用いたい時とか。

むぅ。「csWindows31J」ですか。
「csWindows31J」を使いたいときというのは、ようはMicrosoft向
けにXMLを出力したいときですよね。であれば、文字列化するとき
に:for_microsoft => trueみたいなオプションを指定するような
APIの方がよいと考えています。理由はそっちの方が意図を表現し
ているからです。

そもそも、私がXML宣言のエンコーディングにEncodingを使いたいの
はtypoとかの間違いをなるべく起こしづらかったり、気付きやすい
APIにしたいからです。REXMLはRubyのtranscode（ですよね？）をベー
スにしているため、transcodeが対応しているエンコーディング以外
は扱えないので、XML宣言をEncodingで表現すれば、サポート外のも
のを検出しやすくなると思っています。

それとは別に「内部処理用符号」を持つようにしようと思っていま
す。名前はXMLDecl#transcode, XMLDecl#transcode=がいいんじゃな
いかと思っています。これにもEncodingを使うつもりです。

内部処理用符号を持つことには賛成します。

けれども「transcode」はCRubyのエンコーディング変換エンジンの実装名で、
Rubyレイヤにはその名は出していないはずです。
よって、ここで「transcode」というメソッド名を用いるのは不適だと考えます。

なんと。一般的な用語なのかと思っていました。
であれば、別にアクセサを提供しなくてもよいかなぁという気になっ
てきました。そんなに頻繁に使うような気もしないので、属性や内
容をとってきてencodingしてもらうのでも困らなそう。

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

(2011/02/22 22:12), Kouhei Sutou wrote:

In AANLkTimCVoPzMzKjnj8WPOEU-aBx=[e-mail]
"[ruby-dev:43246] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Tue, 22 Feb 2011 18:13:38 +0900,
"NARUSE, Yui" [e-mail] wrote:

XMLDecl#encoding は String であるべき

というよりは、

XML宣言に記述するエンコーディング（=情報交換用符号ですよ
ね？）と内部処理に使うエンコーディング（=内部処理用符号
=transcode ですよね？）を別々に管理できるようにするべき

ですよね？

「別々に管理できる」に加えて、どのような名を名乗るかまで必要です。
で、Encodingを用いるとEncoding#nameを実際に記述するエンコーディング名に
用いると思いますが、この場合名前の正規化が走ってしまうのでまずいのです。
具体例としては 「csWindows31J」を用いたい時とか。

むぅ。「csWindows31J」ですか。
「csWindows31J」を使いたいときというのは、ようはMicrosoft向
けにXMLを出力したいときですよね。であれば、文字列化するとき
に:for_microsoft => trueみたいなオプションを指定するような
APIの方がよいと考えています。理由はそっちの方が意図を表現し
ているからです。

出力のエンコーディングは Windows-31J だけど名乗りは Shift_JIS にさせたい
という例もありえますね。また、さらに Solaris 用に PCK と名乗らせたいとか。
(PCK は Windows-31J か Shift_JIS の alias として追加予定)

別のユースケースだと、ケータイ絵文字を含んだUTF-8なXHTMLをREXMLで処理して、
UTF8-DoCoMoとして出力しつつ、そいつにUTF-8と名乗らせたいとか。

一般論としては XML 宣言の encoding 属性は受信側のXMLパーサの
文字コード変換器の引数なので、Ruby が変換は可能だが名前を知らない場合や、
Ruby では alias になっちゃってる例が考えられます。

そもそも、私がXML宣言のエンコーディングにEncodingを使いたいの
はtypoとかの間違いをなるべく起こしづらかったり、気付きやすい
APIにしたいからです。REXMLはRubyのtranscode（ですよね？）をベー
スにしているため、transcodeが対応しているエンコーディング以外
は扱えないので、XML宣言をEncodingで表現すれば、サポート外のも
のを検出しやすくなると思っています。

そもそも、Encoding は鬼車のモジュールに対応するオブジェクトで、
transcode の変換器に対する引数とは別の話ですよ。
例えば変換時に Apple 版 NFD を行うことを意味する UTF8-MAC なんかは、
現状 encoding としても別になってますが、これは失敗だった気がするので
UTF-8 に統合しようかとも思っていたり。

また、encoding 宣言は送信側である Ruby/REXML ではなく、
受信側が解釈するものなので、こちらがサポートしているかどうかは本質的には
問題ではありませんね。Encoding オブジェクトを受け付けてもいいとは思いますが。

それとは別に「内部処理用符号」を持つようにしようと思っていま
す。名前はXMLDecl#transcode, XMLDecl#transcode=がいいんじゃな
いかと思っています。これにもEncodingを使うつもりです。

内部処理用符号を持つことには賛成します。

けれども「transcode」はCRubyのエンコーディング変換エンジンの実装名で、
Rubyレイヤにはその名は出していないはずです。
よって、ここで「transcode」というメソッド名を用いるのは不適だと考えます。

なんと。一般的な用語なのかと思っていました。
であれば、別にアクセサを提供しなくてもよいかなぁという気になっ
てきました。そんなに頻繁に使うような気もしないので、属性や内
容をとってきてencodingしてもらうのでも困らなそう。

うむむ？ここの「内部処理用符号」って現在もっぱら UTF-8 を使っている、
REXML 内部でXML断片に用いる encoding とは別でしたか？

念のためまとめ直すと、登場人物は以下の三者ですね。

• REXML 内部エンコーディング
  • REXML 内部での処理で用いるエンコーディング
  • 現在もっぱら UTF-8
  • Encoding オブジェクト可
• REXML 出力エンコーディング
  • 文字列化して出力した結果の encoding
  • transcode が「内部to出力」の変換を扱える必要
  • Encoding オブジェクト可
• 出力結果のXML宣言のencoding属性の値
  • 出力結果を解釈するどこかのXMLパーサが見る値
  • Ruby が理解できる必要はない
  • String が望ましい

--
NARUSE, Yui [e-mail]

=end

[kou (Kouhei Sutou)]

=begin
須藤です。

In [e-mail]
"[ruby-dev:43248] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Tue, 22 Feb 2011 23:32:17 +0900,
"NARUSE, Yui" [e-mail] wrote:

出力のエンコーディングは Windows-31J だけど名乗りは Shift_JIS にさせたい
という例もありえますね。また、さらに Solaris 用に PCK と名乗らせたいとか。
(PCK は Windows-31J か Shift_JIS の alias として追加予定)

うーん。
Solarisで動くXMLパーサ（？iconv？）はPCKというのも解釈するん
ですか。

別のユースケースだと、ケータイ絵文字を含んだUTF-8なXHTMLをREXMLで処理して、
UTF8-DoCoMoとして出力しつつ、そいつにUTF-8と名乗らせたいとか。

あぁ、これはありそうですねぇ。

一般論としては XML 宣言の encoding 属性は受信側のXMLパーサの
文字コード変換器の引数なので、Ruby が変換は可能だが名前を知らない場合や、
Ruby では alias になっちゃってる例が考えられます。

これがしっくりこないんですよね。
XMLはポータブルな書式だった気がするんですが、特定のXMLパーサ
のみで動くような出力にするのを推奨するみたいだからかしら。

そもそも、Encoding は鬼車のモジュールに対応するオブジェクトで、
transcode の変換器に対する引数とは別の話ですよ。

え、そうなんですか。

また、encoding 宣言は送信側である Ruby/REXML ではなく、
受信側が解釈するものなので、こちらがサポートしているかどうかは本質的には
問題ではありませんね。Encoding オブジェクトを受け付けてもいいとは思いますが。

↑の通りXMLの本質的なのはポータブルであることだと思っている
ので、問題な気がするんですよね。

うむむ？ここの「内部処理用符号」って現在もっぱら UTF-8 を使っている、
REXML 内部でXML断片に用いる encoding とは別でしたか？

あぁ、そういえば、そうだったかも。
失礼しました。

念のためまとめ直すと、登場人物は以下の三者ですね。

• REXML 内部エンコーディング
  • REXML 内部での処理で用いるエンコーディング
  • 現在もっぱら UTF-8
  • Encoding オブジェクト可
• REXML 出力エンコーディング
  • 文字列化して出力した結果の encoding
  • transcode が「内部to出力」の変換を扱える必要
  • Encoding オブジェクト可
• 出力結果のXML宣言のencoding属性の値
  • 出力結果を解釈するどこかのXMLパーサが見る値
  • Ruby が理解できる必要はない
  • String が望ましい

ありがとうございます。
うんん。やっぱりまだちょっとでも手を出さなかったほうがよかっ
たかも。また、数ヶ月後に（時間ができたら）考えます。

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

(2011/02/22 23:47), Kouhei Sutou wrote:

出力のエンコーディングは Windows-31J だけど名乗りは Shift_JIS にさせたい
という例もありえますね。また、さらに Solaris 用に PCK と名乗らせたいとか。
(PCK は Windows-31J か Shift_JIS の alias として追加予定)

うーん。
Solarisで動くXMLパーサ（？iconv？）はPCKというのも解釈するん
ですか。

Solaris の iconv はこの辺とかですね。「PC漢字」という名称由来らしい。
http://download.oracle.com/docs/cd/E19455-01/816-2371/6m8no45nr/index.html
前提として、iconv って glibc iconv / GNU libiconv だけじゃないので。

一般論としては XML 宣言の encoding 属性は受信側のXMLパーサの
文字コード変換器の引数なので、Ruby が変換は可能だが名前を知らない場合や、
Ruby では alias になっちゃってる例が考えられます。

これがしっくりこないんですよね。
XMLはポータブルな書式だった気がするんですが、特定のXMLパーサ
のみで動くような出力にするのを推奨するみたいだからかしら。

XML がポータブルなのは外枠だけでしょう。
中身は基本的に一定の受信者が想定されていると思います。
XHTML でいえば想定されているのはもっぱら Web ブラウザとか、
オレオレXMLデータなら対応するオレプロダクトとか。

逆に言えば外枠だけにとどめているから XML 自体はあれだけシンプルかつポータブルになったと。

そもそも、Encoding は鬼車のモジュールに対応するオブジェクトで、
transcode の変換器に対する引数とは別の話ですよ。

え、そうなんですか。

transcode への from/to 引数はあくまで変換表を呼び出すための識別子なので、
本質的には Encoding とは独立の存在になっています。
実際の実装でも、UTF-7 は encoding があっても変換がなく、
escape 絡みでは変換があっても対応する encoding は当然ながらありません。

また、encoding 宣言は送信側である Ruby/REXML ではなく、
受信側が解釈するものなので、こちらがサポートしているかどうかは本質的には
問題ではありませんね。Encoding オブジェクトを受け付けてもいいとは思いますが。

↑の通りXMLの本質的なのはポータブルであることだと思っている
ので、問題な気がするんですよね。

「UTF-8 と UTF-16 以外のエンコーディングはポータブルではない」で答えになりませんかね。
"All XML processors must accept the UTF-8 and UTF-16 encodings of Unicode"
http://www.w3.org/TR/REC-xml/#charsets

うんん。やっぱりまだちょっとでも手を出さなかったほうがよかっ
たかも。また、数ヶ月後に（時間ができたら）考えます。

yugui さんが RubyKaigi あたりで 1.9.3 を出したいと仰っていたはずなので、
数ヶ月だとそこへの仕様変更のタイミングとしてはぎりぎりになります。
というか、そこから議論を始めると高確率でアウトでしょう。
で、現状既に REXML::XMLDecl#encoding は仕様変更が入っているんですが、
ここは巻き戻しませんか。ここ以外は今入っている修正については賛成なので。

--
NARUSE, Yui [e-mail]

=end

[kou (Kouhei Sutou)]

• ruby -v changed from ruby 1.9.3dev (2010-10-27 trunk 29612) [x64-mswin64_100] to -

=begin
須藤です。

In [e-mail]
"[ruby-dev:43250] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Wed, 23 Feb 2011 00:27:19 +0900,
"NARUSE, Yui" [e-mail] wrote:

うんん。やっぱりまだちょっとでも手を出さなかったほうがよかっ
たかも。また、数ヶ月後に（時間ができたら）考えます。

yugui さんが RubyKaigi あたりで 1.9.3 を出したいと仰っていたはずなので、
数ヶ月だとそこへの仕様変更のタイミングとしてはぎりぎりになります。
というか、そこから議論を始めると高確率でアウトでしょう。
で、現状既に REXML::XMLDecl#encoding は仕様変更が入っているんですが、
ここは巻き戻しませんか。ここ以外は今入っている修正については賛成なので。

まだ#encodingはEncodingを返すのでOKだと思っているのですが、変
更前ではできて、現状ではできないことがあるということはわかり
ました。（ただ、それを実現する方法は#encodingがEncodingを返す
かどうかとは別の方法がいいんじゃないかと思っている。）

なので、時間がないということであれば、巻き戻すということでOK
です。お手数ですが、巻き戻してもらえますか？

ところで、フリーズはいつになるかってどこかにでていましたっけ。
もし、フリーズ前に時間ができたらいじろうかと思うのですが。。。
=end

[kou (Kouhei Sutou)]

=begin
須藤です。

In [e-mail]
"[ruby-dev:43250] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Wed, 23 Feb 2011 00:27:19 +0900,
"NARUSE, Yui" [e-mail] wrote:

うんん。やっぱりまだちょっとでも手を出さなかったほうがよかっ
たかも。また、数ヶ月後に（時間ができたら）考えます。

yugui さんが RubyKaigi あたりで 1.9.3 を出したいと仰っていたはずなので、
数ヶ月だとそこへの仕様変更のタイミングとしてはぎりぎりになります。
というか、そこから議論を始めると高確率でアウトでしょう。
で、現状既に REXML::XMLDecl#encoding は仕様変更が入っているんですが、
ここは巻き戻しませんか。ここ以外は今入っている修正については賛成なので。

まだ#encodingはEncodingを返すのでOKだと思っているのですが、変
更前ではできて、現状ではできないことがあるということはわかり
ました。（ただ、それを実現する方法は#encodingがEncodingを返す
かどうかとは別の方法がいいんじゃないかと思っている。）

なので、時間がないということであれば、巻き戻すということでOK
です。お手数ですが、巻き戻してもらえますか？

ところで、フリーズはいつになるかってどこかにでていましたっけ。
もし、フリーズ前に時間ができたらいじろうかと思うのですが。。。
=end

[naruse (Yui NARUSE)]

• Status changed from Closed to Assigned

=begin

なので、時間がないということであれば、巻き戻すということでOK
です。お手数ですが、巻き戻してもらえますか？

とりあえずrevertしておきました。

まだ#encodingはEncodingを返すのでOKだと思っているのですが

REXML::XMLDecl#encoding が一体何を保持するものなのかって話ですよね、結局のところ。

ところで、フリーズはいつになるかってどこかにでていましたっけ。
もし、フリーズ前に時間ができたらいじろうかと思うのですが。。。

まず前提として、フリーズはリリースの3ヶ月程度前になります (仕様フリーズとコードフリーズで違いますが、まぁこれは仕様の方ですね)。
で、1.9.3 のリリースは次の RubyKaigi (7/16-18) までに出したいような事を以前 yugui さんはおっしゃってました。
http://redmine.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20100827
=end

[ko1 (Koichi Sasada)]

=begin
(2011/03/03 18:56), Yui NARUSE wrote:

で、1.9.3 のリリースは次の RubyKaigi (7/16-18) までに出したいような事を以前 yugui さんはおっしゃってました。

　初耳なのですが（いや，どっかで見たかも），決定事項でしょうか．

--
// SASADA Koichi at atdot dot net
=end

[ko1 (Koichi Sasada)]

=begin
(2011/03/03 18:56), Yui NARUSE wrote:

で、1.9.3 のリリースは次の RubyKaigi (7/16-18) までに出したいような事を以前 yugui さんはおっしゃってました。

　初耳なのですが（いや，どっかで見たかも），決定事項でしょうか．

--
// SASADA Koichi at atdot dot net
=end

[usa (Usaku NAKAMURA)]

=begin
こんにちは、なかむら(う)です。

In message "[ruby-dev:43297] Re: [Ruby 1.9 - Bug #3990] [Assigned]tests of rexml/rss reports many errors and failures without iconv"
on Mar.03,2011 18:59:49, [e-mail] wrote:

(2011/03/03 18:56), Yui NARUSE wrote:

で、1.9.3 のリリースは次の RubyKaigi (7/16-18) までに出したいような事を以前 yugui さんはおっしゃってました。

　初耳なのですが（いや，どっかで見たかも），決定事項でしょうか．

ささださんもいたはずの、RubyKaigi 2010の開発者ミーティングで
出てましたよ。
議事録には Before Jul, 2011 (RubyKaigi? RubyConf?) と書いてあ
りますね。

とりあえずの目標みたいなもんで、決定事項ではなかったと記憶し
ています。

それでは。

U.Nakamura [e-mail]
=end

[usa (Usaku NAKAMURA)]

=begin
こんにちは、なかむら(う)です。

In message "[ruby-dev:43297] Re: [Ruby 1.9 - Bug #3990] [Assigned]tests of rexml/rss reports many errors and failures without iconv"
on Mar.03,2011 18:59:49, [e-mail] wrote:

(2011/03/03 18:56), Yui NARUSE wrote:

で、1.9.3 のリリースは次の RubyKaigi (7/16-18) までに出したいような事を以前 yugui さんはおっしゃってました。

　初耳なのですが（いや，どっかで見たかも），決定事項でしょうか．

ささださんもいたはずの、RubyKaigi 2010の開発者ミーティングで
出てましたよ。
議事録には Before Jul, 2011 (RubyKaigi? RubyConf?) と書いてあ
りますね。

とりあえずの目標みたいなもんで、決定事項ではなかったと記憶し
ています。

それでは。

U.Nakamura [e-mail]
=end

[ko1 (Koichi Sasada)]

=begin
　ささだです．

(2011/03/03 19:12), U.Nakamura wrote:

ささださんもいたはずの、RubyKaigi 2010の開発者ミーティングで
出てましたよ。
議事録には Before Jul, 2011 (RubyKaigi? RubyConf?) と書いてあ
りますね。

とりあえずの目標みたいなもんで、決定事項ではなかったと記憶し
ています。

　なるほど．実際，どうします？

　7月リリースを目指すとなると，4月に仕様フリーズ，5月に実装フリーズ，っ
て感じでしょうか．

--
// SASADA Koichi at atdot dot net
=end

[ko1 (Koichi Sasada)]

=begin
　ささだです．

(2011/03/03 19:12), U.Nakamura wrote:

ささださんもいたはずの、RubyKaigi 2010の開発者ミーティングで
出てましたよ。
議事録には Before Jul, 2011 (RubyKaigi? RubyConf?) と書いてあ
りますね。

とりあえずの目標みたいなもんで、決定事項ではなかったと記憶し
ています。

　なるほど．実際，どうします？

　7月リリースを目指すとなると，4月に仕様フリーズ，5月に実装フリーズ，っ
て感じでしょうか．

--
// SASADA Koichi at atdot dot net
=end

[znz (Kazuhiro NISHIYAMA)]

=begin
西山和広です。

At Thu, 3 Mar 2011 19:25:34 +0900,
SASADA Koichi wrote:

(2011/03/03 19:12), U.Nakamura wrote:

ささださんもいたはずの、RubyKaigi 2010の開発者ミーティングで
出てましたよ。
議事録には Before Jul, 2011 (RubyKaigi? RubyConf?) と書いてあ
りますね。

とりあえずの目標みたいなもんで、決定事項ではなかったと記憶し
ています。

　なるほど．実際，どうします？

　7月リリースを目指すとなると，4月に仕様フリーズ，5月に実装フリーズ，っ
て感じでしょうか．

そろそろ4月も終わりが近いですが、このあたりの話はどうなっているのでしょうか?

--
|ZnZ(ゼット エヌ ゼット)
|西山和広(Kazuhiro NISHIYAMA)
=end

[znz (Kazuhiro NISHIYAMA)]

=begin
西山和広です。

At Thu, 3 Mar 2011 19:25:34 +0900,
SASADA Koichi wrote:

(2011/03/03 19:12), U.Nakamura wrote:

ささださんもいたはずの、RubyKaigi 2010の開発者ミーティングで
出てましたよ。
議事録には Before Jul, 2011 (RubyKaigi? RubyConf?) と書いてあ
りますね。

とりあえずの目標みたいなもんで、決定事項ではなかったと記憶し
ています。

　なるほど．実際，どうします？

　7月リリースを目指すとなると，4月に仕様フリーズ，5月に実装フリーズ，っ
て感じでしょうか．

そろそろ4月も終わりが近いですが、このあたりの話はどうなっているのでしょうか?

--
|ZnZ(ゼット エヌ ゼット)
|西山和広(Kazuhiro NISHIYAMA)
=end

[ko1 (Koichi Sasada)]

須藤さん

こちら，どうなってますでしょうか．

[kou (Kouhei Sutou)]

もう、触っちゃダメだということだと思っていたので、1.9.3がリリースした後でやろうと思っていました。

なるせさんが言っている通り、

REXML::XMLDecl#encoding が一体何を保持するものなのかって話ですよね、結局のところ。

のところで思うところがあるのですが、文章でやりとりしていても落とし所が見つかる気がしなかったので、Ruby会議の時にでも相談しようかと思っていました。

[ko1 (Koichi Sasada)]

　ささだです．

(2011/06/11 15:44), Kouhei Sutou wrote:

もう、触っちゃダメだということだと思っていたので、1.9.3がリリースした後でやろうと思っていました。

なるせさんが言っている通り、

REXML::XMLDecl#encoding が一体何を保持するものなのかって話ですよね、結局のところ。
のところで思うところがあるのですが、文章でやりとりしていても落とし所が見つかる気がしなかったので、Ruby会議の時にでも相談しようかと思っていました。

　最初のチケットから，大分話がそれたと思うので，このチケットは閉じて頂い
て，新しく仕切り直して頂くことは出来るでしょうか．

それとも，私がわかっていないだけで，それていない？

--
// SASADA Koichi at atdot dot net

[ko1 (Koichi Sasada)]

　ささだです．

(2011/06/11 15:44), Kouhei Sutou wrote:

もう、触っちゃダメだということだと思っていたので、1.9.3がリリースした後でやろうと思っていました。

なるせさんが言っている通り、

REXML::XMLDecl#encoding が一体何を保持するものなのかって話ですよね、結局のところ。
のところで思うところがあるのですが、文章でやりとりしていても落とし所が見つかる気がしなかったので、Ruby会議の時にでも相談しようかと思っていました。

　最初のチケットから，大分話がそれたと思うので，このチケットは閉じて頂い
て，新しく仕切り直して頂くことは出来るでしょうか．

それとも，私がわかっていないだけで，それていない？

--
// SASADA Koichi at atdot dot net

[kou (Kouhei Sutou)]

• Status changed from Assigned to Closed

#4872 として新しくチケットを作ったので、これはcloseします。