meeting_20160307

Jump to bottom

Takatomo Fujisawa edited this page Mar 11, 2016 · 16 revisions

2016年03月07日打合せ

日時: 2016年03月07日（月） 15:00-
場所: W207
メンバ: 大石、児玉、福田、藤澤

アジェンダ

ウェブアプリケーションのUI仕様詳細について

資料

ウェブアプリケーションUI仕様詳細打合せ資料 - 藤澤

参考

内容

エラーとして何を表示すればよいか？

提示したNCBIと同様な表示を実現したい - 児玉
集計結果サマリ: errors: XX , warnings: YY + 共通メタデータは共通で表示
group by/sequentialオプションで切り替え表示
sequentialの場合はJSONの情報を上から素直に表示。
group byではError ID毎に表示
group byではレスポンスJSONのannnotations: 以下の情報を表示
group byではメッセージは変数展開しない
NCBIではViewパターンがいくつか存在する
Viewのパターンについては、ルールに記述されているerror/warning/auto-annotation/location情報からViewを設定する
異なる表示のための情報をできれば持ちたくない。
submission全体, sample単位, sample attribute, attribute suggestありの3-4つ程度？

エディター機能はどこに配置するか？

入力ファイル全体に対してサジェストされたものをReject/Acceptなすべて置換メニューも必要。
List Messages Sequentially (個別・一括変換)から
Group Error Messages by Type (一括変換)から
表示ソースからEditor呼び出しはやらない。
置換およびすべてを置換のメニューを用意する。

DDBJ BioSample Validatorの入力がBioSample要素を複数もつ場合を想定するべきか？

BioSample Validator実装において、岡別府さんから確認依頼された内容
既にbiosamplesetな対象ルールがいくつか存在する
DDBJ BioSample Validatorの入力JSONは（Submission単位で変換される）複数BioSampleエントリーを想定

PostgreSQLインターフェースについて

DDBJ内部用にprivate機能としての位置づけ
Docker配布時等には不要
PostgreSQLはID入力でXMLを変換するAPIサーバを別で立てることでValidationウェブアプリケーション上では実装しない
nodeアプリではURL入力を想定し、APIが返すXMLをバリデーションすることで児玉さん希望の仕様は満たす。
XMLを返すAPIサーバ開発はだれがやるか未定。【Todo】

結果画面では画面遷移するか?

どちらにしましょうか？
しない

CSSフレームワークは?

レスポンシブ対応。
Bootstrap使ってる。
プラスDDBJ色づけ

Editor log

汎用ルールに組み込むのは難しいデータ依存のボトムアップな作業履歴ルールの再利用
Applicationでの適応 (作業履歴ルールを適応のオプションの追加が必要) • Validatorでの適応 • Dockerで配布した際の、作業履歴を吸い上げる仕組みについて
今期の開発はJSONを保存するところまでで、再利用は来年度
レスポンスJSONに編集情報を追加したJSONをイメージ。JSONの仕様を決める【Todo】