タグ付けされた質問 「xml」

eXtensible Markup Languageを表すシンプルで非常に柔軟なテキスト形式で、データの交換、共有、保存に使用できます。コンピューターで簡単に解析できますが、プログラマーでも読み取り可能です。このタグは、XMLの使用に関するトピックに関連する質問に使用します。


5
XSLTおよび可能な代替案[終了]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 1つのXMLファイルを別のXMLファイル(HTMLなど)に変換するためのXSLTを見てきました。XSLT(標準化されて使用されているツールである)には利点があることがわかりましたが、いくつかの理由で消極的です XSLTプロセッサは非常に巨大であると思われる/リソースを大量に消費する XMLはプログラミングにとって悪い表記法であり、それがXSLTのすべてです。 ここでXSLTをトロールしたくないのですが、私はそれについて嫌いなものを指摘したいだけで、私は代替手段に期待することのアイデアをあなたに提供します。 Lispのバックグラウンドがあるので、Lispに基づいたツリー構造変換のより良い方法があるかどうか疑問に思います。DSSSLへの参照を見てきましたが、残念ながらDSSSLに関するほとんどのリンクは死んでいるので、それを説明するコードを見るのはすでに困難です。DSSSLはまだ使用中ですか?docbookをチェックアウトするときに一度openjadeをインストールしたことを覚えています。 Jeff Atwoodのブログ投稿は、XSLTの代わりにRubyを使用することを示唆しているようです。 非XMLプログラミング言語でXSLTに似たXML変換を行うための適切な方法はありますか?私は上の入力のために開いているだろう XML変換を容易にするスクリプト言語に役立つライブラリ 特に(ただし排他的ではない)Lispのような変換言語、またはRubyなど。 これまでに見つけたいくつかのこと: Webのいくつかの場所で、Linqが代替案として挙げられています。非常に一般的には、あらゆる種類の分類であり、XSLTの経験が最も豊富な人のものです。 スキームhttp://cs.brown.edu/~sk/Publications/Papers/Published/kk-sxslt/およびhttp://www.okmij.org/ftp/Scheme/xml.html
14 xml  lisp  linq  xslt 

