XMLなんでもスレ。
前スレ: 【XML】xmlns, XSLT, RelaxNG, JAXP, etc.【総合】
http://pc11.2ch.net/test/read.cgi/tech/1133280488/
前々スレ: 【必須?】XML技術【使ってる?】
http://pc8.2ch.net/test/read.cgi/tech/1090253584/
探検
<XML総合 part="3"/>
■ このスレッドは過去ログ倉庫に格納されています
2008/10/07(火) 17:40:09
2008/11/19(水) 04:48:29
<Keywords>
<Keyword>あ</Keyword>
<Keyword>い</Keyword>
<Keyword>う</Keyword>
</Keywords>
みたいなXMLがあって、それをXSLで
perlで書くと
---
my @Keyword = qw( あ い う );
my $out = join(',', @Keyword);
print $out, "\n";
## 出力:あ,い,う
---
と同じことがしたんだけど、Javascriptを使わないで出来ますか?
詳しい人方法をplz
<Keyword>あ</Keyword>
<Keyword>い</Keyword>
<Keyword>う</Keyword>
</Keywords>
みたいなXMLがあって、それをXSLで
perlで書くと
---
my @Keyword = qw( あ い う );
my $out = join(',', @Keyword);
print $out, "\n";
## 出力:あ,い,う
---
と同じことがしたんだけど、Javascriptを使わないで出来ますか?
詳しい人方法をplz
2008/11/19(水) 13:18:17
>>39
xsl:for-each と xsl:value-of で検索。
xsl:for-each と xsl:value-of で検索。
2008/11/20(木) 02:52:00
XMLマスターのスレってある?
いろんな板見たけど見つからなかったんだけど
いろんな板見たけど見つからなかったんだけど
2008/11/21(金) 08:51:16
探して見つからなかったならないと思うよ。
2008/11/21(金) 22:14:41
立てたら?
44デフォルトの名無しさん
2008/11/26(水) 15:10:40 >>42
なんかお前イライラする
なんかお前イライラする
2008/11/26(水) 19:39:47
そうですね!
2008/11/26(水) 22:04:56
yes we can.
47デフォルトの名無しさん
2008/11/27(木) 15:08:30 楽天APIで出力されるXMLをPHP5で解析しようとしてるんだが、
$xml = new SimpleXMLElement($xmlstr);
echo $xml->Body->itemRanking->Item[0]->title;
こんな感じでデータ取り出せないのかな。
どうしてもうまくいかない。
$xml = new SimpleXMLElement($xmlstr);
echo $xml->Body->itemRanking->Item[0]->title;
こんな感じでデータ取り出せないのかな。
どうしてもうまくいかない。
2008/11/27(木) 21:52:38
出力されるXMLを見ないとなんとも言えん
2008/11/29(土) 23:30:41
基本的な質問
タグ内にテキスト(PCDATA)とタグを混在させるのはありらしいですが、
なんか気持ち悪いのです
<title>テキスト1<keyword>テキスト2</keyword>テキスト3</title>
↑こういう書き方は普通にありなんでしょうか?
タグ内にテキスト(PCDATA)とタグを混在させるのはありらしいですが、
なんか気持ち悪いのです
<title>テキスト1<keyword>テキスト2</keyword>テキスト3</title>
↑こういう書き方は普通にありなんでしょうか?
2008/11/29(土) 23:48:44
普通にあり。
title要素が、テキストノード、keyword要素、テキストノード、をchild nodes
title要素が、テキストノード、keyword要素、テキストノード、をchild nodes
2008/11/29(土) 23:57:29
>>50
ありがとうございます
テキスト1とテキスト2とテキスト3は意味的には1つの繋がった文章なのですが
(要するにプログラム解釈としてkeyword要素を強調解釈させたい(文字装飾とかリンクのため)
テキストの中にタグを入れるというと文章が分断されてしまう感じがしたもので
普通にありならば堂々と使っていきたいと思います
ありがとうございます
テキスト1とテキスト2とテキスト3は意味的には1つの繋がった文章なのですが
(要するにプログラム解釈としてkeyword要素を強調解釈させたい(文字装飾とかリンクのため)
テキストの中にタグを入れるというと文章が分断されてしまう感じがしたもので
普通にありならば堂々と使っていきたいと思います
2008/11/30(日) 00:11:34
HTMLとか見たことないのかい?
2008/11/30(日) 07:07:58
XMLみたいな文法厳しいものの前にHTML理解してこいって感じだな(汗
2008/11/30(日) 13:59:10
そもそもXMLはテキストをマークアップするための言語なわけだが…
2008/11/30(日) 15:23:18
51だけど
HTML見たことないわけねーだろ
DTDでいう<!ELEMENT tag1 (#PCDATA | tag2)*>って
気持ち悪くないのか?
なんかXMLって扱いにくいね
こういうとお前が馬鹿な(ryとか来そうだが
HTML見たことないわけねーだろ
DTDでいう<!ELEMENT tag1 (#PCDATA | tag2)*>って
気持ち悪くないのか?
なんかXMLって扱いにくいね
こういうとお前が馬鹿な(ryとか来そうだが
2008/11/30(日) 15:47:18
PCDATAが気持ち悪いっていうことがもう爆笑なんだがwww
お前終わってるだろ
お前終わってるだろ
2008/11/30(日) 17:35:55
#PCDATAとtag2の混合が気持ち悪いって言ってんだろ
ちなみに爆笑するお前も気持ち悪い
ちなみに爆笑するお前も気持ち悪い
2008/11/30(日) 17:42:56
もっと罵って欲しい
2008/11/30(日) 18:05:19
気持ち悪いとか爆笑とか、感性や感情を吐露されても
具体的なXMLとの関係はさっぱりわからん。
なぜ気持ち悪いのか、なぜ爆笑するのか、そこを掘り下げろよ。
具体的なXMLとの関係はさっぱりわからん。
なぜ気持ち悪いのか、なぜ爆笑するのか、そこを掘り下げろよ。
2008/11/30(日) 23:35:29
<dig>そこ掘れワンワン</dig>
61デフォルトの名無しさん
2008/12/01(月) 16:01:45 参考になるかどうか分からないけど、かつてTed NelsonはHTMLでは
次のような記法が出来ないから嫌いだと言ったとか何とか。
HTML is <U>precisely <B>what</U> we were trying to PREVENT.</B>
最近のブラウザでは上記例も無理矢理表示するかも知れないけど、
HTML規格に合わせるなら未だに次の記法でないとダメだと思う。
HTML is <U>precisely <B>what</B></U><B> we were trying to PREVENT.</B>
つまり、彼のクレームは「何故フォントスタイル指定は入れ子構造を
強制されるのか」と言うこと。
赤ボールペンと蛍光マーカーを使って文書に線を入れる作業をする
例を考えると、赤線や蛍光マークは入れ子など考えずに好きな場所
に入れて好きなようにオーバーラップ出来るよね。
(上の例で言えばpreciselyからwhatまでピーッと赤アンダーラインを
引いて、whatからPREVENTまで蛍光マーカーでなぞる)
これと比べればHTMLやXMLの「要素の入れ子構造」はいささかか
不自然さを文書作成者に強制している、といえなくもない。
もちろんTed NelsonがHTMLに対して述べたクレームはこれだけじゃ
ないし、彼の主張が全てと言うわけでもないけど、HTMLやXMLには
文書を表現する上では不自然さも持っている、完璧ではないという
意見も存在すると言うことで。
XMLを用いて修飾された文書からDOMを作ると確かに元の文書が
ブツ切りのTextNodeとして出てくるので、個人的には>>51のいう
「気持ち悪い」感覚は何となく理解できます。
次のような記法が出来ないから嫌いだと言ったとか何とか。
HTML is <U>precisely <B>what</U> we were trying to PREVENT.</B>
最近のブラウザでは上記例も無理矢理表示するかも知れないけど、
HTML規格に合わせるなら未だに次の記法でないとダメだと思う。
HTML is <U>precisely <B>what</B></U><B> we were trying to PREVENT.</B>
つまり、彼のクレームは「何故フォントスタイル指定は入れ子構造を
強制されるのか」と言うこと。
赤ボールペンと蛍光マーカーを使って文書に線を入れる作業をする
例を考えると、赤線や蛍光マークは入れ子など考えずに好きな場所
に入れて好きなようにオーバーラップ出来るよね。
(上の例で言えばpreciselyからwhatまでピーッと赤アンダーラインを
引いて、whatからPREVENTまで蛍光マーカーでなぞる)
これと比べればHTMLやXMLの「要素の入れ子構造」はいささかか
不自然さを文書作成者に強制している、といえなくもない。
もちろんTed NelsonがHTMLに対して述べたクレームはこれだけじゃ
ないし、彼の主張が全てと言うわけでもないけど、HTMLやXMLには
文書を表現する上では不自然さも持っている、完璧ではないという
意見も存在すると言うことで。
XMLを用いて修飾された文書からDOMを作ると確かに元の文書が
ブツ切りのTextNodeとして出てくるので、個人的には>>51のいう
「気持ち悪い」感覚は何となく理解できます。
2008/12/01(月) 16:17:42
プログラマとそうでない人、両方の視点が必要というわけか
非プログラマからは文書を表現しにくいと言われ
かといってプログラマからはJSONで十分じゃんと言われ
・・・でもそんなXMLが大好きです(AA略
非プログラマからは文書を表現しにくいと言われ
かといってプログラマからはJSONで十分じゃんと言われ
・・・でもそんなXMLが大好きです(AA略
2008/12/01(月) 16:33:09
そういわれてみて気づいたが、俺は
HTML は文章の一部をマークアップするためのもの、
XML はデータをツリー構造で表現するためのもの、
として捉えていたようだ。
文章の一部をマークアップするということが本来的に
マークアップがきれいな入れ子構造を持つことを要請するわけじゃないよね。
そう考えるとたしかに言葉通りの「マークアップランゲージ」の仕様としては「要素の入れ子構造」は無理な部分もあるのかも。
そもそもなぜ「要素の入れ子構造」は要請されたのかね?
HTML は文章の一部をマークアップするためのもの、
XML はデータをツリー構造で表現するためのもの、
として捉えていたようだ。
文章の一部をマークアップするということが本来的に
マークアップがきれいな入れ子構造を持つことを要請するわけじゃないよね。
そう考えるとたしかに言葉通りの「マークアップランゲージ」の仕様としては「要素の入れ子構造」は無理な部分もあるのかも。
そもそもなぜ「要素の入れ子構造」は要請されたのかね?
2008/12/01(月) 16:40:35
入れ子だとXMLパーサを作りやすいからだろう。
実装の手間とインタフェースの使いやすさのバランスを取った結果が
こういう仕様になったんだと思う。
実装の手間とインタフェースの使いやすさのバランスを取った結果が
こういう仕様になったんだと思う。
2008/12/01(月) 16:50:37
なるほど、やはりプログラムでの処理からの要請か…。ありがとう。
たしかにプログラムで処理するためのマークアップだもんね。
たしかにプログラムで処理するためのマークアップだもんね。
2008/12/01(月) 16:54:33
6764
2008/12/01(月) 17:32:33 > つ SAX
ああその通り。失礼しました。
入れ子ならDOMパーサを作りやすい、なら問題ないかな。
> しかし今度はパーサを使うプログラマが苦労するという罠。
要素のオーバーラップしたXMLをSAXパーサに食わせて
プログラマ側が構造化するとか、考えただけでクラクラする。
ああその通り。失礼しました。
入れ子ならDOMパーサを作りやすい、なら問題ないかな。
> しかし今度はパーサを使うプログラマが苦労するという罠。
要素のオーバーラップしたXMLをSAXパーサに食わせて
プログラマ側が構造化するとか、考えただけでクラクラする。
2008/12/01(月) 17:50:46
人間が直接パーサを作るなんてひどい拷問だ
自動生成させようよ
機械的に扱わせやすいための入れ子構造なんだし
処理そのものだけでなく処理をさせるものの生成にも構造が簡易なのが効いてくる
自動生成させようよ
機械的に扱わせやすいための入れ子構造なんだし
処理そのものだけでなく処理をさせるものの生成にも構造が簡易なのが効いてくる
2008/12/01(月) 22:55:53
盛り上がってきたな
2008/12/02(火) 01:10:18
SGMLパーサーの実装が不可能に近かったのでxmlを作りましたとさって経緯もあるからなぁ
71デフォルトの名無しさん
2008/12/02(火) 22:28:48 XSLTで、<xsl:template match="processing-instruction('xml')">
というテンプレートを見かけたんだけど、これってマッチすることあるの?
というテンプレートを見かけたんだけど、これってマッチすることあるの?
2008/12/03(水) 01:13:39
2008/12/03(水) 01:50:00
XMLって何て読むんですか?
2008/12/03(水) 02:05:35
シャマル
2008/12/03(水) 20:07:26
命題1:XMLはデータをツリー構造で表現するデータ形式である
命題2:XMLはあらゆるデータ構造の表現に用いられている
命題3:世の中に存在するデータ構造はツリー構造のみではない
というわけで質問なんだけど、
1. XMLのデータ表現にツリー構造が採用されたのはなぜ?
2. XMLと相性の良い、あるいは悪いデータ構造って例えばどういうの?
命題2:XMLはあらゆるデータ構造の表現に用いられている
命題3:世の中に存在するデータ構造はツリー構造のみではない
というわけで質問なんだけど、
1. XMLのデータ表現にツリー構造が採用されたのはなぜ?
2. XMLと相性の良い、あるいは悪いデータ構造って例えばどういうの?
2008/12/03(水) 20:13:05
その命題の真偽は?
2008/12/03(水) 20:26:26
まず、命題1は偽だな
2008/12/03(水) 21:43:13
安易に全称を使わないで欲しい
2008/12/03(水) 22:01:04
命題1と命題2のどちらかが偽だな
1. XMLのデータ表現にツリー構造が採用されたのはなぜ?
括弧の入れ子構造は自然にツリーになるから
(() ((()) ())))
2. XMLと相性の良い、あるいは悪いデータ構造って例えばどういうの?
相性が悪いのはグラフ(任意の矢印でつなげた構造)
-------
+→| | |
| +--|--+
+-----+
みたいな自分自身を指す構造とか。
1. XMLのデータ表現にツリー構造が採用されたのはなぜ?
括弧の入れ子構造は自然にツリーになるから
(() ((()) ())))
2. XMLと相性の良い、あるいは悪いデータ構造って例えばどういうの?
相性が悪いのはグラフ(任意の矢印でつなげた構造)
-------
+→| | |
| +--|--+
+-----+
みたいな自分自身を指す構造とか。
2008/12/03(水) 22:16:27
2008/12/03(水) 22:24:57
S式と1対1に対応できるから可能
2008/12/03(水) 22:54:47
何も悩まず
<lambda arg="x"><lambda arg="y">
<add><value expr="x"/><value expr="y"/></add>
</lambda></lambda>
でいいじゃん。
<lambda arg="x"><lambda arg="y">
<add><value expr="x"/><value expr="y"/></add>
</lambda></lambda>
でいいじゃん。
2008/12/03(水) 23:03:26
大抵のデータ構造は二項関係の集合にバらして表現できるから
大概のデータはその気になればXMLで「書ける」はずです。
ただ本当にバラバラ事件になるので、機械可読だけど人間様は
読みたくないXML文書になることは請け合いです。
「相性」にも広い意味がありますが元のデータ構造をバらさない
ままXMLの構造に対応づけることが出来るか、という意味では
やはり相性の良いデータは「木」に見立てることが出来るもの
に限られると思います。
ちなみに先日の下線とアンダーラインの例も次のように書けば
入れ子もオーバーラップも気にせずにXMLで表現できます。
<decoratedText>
<text>HTML is precisely what we were trying to PREVENT.</text>
<underline start="9" end="22"/>
<bold start="19" end="48"/>
...
</decoratedText>
確かTed NelsonのHyperTextにおけるHyperLinkの定義もこんな
アプローチ(参照元と参照先の開始点と終了点)だったと記憶して
います。ただ、手書きでは絶対に書きたくないな、これ。
大概のデータはその気になればXMLで「書ける」はずです。
ただ本当にバラバラ事件になるので、機械可読だけど人間様は
読みたくないXML文書になることは請け合いです。
「相性」にも広い意味がありますが元のデータ構造をバらさない
ままXMLの構造に対応づけることが出来るか、という意味では
やはり相性の良いデータは「木」に見立てることが出来るもの
に限られると思います。
ちなみに先日の下線とアンダーラインの例も次のように書けば
入れ子もオーバーラップも気にせずにXMLで表現できます。
<decoratedText>
<text>HTML is precisely what we were trying to PREVENT.</text>
<underline start="9" end="22"/>
<bold start="19" end="48"/>
...
</decoratedText>
確かTed NelsonのHyperTextにおけるHyperLinkの定義もこんな
アプローチ(参照元と参照先の開始点と終了点)だったと記憶して
います。ただ、手書きでは絶対に書きたくないな、これ。
2008/12/04(木) 01:02:30
XSLTがチューリング完全だからそれで変換すればなんでもありじゃね?
2008/12/04(木) 01:19:43
XSLTは "Sun, 28 ほにゃらら +0900(JST)" みたいな日付の書き方とかを始めとした
色んなデータ表現形式をサポートしてくれないとちょっと使いにくい。
JavaScriptでStringを引数としたString戻り値の関数を定義できる機能とかないのかね。
色んなデータ表現形式をサポートしてくれないとちょっと使いにくい。
JavaScriptでStringを引数としたString戻り値の関数を定義できる機能とかないのかね。
2008/12/04(木) 02:16:00
暇つぶしに論文漁ったらこんなのが。
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108.9959&rep=rep1&type=pdf
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/NH.html
Overlap(上記の下線と太線の例の様なケース)をどのようにSGMLや
XMLで表現するか、「技」の事例が揃ってます。
いや、苦労しているなぁ、皆さん(笑)。
個人的には次のようなアプローチが一番面白かった。
HTML is <U_start/>precisely <B_start/>what<U_end/> we were trying to PREVENT.<B_end/>
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108.9959&rep=rep1&type=pdf
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/NH.html
Overlap(上記の下線と太線の例の様なケース)をどのようにSGMLや
XMLで表現するか、「技」の事例が揃ってます。
いや、苦労しているなぁ、皆さん(笑)。
個人的には次のようなアプローチが一番面白かった。
HTML is <U_start/>precisely <B_start/>what<U_end/> we were trying to PREVENT.<B_end/>
2008/12/04(木) 02:30:40
もはや要素の概念が・・・
2008/12/04(木) 02:33:59
>>86
rtfとかこんなんだよね。
rtfとかこんなんだよね。
2008/12/04(木) 02:39:23
昔のワープロデータの保存形式は、こんなのが多かった気がする。
HTML is <U length="14"/>precisely <B length="25"/>what we were trying to PREVENT.
HTML is <U length="14"/>precisely <B length="25"/>what we were trying to PREVENT.
2008/12/04(木) 02:45:59
>>88
RTFはHTMLと一緒だよ。
RTFはHTMLと一緒だよ。
2008/12/04(木) 08:10:13
2008/12/04(木) 08:14:51
あと、>>79について、完全に歴史の話だと思うけど、
> 括弧の入れ子構造は自然にツリーになるから
というのは、XML仕様の作成者の意図は、「括弧の入れ子構造」を使った
データフォーマットを作ることが先にあって、ツリーになったのは結果論という認識でいい?
> 括弧の入れ子構造は自然にツリーになるから
というのは、XML仕様の作成者の意図は、「括弧の入れ子構造」を使った
データフォーマットを作ることが先にあって、ツリーになったのは結果論という認識でいい?
93デフォルトの名無しさん
2008/12/04(木) 17:13:22 INIファイルをXMLファイルに変換する方法を教えてください
2008/12/04(木) 17:52:51
2008/12/04(木) 19:57:35
鬼才現る
96デフォルトの名無しさん
2008/12/04(木) 20:59:50 >>94
できなかったです+_+
できなかったです+_+
2008/12/04(木) 22:07:50
【サンタクロース、トナカイの酒気帯び運用で逮捕。有罪判決に、マジ逆切れ&大暴れw(動画有り)】(ZDNet)
http://builder.japan.zdnet.com/story_media/20384793/081204_sun-james-gosling_03_400x300.jpg
http://builder.japan.zdnet.com/story_media/20384793/081204_sun-james-gosling_01_400x300.jpg
http://builder.japan.zdnet.com/story_media/20384793/081204_sun-james-gosling_02_400x300.jpg
2008/12/08(月) 16:04:44
hoge要素に対するhoe要素、hogehoge要素に対するhoehoe要素が
別のXML文書(hoe.xml)内にあるものとして、
そこへそれぞれにリンクを設定する必要がある時、
<root>
<hoge xml:base="hoe.xml#xpointer(hoe[1])">
<hogehoge xlink:href="#xpointer(hoe[1]/hoehoe[1])" />
</hoge>
</root>
"hoe[1]"を2回書くの嫌なんですが、こう書かなきゃだめ?
xml:baseはXPath部分は含んでくれない?
別のXML文書(hoe.xml)内にあるものとして、
そこへそれぞれにリンクを設定する必要がある時、
<root>
<hoge xml:base="hoe.xml#xpointer(hoe[1])">
<hogehoge xlink:href="#xpointer(hoe[1]/hoehoe[1])" />
</hoge>
</root>
"hoe[1]"を2回書くの嫌なんですが、こう書かなきゃだめ?
xml:baseはXPath部分は含んでくれない?
2008/12/19(金) 07:35:14
画像処理の実験データを記録するのに、勉強がてらxmlを使うことにしたのですが
例えば、目標位置を記録する場合の要素Targetがあったとして
例@
<Target num="0" x="315" y="292">
例A
<Target>
<Num>0</Num>
<X>315</X>
<Y>292</Y>
</Target>
この二通りを考えたとき、どちらの書き方が『正しい』と言えるのでしょうか。
自分はどちらでもいいのではと思っており、例@を採用していたのですが、報告会で先輩から
「そういう属性だけの要素が存在してもいいの?」や「そういうのを書くとき、一般的な決まりごととか無いの?」などの
質問を受けました。考えたことも無かったので調べてはみたのですが
これといった答えが見つからず、質問に参った次第です。
好みの問題なのでしょうか。それとも、何か決まりごとのようなものがあるのでしょうか。
参考になるwebサイトなどでも構いません。知っている方がおりましたら、どうかご教授ください。
例えば、目標位置を記録する場合の要素Targetがあったとして
例@
<Target num="0" x="315" y="292">
例A
<Target>
<Num>0</Num>
<X>315</X>
<Y>292</Y>
</Target>
この二通りを考えたとき、どちらの書き方が『正しい』と言えるのでしょうか。
自分はどちらでもいいのではと思っており、例@を採用していたのですが、報告会で先輩から
「そういう属性だけの要素が存在してもいいの?」や「そういうのを書くとき、一般的な決まりごととか無いの?」などの
質問を受けました。考えたことも無かったので調べてはみたのですが
これといった答えが見つからず、質問に参った次第です。
好みの問題なのでしょうか。それとも、何か決まりごとのようなものがあるのでしょうか。
参考になるwebサイトなどでも構いません。知っている方がおりましたら、どうかご教授ください。
100デフォルトの名無しさん
2008/12/19(金) 08:00:22 ないからどういう風に書くかスキーマを書いて決める。
101デフォルトの名無しさん
2008/12/19(金) 08:03:10 特に num や x が二つ以上あれば属性ではなく要素を選択するしかないけど、
構造体やハッシュ/辞書みたいなデータ構造を XML に落とす場合は
どっちでもいいと思うよ
ちなみに XML Hacks って本が言うには
要素にするか属性にするかは論争の種ではあるけれど
相互変換が可能なのでお好みでどうぞというのが結論だった気がする
構造体やハッシュ/辞書みたいなデータ構造を XML に落とす場合は
どっちでもいいと思うよ
ちなみに XML Hacks って本が言うには
要素にするか属性にするかは論争の種ではあるけれど
相互変換が可能なのでお好みでどうぞというのが結論だった気がする
102デフォルトの名無しさん
2008/12/19(金) 08:33:30 num や x が2つ以上あっても例えば空白区切りで書けるけど。
103デフォルトの名無しさん
2008/12/19(金) 08:48:40104デフォルトの名無しさん
2008/12/19(金) 11:01:45 属性にできるなら属性にしたほうがコードは書き易い印象がある。
105デフォルトの名無しさん
2008/12/19(金) 15:17:13 >>104
DOMにしてもSAXにしても確かに属性にした方が楽ですね。
DOMにしてもSAXにしても確かに属性にした方が楽ですね。
106デフォルトの名無しさん
2008/12/20(土) 00:33:05 >>103
<svg:path d="M 0 0 L 0 100 100 100 100 0 0 0" />
<svg:path d="M 0 0 L 0 100 100 100 100 0 0 0" />
107デフォルトの名無しさん
2008/12/20(土) 03:37:06 >>99
「XML 要素 属性 使い分け」でググるといくつか出てくるから参考にするとよろし
「XML 要素 属性 使い分け」でググるといくつか出てくるから参考にするとよろし
108デフォルトの名無しさん
2008/12/25(木) 02:19:56 xsltで質問です。
xmlをxslでhtmlにしたいのですが、
できるhtmlに文書型宣言を入れることはできるのでしょうか。
よろしくお願いします。
xmlをxslでhtmlにしたいのですが、
できるhtmlに文書型宣言を入れることはできるのでしょうか。
よろしくお願いします。
109デフォルトの名無しさん
2008/12/25(木) 02:23:54110デフォルトの名無しさん
2008/12/25(木) 02:37:16111デフォルトの名無しさん
2008/12/27(土) 14:29:33 自分のホームページの資料的コンテンツのところをXML&XSLTにしようと思って勉強しはじめました。
友人に貰った何年も前の「10日で覚えるXML入門」とかいうの本を見てるんですが、いまいち分かりにくいので、他の入門書があったら教えて貰えませんか?
分けあって今PCがネットに繋げられない状況なので、ぐぐれってのは無しでお願いします(^_^;)
友人に貰った何年も前の「10日で覚えるXML入門」とかいうの本を見てるんですが、いまいち分かりにくいので、他の入門書があったら教えて貰えませんか?
分けあって今PCがネットに繋げられない状況なので、ぐぐれってのは無しでお願いします(^_^;)
112デフォルトの名無しさん
2008/12/27(土) 15:13:39 どっちかというとXSLTの本を買うべきなんじゃないかという気がするけど、
俺は全然わからないのでえろい人たのむ
俺は全然わからないのでえろい人たのむ
113デフォルトの名無しさん
2008/12/27(土) 15:23:01 Webになっちゃうけど「万葉の想い」には時々お世話になります。
とても説明が丁寧なので大変助けられます。
同僚が近くにいるときには微妙に利用しにくいのが何ですが(笑)。
とても説明が丁寧なので大変助けられます。
同僚が近くにいるときには微妙に利用しにくいのが何ですが(笑)。
114デフォルトの名無しさん
2008/12/27(土) 19:16:44 >>113
Webは見たこと無いけど、書籍( ttp://www.amazon.co.jp/dp/4881662201/ )はよかったな
Webは見たこと無いけど、書籍( ttp://www.amazon.co.jp/dp/4881662201/ )はよかったな
115デフォルトの名無しさん
2008/12/27(土) 20:01:03 とりあえずオライリーいっとけ
116デフォルトの名無しさん
2008/12/28(日) 11:30:54117デフォルトの名無しさん
2008/12/28(日) 14:00:00 なし。
ブラウザ実装のXSLTトランスフォーマは屑だらけな上、互換性ないから。
そういうことしたいならphpとかjspとかそっち系。
ブラウザ実装のXSLTトランスフォーマは屑だらけな上、互換性ないから。
そういうことしたいならphpとかjspとかそっち系。
118デフォルトの名無しさん
2008/12/28(日) 17:20:33 標準準拠してない処理系を切り捨てる気があるなら十分アリ。
119デフォルトの名無しさん
2008/12/28(日) 17:30:58 挑戦してみて一度挫折してみるのも技術の可能性と限界、適切な適用領域
を理解するために良いかも。
以前「元データのXMLをこのXSLTで変換すると、こ〜んなインタラクティブ
なHTMLページに!」なんてものを紹介された事があって、その実装の詳細
をみて驚愕した事がある。
それはまさにJavaScriptコードを生成するXSLT。HTML要素を出力する
templateの記述はほんの数行で、あとはJavaScript変数に値を代入する
templateやJavaScript関数を実行するtemplateが延々と続く。
これでXMLデータを変換すると殆ど空っぽのHTML文書に巨大JavaScript
プログラムが埋め込まれたものを生成。
で、具体的なHTML文書中の表示要素の生成やインタラクティブ云々は
全てJavaScriptプログラム側に丸投げされているという、そういう代物。
で、見て関心しているだけだったら良かったのだけど、そのXSLTのデバッグ
を仕事に振られて・・・(´Д⊂
を理解するために良いかも。
以前「元データのXMLをこのXSLTで変換すると、こ〜んなインタラクティブ
なHTMLページに!」なんてものを紹介された事があって、その実装の詳細
をみて驚愕した事がある。
それはまさにJavaScriptコードを生成するXSLT。HTML要素を出力する
templateの記述はほんの数行で、あとはJavaScript変数に値を代入する
templateやJavaScript関数を実行するtemplateが延々と続く。
これでXMLデータを変換すると殆ど空っぽのHTML文書に巨大JavaScript
プログラムが埋め込まれたものを生成。
で、具体的なHTML文書中の表示要素の生成やインタラクティブ云々は
全てJavaScriptプログラム側に丸投げされているという、そういう代物。
で、見て関心しているだけだったら良かったのだけど、そのXSLTのデバッグ
を仕事に振られて・・・(´Д⊂
120デフォルトの名無しさん
2008/12/28(日) 17:40:32 ろくにクロスブラウザされてなくて動作チェックに苦労したと・・・。
121デフォルトの名無しさん
2008/12/28(日) 17:43:46 クロスブラウザとかライブラリ側でやってくれてないと死ねるな。
122デフォルトの名無しさん
2008/12/28(日) 18:19:33 クロスブラウザも苦労しましたが、一番死ねたのがXSLTとJavaScriptが
素晴らしくフュージョンしてコンバインしていた点です。
XSLTのtemplateとしてJavaScriptの関数宣言が記述されていて、その
関数定義中の所々にまたXSLTのapply-templatesやfor-eachが記述
されている。
で、変換するXMLデータに応じて新しい関数を動的にバキバキ宣言して、
そのロジックをニョキニョキと自動生成するのです。
その技術ロマンは理解出来ないわけでもありません。ですが、
・変換対象のXMLデータに応じて、毎回JavaScript関数の内容が変化(涙)
・JavaScriptのデバッグをするのに、書き換えるのはXSLT、そのもどかしさ
・・・最終的にはXMLデータをJSON風のJavaScript Objectの配列に変換
するところだけにXSLTは用いて、「静的な」JavaScriptプログラムとして
ロジックを一から書き直して放り込んで始末しました。
プログラムの世界には、時々「混ぜては危険」なものもあると実感しました。
素晴らしくフュージョンしてコンバインしていた点です。
XSLTのtemplateとしてJavaScriptの関数宣言が記述されていて、その
関数定義中の所々にまたXSLTのapply-templatesやfor-eachが記述
されている。
で、変換するXMLデータに応じて新しい関数を動的にバキバキ宣言して、
そのロジックをニョキニョキと自動生成するのです。
その技術ロマンは理解出来ないわけでもありません。ですが、
・変換対象のXMLデータに応じて、毎回JavaScript関数の内容が変化(涙)
・JavaScriptのデバッグをするのに、書き換えるのはXSLT、そのもどかしさ
・・・最終的にはXMLデータをJSON風のJavaScript Objectの配列に変換
するところだけにXSLTは用いて、「静的な」JavaScriptプログラムとして
ロジックを一から書き直して放り込んで始末しました。
プログラムの世界には、時々「混ぜては危険」なものもあると実感しました。
123デフォルトの名無しさん
2008/12/28(日) 18:36:18 >関数定義中の所々にまたXSLTのapply-templatesやfor-eachが記述
されている。
>
>で、変換するXMLデータに応じて新しい関数を動的にバキバキ宣言して、
>そのロジックをニョキニョキと自動生成するのです。
さすがチューリング完全のXSLT・・・と言いたいが、
そういうのは実行中にオブジェクトのプロパティに関数突っ込むのがプロトタイプベースOOPの流儀なんだが。
ろくにjavascript触れないPGの苦肉の策にしか見えない。
てかHTML+DOMだけでできる気がする。
されている。
>
>で、変換するXMLデータに応じて新しい関数を動的にバキバキ宣言して、
>そのロジックをニョキニョキと自動生成するのです。
さすがチューリング完全のXSLT・・・と言いたいが、
そういうのは実行中にオブジェクトのプロパティに関数突っ込むのがプロトタイプベースOOPの流儀なんだが。
ろくにjavascript触れないPGの苦肉の策にしか見えない。
てかHTML+DOMだけでできる気がする。
124デフォルトの名無しさん
2008/12/28(日) 18:40:59 言語のコンパイラひとつ丸ごとデバッグしろっていうのに等しいなw
125デフォルトの名無しさん
2008/12/28(日) 19:06:30 実際、言語コンバータ一つ丸ごとデバッグしてるので間違ってないな。
126デフォルトの名無しさん
2008/12/28(日) 19:08:25 >>123
元々はSVGによるグラフをXSLTを使って生成する事が目的だった様です。
ところがSVGの代わりにFlashのグラフコンポーネントを使う事になって、
そのFlashではパラメーターをJavaScriptで渡す必要があった。
で、「よ〜しJavaScriptコードもXSLTで生成しちゃうぞ〜」となった様です。
やがてXSLTを用いたJavaScriptコードの生成技術にもますます磨きが
かかり、関数宣言やロジック実装までXSLTでバキバキ行うように。
いや動く、確かに動くんです。デバッグの手間や拡張さえ考えなければ。
技術の無駄遣いというか、どこで磨き方の方向を誤ったのやら・・・
>>124
いや、まさにそんな感じです。プログラムだけではなくコンパイラの面倒も
見なくちゃいけない、そんな感じでした。
元々はSVGによるグラフをXSLTを使って生成する事が目的だった様です。
ところがSVGの代わりにFlashのグラフコンポーネントを使う事になって、
そのFlashではパラメーターをJavaScriptで渡す必要があった。
で、「よ〜しJavaScriptコードもXSLTで生成しちゃうぞ〜」となった様です。
やがてXSLTを用いたJavaScriptコードの生成技術にもますます磨きが
かかり、関数宣言やロジック実装までXSLTでバキバキ行うように。
いや動く、確かに動くんです。デバッグの手間や拡張さえ考えなければ。
技術の無駄遣いというか、どこで磨き方の方向を誤ったのやら・・・
>>124
いや、まさにそんな感じです。プログラムだけではなくコンパイラの面倒も
見なくちゃいけない、そんな感じでした。
127デフォルトの名無しさん
2008/12/29(月) 00:47:44 俺はPHPでXSLTでXML整形してかきだすWikiみたいの作ってるけど
未実装関数とか多いわ挙動おかしいわで苦労することだけは伝えておこう。
あとhtml5で書こうとしてXSLTからはDOCTYPE生成できないとか、
妙に新しいことやるのもダメポ。
未実装関数とか多いわ挙動おかしいわで苦労することだけは伝えておこう。
あとhtml5で書こうとしてXSLTからはDOCTYPE生成できないとか、
妙に新しいことやるのもダメポ。
128デフォルトの名無しさん
2008/12/29(月) 01:11:45 >>127
DOCTYPE が生成できないとか嘘だろ。
DOCTYPE が生成できないとか嘘だろ。
129デフォルトの名無しさん
2008/12/29(月) 23:22:05130デフォルトの名無しさん
2008/12/30(火) 17:59:51 xml好きの俺が仕事納めに一言申します
php, jsp, aspとかのソース見てると罪悪感
嫌悪感を感じます
<e name="<%= value %>" />
なんか、いや、もうっやめてあげてえーー
php, jsp, aspとかのソース見てると罪悪感
嫌悪感を感じます
<e name="<%= value %>" />
なんか、いや、もうっやめてあげてえーー
131デフォルトの名無しさん
2008/12/30(火) 18:23:09 こういうXMLに変数値を埋め込む方法は悩ましいですねぇ。
E4Xではどうでしょう(以下はActionScript3の例)。
var value:String ="Foo bar"
var xml:XML = <e name={value} />
二重引用符が必要無いのが素敵。
E4Xではどうでしょう(以下はActionScript3の例)。
var value:String ="Foo bar"
var xml:XML = <e name={value} />
二重引用符が必要無いのが素敵。
132デフォルトの名無しさん
2008/12/30(火) 18:43:15 hamlとか割といいと思いますヨ
133デフォルトの名無しさん
2008/12/30(火) 21:40:53 普通にDOMで吐き出してるなあ
134デフォルトの名無しさん
2009/01/18(日) 23:24:09 亀だが、JSPならXML構文使えば?
数値文字参照とかELとかでいくらでも解消できるだろ。
数値文字参照とかELとかでいくらでも解消できるだろ。
135デフォルトの名無しさん
2009/01/20(火) 11:01:04 データをCSVからXMLに移行しようと思ったのですが、本が古くて今でも通用するのか心配です。
XMLでデータを作成して、XSLTでIEに表示させるようにするのが主流であってますか?
CSSという奴はどういう位置付けなんでしょうか?
XMLでデータを作成して、XSLTでIEに表示させるようにするのが主流であってますか?
CSSという奴はどういう位置付けなんでしょうか?
136デフォルトの名無しさん
2009/01/20(火) 11:01:41 すいません上げさせてください。
137デフォルトの名無しさん
2009/01/20(火) 11:47:45 >>135
XML で作成したデータを XSLT で変換するのは
IE じゃなくて Java とかのプログラムを使うのが普通かと。
ユーザーが全員 IE を使ってるわけではないし
全てのブラウザが正しく XSLT に対応しているわけでもない。
自分だけで使うなら IE でも全然かまわないが。
XSLT が文書構造(スタイル)を決定するのに対して
CSS は見た目(スタイル)を決める。
例えばデータを XSLT で表構造に変換して CSS で表に枠を付けるみたいに。
XML で作成したデータを XSLT で変換するのは
IE じゃなくて Java とかのプログラムを使うのが普通かと。
ユーザーが全員 IE を使ってるわけではないし
全てのブラウザが正しく XSLT に対応しているわけでもない。
自分だけで使うなら IE でも全然かまわないが。
XSLT が文書構造(スタイル)を決定するのに対して
CSS は見た目(スタイル)を決める。
例えばデータを XSLT で表構造に変換して CSS で表に枠を付けるみたいに。
138デフォルトの名無しさん
2009/01/20(火) 12:26:50 Java入れるくらいならそのページは見ない。
IE使ってる人 > そのページを見るためにJava入れてもいい人
この式が成り立つなら、IE対応で良いのでは?
サーバーサイドに関してはどうでもいいと思いますね。
IE使ってる人 > そのページを見るためにJava入れてもいい人
この式が成り立つなら、IE対応で良いのでは?
サーバーサイドに関してはどうでもいいと思いますね。
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【日本人の旅行離れ】国内旅行すら行けなくなった……オーバーツーリズムだけじゃない 旅行者減少の異常事態 [ぐれ★]
- 高市首相の答弁書に「台湾有事答えない」と明記 存立危機発言当時 ★12 [蚤の市★]
- 中国の渡航自粛要請1カ月 大阪の観光バス予約ゼロ、東北にも波及 [蚤の市★]
- 【神戸】エレベーター「かご」なく男性医師が転落死 大手「三菱電機ビルソリューションズ」の担当者、安全装置切り放置か [ぐれ★]
- 【福岡】「人が道路に寝込んでいた。顔面から出血し、うなり声をあげている」 福岡市中央区で男性はねられ死亡 タクシー運転手逮捕 [ぐれ★]
- 女性天皇「賛成」69%、将来の皇位継承「不安」68%…読売世論調査 [蚤の市★]
- 高市、メガソーラー廃止。環境破壊が社会問題化 [792147417]
- クリスマスに何かする「予定なし」は54%。 過去最高水準に。ケーキの値上げもあって節約志向へ [663766621]
- 他人のリクエストで自分の癖と異なる絵を上げる絵師いるじゃん?
- 🏡おい!返事しろ︎︎!知的障害者!
- 日本人がホルホルの対象にしている生物、海外にも生息すると判明 [603416639]
- キミプリ→ゼッツ→ゴジュウ→猥談