3
Strategyパターンを使用したJavaの汎用ファイルパーサーデザイン
私は、モジュールの1つの責任がXMLファイルを解析し、データベースに必要なコンテンツをダンプすることである製品に取り組んでいます。現在の要件はXMLファイルの解析のみですが、将来、あらゆる種類のファイルをサポートできるように解析モジュールを設計したいと考えています。このアプローチの理由は、特定のクライアント向けにこの製品を構築しているが、近い将来に他のクライアントに販売する予定だからです。現在のクライアントのエコシステム内のすべてのシステムはXMLファイルを生成および消費しますが、他のクライアントの場合はそうではありません。 これまでに何を試しましたか?(現在) 戦略パターンに基づいた次の設計を念頭に置いています。私はすぐに日食でコードを書き留めてデザインを伝えたので、例外を適切に処理する方法などの他の側面が今のところ無視されるといいでしょう。 Parser:解析メソッドを公開する戦略インターフェイス。 public interface Parser<T> { public T parse(String inputFile); } *ジェネリックパラメーターを使用する理由は、すべての戻り値の型を許可し、コンパイル時に型の安全性を確保するためです。 ProductDataXmlParser製品関連情報を含むproduct.xmlファイルを解析するための具象クラス。(XMLBeanを使用) public class ProductDataXmlParser implements Parser<ProductDataTYPE> { public ProductDataTYPE parse(String inputFile) { ProductDataTYPE productDataDoc = null; File inputXMLFile = new File(inputFile); try { productDataDoc = ProductDataDocument.Factory.parse(inputXMLFile); } catch(XmlException e) { System.out.println("XmlException while parsing file : "+inputXMLFile); …
14 java  design  parsing  xml 

3
コードでExcel(xlsx)ファイルを生成するための良いデザインパターンは何ですか?
詳細については、下部の更新を参照してください。 Excelファイル(xlsx形式)としてデータを出力する必要があるプロジェクトがときどきあります。通常、プロセスは次のとおりです。 ユーザーが私のアプリケーションのいくつかのボタンをクリックする 私のコードはDBクエリを実行し、結果を何らかの方法で処理します 私のコードは、Excel com相互運用ライブラリまたはサードパーティライブラリ(Aspose.Cellsなど)を使用して* .xlsxファイルを生成します これをオンラインで行う方法のコード例を簡単に見つけることができますが、より堅牢な方法を探しています。私のコードがいくつかの設計原則に従って、私のコードが維持可能で簡単に理解できるようにしたいと思います。 xlsxファイルを生成する最初の試みは次のとおりです。 var wb = new Workbook(); var ws = wb.Worksheets[0]; ws.Cells[0, 0].Value = "Header"; ws.Cells[1, 0].Value = "Row 1"; ws.Cells[2, 0].Value = "Row 2"; ws.Cells[3, 0].Value = "Row 3"; wb.Save(path); 長所:それほど多くはありません。動作するので、それは良いことです。 短所: セル参照はハードコーディングされているため、コード全体にマジックナンバーが散らばっています。 多くのセル参照を更新せずに列と行を追加または削除することは困難です。 サードパーティのライブラリを学ぶ必要があります。一部のライブラリは他のライブラリと同様に使用されますが、それでも問題が発生する可能性があります。com interopライブラリが1ベースのセル参照を使用し、Aspose.Cellsが0ベースのセル参照を使用するという問題がありました。 上に挙げたいくつかの短所に対処する1つのソリューションを次に示します。データのテーブルを、セルの操作や他のセル参照を妨害することなく移動したり変更したりできる独自のオブジェクトとして扱いたいと思いました。擬似コードは次のとおりです。 var headers = new Block(new …

12
データストレージとしてのXMLの使用[終了]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私はXML形式と次の引用について考えていました。 「XMLはデータベースではありません。データベースになることを意図したものではありませんでした。データベースになることはありません。リレーショナルデータベースは、20年以上の実装経験を持つ実績のあるテクノロジーです。彼らは、固体、安定した、有用な製品です。彼らは去りません。XMLは、異なるデータベース間またはデータベースと他のプログラム間でデータを移動するための非常に便利なテクノロジーです。ただし、それ自体はデータベースではありません。いずれかのようにそれを使用しないでください「 - 。効果的なXML:50の具体的な方法をあなたのXMLを向上させることではElliotte Rusty Harold著(230ページ、パート4、項目41、第二段落) これは、XMLをデータストレージに使用すべきではなく、プログラム間の相互運用性にのみ使用すべきであることを本当に強調しているようです。 個人的にはapp.config、プログラムの設定を保存するために使用される.NETのファイルは、XMLファイルのデータストレージの例です。ただし、構成などではなくデータベースにはXMLを使用しないでください。 ポイントを開発するために、2つの例を使用します 。A)すべてが1レベルのフィールドを持つ顧客に関するデータ。つまり、子を持たない1人の顧客にすべて関連するいくつかのフィールド があります。とプロパティは非常に理にかなっています だから私の質問は、これはまだ有効なステートメントであり、XMLを使用してデータを保存することは現在受け入れられますか? 編集:私は彼の入力/追加のコンテキストを求めるためにその引用の著者にメールを送りました。

8
開発者にとってXMLはどれほど重要ですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 すべての開発者がXMLを知っている必要がありますか?開発者にとってXMLはどれほど重要ですか?なにか提案を...
12 xml 

3
S式(-ish)表記法に対するXMLの利点は何ですか?
XMLおよびS-expressions(-ish)表記法について質問したいと思います。S式はかなり古いです。また、それらは本当にシンプルです。意味が等しく、構文が異なる2つの形式を検討できます。 (ポーランド語のウィキペディアから取られたxmlコード) <?xml version="1.0" encoding="UTF-8"?> <ksiazka-telefoniczna kategoria="bohaterowie książek"> <!-- komentarz --> <osoba charakter="dobry"> <imie>Ambroży</imie> <nazwisko>Kleks</nazwisko> <telefon>123-456-789</telefon> </osoba> <osoba charakter="zły"> <imie>Alojzy</imie> <nazwisko>Bąbel</nazwisko> <telefon/> </osoba> </ksiazka-telefoniczna> S-Expression(-ish)バージョン: (:version "1.0" :encoding "utf-8") (ksiazka-telefoniczna :category "bohaterowie książek" ; komentarz(a comment) (osoba :charakter "dobry" (imie Ambroży) (nazwisko Kleks) (telefon 123-456-789)) (osoba :charakter "zły" (imie Alojzy) …
11 xml 

7
XMLを解析するためのテクニック
私は常にXMLの処理がやや面倒だと感じてきました。私はXMLパーサーの実装について話しているのではなく、ノードごとにXMLを処理するSAXパーサーのような既存のストリームベースのパーサーの使用について話しているのです。 はい、これらのパーサーのさまざまなAPIを学ぶのは非常に簡単ですが、XMLを処理するコードを見ると、常に多少複雑になることがわかります。本質的な問題は、XMLドキュメントが個々のノードに論理的に分離されているにもかかわらず、データの種類と属性が実際のデータから分離されていることが多いことです。したがって、特定のノードを個別に処理する場合、現在の場所と次に何をする必要があるかを判断するために、多くの余分な状態を維持する必要があります。 たとえば、典型的なXMLドキュメントからスニペットが与えられた場合: <book> <title>Blah blah</title> <author>Blah blah</author> <price>15 USD</price> </book> ...本のタイトルを含むテキストノードに出会ったとき、どのように判断しますか?イテレータのように動作し、を呼び出すたびにXMLドキュメントの次のノードを提供する単純なXMLパーサーがあるとしますXMLParser.getNextNode()。私は必然的に次のようなコードを書くことに気づきます。 boolean insideBookNode = false; boolean insideTitleNode = false; while (!XMLParser.finished()) { .... XMLNode n = XMLParser.getNextNode(); if (n.type() == XMLTextNode) { if (insideBookNode && insideTitleNode) { // We have a book title, so do something with it } …

4
サーバーでXMLを解析するか、プロキシを提供して、ブラウザで解析する必要がありますか?
サードパーティのAPIとのインターフェースが必要です。このAPIを使用して、エンドユーザーのブラウザー内からGET要求を作成し、XML応答を受信します。このデータは、ユーザーがデータを検索したり、決定に使用したりできるブラウザーベースのアプリケーションで使用されます。主な問題は、ほとんどのブラウザーがクロスドメインXMLの使用を制限しているため、単純に取得できないことです。 APIからのXML。 ただし、全体的なデータは基本的に2つのセットに分かれています。 最初のデータセットは公開されており、頻繁に更新する必要があるだけなので、サーバー側のすべてのユーザーがキャッシュできるため、トラフィックが大幅に軽減されます。 2番目のデータセットはプライベートであり、各ユーザーに個別です。このデータは、APIでもより頻繁に更新されます。これにより、キャッシュの効果が大幅に低下します。 スケーラビリティの理由から、サーバーの負荷をできるだけ小さくしたいと思います。 私の前に2つのオプションが表示されます。 XMLリクエストをサードパーティのサーバーにルーティングし、クライアントとサードパーティのAPIの間で直接やり取りするために使用できるプロキシを提供します。 サーバーにXMLからJSONへの変換を実行させ、不要な情報を削除します。これは基本的に、サーバー用の新しいAPIを作成することを意味します。これは、サードパーティAPIからのリクエストに変換されます ユーザーにデータを提供するための最良の方法は何ですか?(2つのオプションのいずれかである必要はありません)
11 javascript  api  xml  websites  json 

5
ストレージフォーマットをどのように決定するか、またそれらのいくつかの使用例は何ですか?
プログラムデータを保存する方法はいくつかあります(ゲーム、従業員データベース、プログラム構成などにファイルを保存します)。 プレーンテキスト(考える.iniと.conf) XML データベース(MySQL、SQLite ...) .zip および類似のいくつかのファイルを含む(異なる形式で) バイナリファイル(.docたとえば、シリアル化ツールによって作成されたものなど) 上記のフォーマットのさまざまな使用例は何ですか?それらの長所と短所の対比(速度、柔軟性、ファイルサイズ、使いやすさなどを考えてください)?異なるタスクのためにそれらをどのように決めるのですか? zip形式について:これは、他のファイルを格納するためだけに使用されます。別の圧縮形式の場合もあります。これにより、イメージファイル、サウンドファイル、テキストファイルなど、いくつかのファイルの構造が可能になります。例として、ファイルを含むメッセージの保存形式があるとします。次のファイルを圧縮ファイル内に含めることができます。 message.txt (containing the message) attachments (folder containing attachments) audio.wav picture.jpg

3
小規模なプロジェクトでのXMLとSQLの比較
ローカルアプリケーション(WPFおよびC#で開発)であるため、一度に1人のユーザーしか使用しない小さなプロジェクトに取り組んでいます。データを保存するには、XMLファイルを使用することを考えていましたが、これが最善の方法かどうか疑問に思っています。 データの目的: シェドル フォルダ内のファイルのライブラリ(アーティスト名、タイトル、HDD上の場所) おそらく、シェドゥルデータに基づく統計 ... ライブラリに関する情報は私が想像するXMLで十分でしょうが、残りのすべてについては私にはよくわかりません。また、LINQ to SQLは、LINQ to XMLよりも開発速度の点ではるかに収益性が高いようです。これは正しいですか、それとも間違っていますか?これをSOとここのどちらに投稿すればよいかわかりませんでしたが、こちらのほうが適切に思えました。 前もって感謝します
10 sql  wpf  xml 

6
xmlベースのプログラミング言語
私はウィキペディア-Category:XMLベースのプログラミング言語を見ていました。 言語を設計するために誰かがこのアプローチを取るのはなぜですか それの利点は何ですか? 私はデメリットしか考えられません。 維持するのが難しい 読みにくい 書くのが難しい

8
構成ファイルに推奨されるXML以外の何かを使用していますか?
ある種の構成ファイルを必要とする小さなツールを設計しています。私の場合、構成ファイルは実際にはデータベースに近いものですが、軽量である必要があり、必要に応じてエンドユーザーが簡単に編集できるようにする必要があります。ただし、その中にも多くのものが含まれます。(特定の要因に応じて、1Mb以上になる場合があります) SQLiteなどを使用するのではなく、プレーンテキストを使用することにしました。ただし、テキストを使用する場合は、さまざまな形式にも対応する必要があります。これまでのところ、私の選択肢は XML JSON カスタムフォーマット 私のファイルのデータは非常にシンプルで、ほとんどの部分はキーと値のタイプのものです。したがって、カスタム形式はそれほど難しくありません...しかし、サポートの作成について心配する必要はありません。JSONが構成ファイルに使用されるのを見たことがありません。XMLはファイルサイズを大幅に膨らませると思います。(私はまた、一般的にXMLが嫌いです)。 この場合、どうすればよいですか? 考慮すべき要素: この構成ファイルはWebサービスにアップロードできます(サイズが重要です) ユーザーは必要に応じて手動で編集できる必要があります(編集や読みやすさの問題) 自動的に生成および処理できる必要があります(速度はそれほど重要ではありませんが、過度に遅くはなりません) 「キー」と「値」はプレーンな文字列ですが、何でも含めることができるためエスケープする必要があります。(ユニコードとエスケープは簡単に機能する必要があります) 複数の構成ファイル。基本的に、各設定ファイルは1つの「プロジェクト」に関連付けられています

8
コードエディターが、入力したとおりにタブ/スペースなしでコードをフォーマットした場合、どのように感じますか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 2年前休業。 ほとんどの場合と同様に、私はこの概念が以前に試されたことを確信しています-私が「仮想フォーマット」と呼んでいるものを使用するエディターに出会ったことがありません。原則は、コードをフォーマットするために開発者またはエディター自体によって従来挿入されていたパディングスペース/タブ文字の効果をシミュレートする浮動左マージンがあるということです。入力すると、エディターは(コメントアウトされている場合でも)コードを継続的に解析し、各改行が見つかったコンテキストに基づいて必要なインデントを計算します XMLには文字の書式設定に特有の問題があり、入れ子になっている傾向があるため、特にXMLエディターを使用してこのアイデアを開発しています。ただし、多くの原則は従来のコードにも当てはまると思います。 そのようなツールを使ったコーディングの経験はありますか、それとも役立つか、妨げるかについての見解はありますか?バージョン管理システムで問題が発生しますか?(既存のパディング文字をすべて検出して取り除きます) 試していない限り、そのようなツールの動作を説明するのは困難です。実際に編集を開始するまでは、従来のように見えます。私は、XMLの編集、階層の変更、ドラッグ/ドロップ、コピーと貼り付けの操作、そして無効な文字が入力された場合のフォーマットの破損/修正を示す、プロトタイプの動作を示すスクリーンキャストビデオを公​​開しました。 編集 すべての回答/コメントはこれまで否定的でした-バランスを是正しようとするために、仮想フォーマットが考えるいくつかの利点: フォーマット標準についての議論は不要で、選択した/必須の規則に準拠する場所に改行を配置するだけです スペースが限られている場合(本/ブログ/ドキュメント)、ワードラップは可能ですが、完全なインデントを取得できます 各コードブロックには、画面の端に押し込まれずに、開始位置のすぐ隣に「マウスハンドル」があります。これをクリックして、ブロック全体または内部ブロックを選択します。 ドラッグアンドドロップして忘れる-初めて実行可能になります 他の人々のコードを再フォーマットする時間はありません 正しくフォーマットされていないコードはありません(レンダリングがないという意味で) Ctrl + Backspaceの代わりにBackspaceを使用すると、キーボードのガイドキーを指で維持できます 柔軟なレンダリング-レンダリングされたフォーマットを環境に適合させます。誰かが携帯電話/小さな画面のタブレットでコードを読んでみましたか? 編集可能な文字が(サンプルXSLTで)およそ25%少ないと考えてください。効率の面でメリットはありませんか? 編集-これまでの結論 開発者は、インデントに使用される埋め込み文字の使用に固有の欠点のほとんどを効率的に克服するツールと作業方法を確立しています。 書式設定文字を削除すると、一部の差分ツールに悪影響が及ぶことが懸念されます。 開発者は、自動レンダリングでは処理できないような方法でフォーマットを「微調整」する柔軟性を求めています。 先頭のスペース/タブを削除すると、そのようなコードを効率的に確認するには、コードをフォーマットできる「コード認識」ツールが必要になります。プレーンテキストエディターではフォーマットが表示されません。 (仮想インデントに対して)いくつかの仮想的なメリットがある可能性があると感じている人は、デメリットがこれらの潜在的なメリットを決定的に上回っていると考えています。 編集-評決 障害の認識といくつかの利点(ある場合)は、一般的な言語向けにこのスペースのない編集コンセプトを追求することは、単一の開発者としては賢明ではありません。ただし、XML / XSLTの場合(空白の特別な処理のため)、少なくとも可能性についてはある程度の合意があるようです。 編集-出荷された製品 ここで一般的に否定的な感情があったにもかかわらず、私は編集者を出荷しました。私は実際の経験に基づいて、より具体的な問題という形で批判をもたらすことを期待して無料版を作成しました。ややイライラして、これまでのところ不満はありません(実際、ダウンロード量を考慮したフィードバックはほとんどありません)。これは、ユーザーがこれを「そう何なのか」と考えるほどうまく調整したためだと思います。一種の機能-しかし、伝える方法はありません...
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.