setextドキュメントの日本語訳
１９９８年１月９日アップデート
このページではsetextドキュメントの日本語訳を公開しています。
# Message from: Ian Feldman, the Current Setext Oracle
# Date: Sun, 16 Aug
92 08:19:00 +0100 (CET)
# Reply-To: setext-list@random.se (Keepers
of The Setext Flame[tm])
# Replaces: setext_concepts_Mar92.etx
# Lines: 240
# Subject: setext_concepts_Aug92.etx
Thank you for your interest in the setext format. Enclosed
is an
advance sheet that will remain in effect until the first public
release of the setext format package (originally planned for
around
March 1st, 1992, now delayed).
シーテキストフォーマットに関心を持っていただいてありがとうございます。
シーテキストフォーマットが一般公開されるまで（当初は１９９２年の３月１
日頃と計画していたのですが、今は遅れています）ここに添付された仮のもの
が効力を持ちます。
If you recognize some of the arguments presented here then that
is
the price that you are paying for having been an early bird.
;-))
Please note that my email address may change in the near future;
consult the trailer of weekly issues of TidBITS for the most
current one.
ここの資料の中で見覚えがあるものがあるとすれば、それは早起きした者とし
て支払っている代価です。近い将来、私の電子メールアドレスが変更されるか
もしれないので注意してください。最も新しいものに関しては、週刊 TidBITS
の予告編を見てください。
What is setext
----------------
シーテキストて何？
As originally explained in TidBITS#100 and mentioned there from
now on, that publication now comes "wrapped as a setext." The
noun
itself stands for both a method to wrap (format) texts according
to specific layout rules and for a single _structure_enhanced_
text. The latter is a text which has been formatted in
such a
fashion that it contains clues as to the typographical and logical
structure of its source (word-processed) document(s), if any.
Those clues, which I call "typotags," facilitate later automatic
detection of that structure so it can be validated and extracted/
processed/ transformed/ enhanced as needed, if needed.
TidBITS#100 で最初に説明し、そこで触れたように、今後 TidBITS 出版はシ
ーテキストとしてフォーマットされて配布されます。シーテキストという名称
は、特定のレイアウト規則に従ってテキストをフォーマットする方法及び１つ
の構造性を高めたテキストの両方を意味します。後者は（ワードプロセッサー
で作成した）ソースドキュメントのタイポグラフ的および論理的構造（もしあ
れば）に関する手がかりを含むような方法でフォーマットさたテキストです。
”タイポタグ”と呼んでいるこれらの糸口は、後の自動検証をさらに容易なも
のとし、必要に応じて、構造性の検証、取り出し、処理、変換、改良等を可能
にします。
It follows that setexts, being nothing but pure text (albeit
with
a special layout), are eminently readable using ANY editor or
word processor in existence today or tommorrow, and not only
on
the Macintosh either. ANY computer, any computer program
that is
capable of opening and reading text files can be used for reading
setexts. By default all properly setext-ized files will
have an
".etx" or ".ETX" suffix. This stands for an "emailable/
enhanced
text", the ExtraTerrestrial overtones nothwistanding ;-))
（特殊なレイアウトですが、）単なる純粋なテキスト以外のなにものでもない
シーテキストは、今日存在している又は明日のどんなエディターまたはワード
プロセッサー（Macintosh に限らず）を使って非常にうまく読めます。テキス
トファイルをオープンでき、読めれるならどんなコンピュータ、又はコンピュ
ータプログラムでもシーテキストを読むのに使用できます。正しくシーテキス
トフォーマットされたファイルはすべて、標準で".etx"または".ETX"拡張子を
付けています。これは、"ExtraTerrestrial（地球外の）"を連想させますが、
”電子メール用及び構造性を高めた（エンハンスされた）テキスト”を意味し
ます。
Unlike other forms of text encoding that use explicit, visible
tag
elements such as <this> and <\that>, the setext format
relies
solely on the presence of _implicit_ typotags, carefully chosen
to be as visually unobtrusive as possible. The underlined
word
above is one such instance of the defacto "invisible" coding.
Inserted typotags will at worst appear as mere "typos" in the
text.
<this>とか<\that>のような明示的な、目に見えるタグ要素を使ってテキスト
コード化を行う他の形式とは異なり、シーテキストフォーマットはできるだけ
目立たないように注意深く選ばれた、明示的でないタイポタグを使用していま
す。上の下線を引いた語は、事実上”目に見えない”コード化の一例です。挿
入されたタイポタグは、最悪の場合でもテキスト内のタイポグラフエラーにし
か見えないでしょう。
Similarly, just to give an example, here is a short description
of the four types of word emphasis typotags that setexts MAY
contain, limited to one emphasis type ONLY per word or word
group:
シーテキスト内で使用できる、一語または複数からなるグループ当たり１つの
強調タイプしか使用できないといった制限がありますが、一例を挙げるため、
ことばを強調する４種類のタイポタグを簡単に説明します：
------------------- ---------------------------- --------------
**aBoldWord** **multiple
bold words** ; bold-tt
_anUnderlinedWord_ _multiple underlined words_
; underline-tt
~anItalicWord~
; italic-tt
aHotWord_
multiple_hot_words_ ; hot-tt
-----------------------------------------------------------------
一語の太字 複数語の太字
一語の下線 複数語の下線
一語の斜体 複数語の斜体
一語のホットワード 複数のホットワード
the 'hot-tt' is synonymous with the 'grouped' style of HyperCard
only single ~italic~ words are allowed for visual-clarity reasons
hot-ttタイポタグは、HyperCardのグループ化スタイルと同意語です。
見た目にわかりやすいという理由で、斜体は単一語だけしか認めていません。
Please note, however, that the <end> strings previously found
in
TidBITS #100-110 were not part of the format as such, but were
added by Adam Engst for a specific setext-raterrestrial purpose.
しかし以前に TidBITS #100-100 で使われていた <end> 文字列は、シーテキ
ストフォーマットのタイポタグではなく、特殊なシーテキスト以外の目的で
Adam Engst が追加したものです。
Why is setext
---------------
なでシーテキスト？
Data formats like the RTF (Rich Text Format) and SGML (Standard
Graphic Markup Language) have been designed for processing ONLY
by software. Setext, on the other hand, has been _optimized_
for reading directly by human eyes on what probably is still
the
lowest common denominator of today's computer hardware, an 80-
character by 24-line terminal screen (or, in effect, any computer
screen). It follows that the format is intended chiefly
for
smaller texts, those of a size that a human reader might find
within her capacity of overview.
ＲＴＦ及びＳＧＭＬのようなデータフォーマットは、ソフトウェアがあっては
じめて処理できるようにデザインされています。ところが、シーテキストは、
恐らくまだ今日のコンピュータの最少共通項である２４行８０桁の端末画面（即
ち、事実上すべてのコンピュータの画面）上、肉眼で直接読むために最適化さ
れています。当然、このフォーマットは主に、読む人が概観できる範囲内の、
短いテキスト用です。
I need to state explicitly that although TidBITS is currently
the
only setext publication in wide distribution, the setext is
NOT
synonymous with that of TidBITS's layout. Many other distinctive
layouts are possible. TidBITS is therefore just an _instance_
of
the format, not THE setext format. More specifically,
that also
means that any of you thinking of writing a "TidBITS browser"
should in reality be considering a "setext browser." Otherwise
your program will in all probability be able to recognize only
today's specifically-formatted TidBITS and no other future setext
publications (which are in the making), including that of a
future
possibly changed or modified TidBITS.
TidBITS が現在幅広く配布されている唯一のシーテキストフォーマットによる
出版物ですが、シーテキストは、TidBITS のレイアウトと同義ではないことを、
はっきり述べておく必要があります。他にも多くの異なるレイアウトが考えら
れます。ですから、TidBITS はシーテキストフォーマットの１つの実例であっ
て、シーテキストフォーマットそのものではありません。さらに明確に言えば、
TidBITS ブラウザを作ろうと考えている者はだれであれ、実際はシーテキスト
ブラウザの作成を考慮する必要があるのです。そうでないと、そのプログラム
は今日の特殊なフォーマットによる TidBITS 出版物は認識できるが、将来起
こりうる変更又は修正された TidBITS を含む、その他将来の（現在作成中の）
シーテキスト出版物は十中八九認識できないと言っていいでしょう。
How come is setext
--------------------
なぜシーテキスト
The idea of a common format for online-distributed publications
grew in my mind since approximately 1986-87. It came into
focus
after I started corresponding with Adam C. Engst, following
my
April, 1990 criticism of the original TidBITS presented as a
HyperCard stack. Gradually it ceased to be a redesign
effort for
the TidBITS and became instead a generic format for all kinds
of
electronic publications (which I affectionately call "the compu-
rags" ;-)). I hit on the current "tagless" version of
the format
in the winter of 1990 and the first internal beta product --
a
setext encoder for TidBITS -- saw the light of the day in July
of
1991. Later Adam wrote a setext-encoding Nisus macro for
his
personal use, the one he now uses to wrap the weekly issues
of
TidBITS (he isn't putting all those spaces and dashes in there
entirely by hand! ;-))
オンライン配布出版のための共通フォーマットの考えは、１９８６-７頃から
私の頭のなかで育って来ています。HyperCard 資料の山として提供されたオリ
ジナルの TidBITS に対する私の１９９０年４月の非難に続いく、Adam C.
Engstとの交信の後、この概念は明確になものになりました。シーテキストは、
徐々に TidBITS のデザインのやり直しといったものではなく、すべての種類
の電子出版（私はコンピュラグと呼んでいますが）で使用できる包括的なフォ
ーマットになりました。１９９０年の冬、シーテキストフォーマットの現在の
”タグのない”バージョンを思い付き、そして最初の内部でのベータ製品
（TidBITS 用シーテキストエンコーダー）は１９９１年７月に世に出ました。
後に、Adam が個人的な使用のためにシーテキストコード化マクロ Nisus を書
きました。これは、週刊 TidBITS をフォーマットする時に彼が現在使用して
いるものです。（彼は、空白文字とかハイフォンを、すべて手で打ち込んでい
るのではありません。）
As can be seen from the above setext is not some quickie project,
though up and finalized in a few afternoons. A lot of
thought
has gone into it and some of it has survived to the present
day.
Needless to say the format definition will be placed in the
public domain and its use actively promoted by the many parties
that have expressed an interest in adopting it for their own
use.
上記のことから見て取れるように、シーテキストは、数日で突如終わらせまし
たが、急ごしらえのプロジェクトではありません。多くの思案がつぎ込まれて
おり、その幾つかは今日まで残っています。言うまでもなく、フォーマット定
義は、パブリックドメイン（権利不在状態）に置かれ、その使用は、独自の使
用で採用するのに関心を示した多くの関係者によって積極的に奨励されていま
す。
What for is setext
--------------------
シーテキストの目的
The setext (data) format is intended primarily for use by online-
distributed periodic publications. It is particularly
well-suited
to all kinds of electronic digests and other types of repetitively
disseminated text information. Despite its formal appearance
as
"mere stream of unenhanced ASCII characters on a computer screen"
setext is rich enough and unambiguous enough to permit construction
of fairly complex encoding engines for specific application
purposes
(also on top of the format) and to allow easy implementation
of a
countless number of front-end browsers/ decoders and other
reading/ archiving-enhancement tools.
シーテキスト（データ）フォーマットは、主としてオンラインで配布する定期
的な出版物での使用のためのものです。すべての種類の電子ダイジェスト（要
約雑誌）及び他の種類のくり返し配布されるテキスト情報に特に向いています。
”コンピュータの画面上で構造性を高めていない単なる ASCII 文字の集まり
（流れ）”という表面的な外観にもかかわらず、シーテキストは、（更にフォ
ーマットの拡張として）特殊なアプリケーション目的でのかなり複雑なコード
化エンジンの作成をも可能にし、さらに無数のフロントエンドブラウザ、デコ
ーダー、その他閲覧/保管強化ツールの簡単なインプレメンテーションを行う際
にも、機能は十分豊富で明瞭なものです。
While setext does, indeed, allow the preservation of a source
text's structure it does not, by definition, guarantee the 100%
ability to recreate it at the destination. Any word originally
styled as **bold** may in effect end up as Yellow-On-Black or
be
set in a different font, or considered a candidate for a
cumulative keywords list or be deemphasized at will. There
are
not now and never will be any rules to govern how decoded setexts
should be presented at the receiving end. It will be up
to each
front-end's author to ensure that decoded (no-longer-)setexts
are
presented in a fashion that's agreeable to his/ her end users.
There is plenty of sound advice and recommendations on how to
achieve that but that's an entirely different matter.
実際、シーテキストはソーステキストの構造を保持していますが、定義によれ
ば、受信側が１００％同じものを再現できる能力は保証はしていません。本来
**太字** として表現されていたことばが、事実上黒地に黄色で表示されたり、
異なるフォントを使って表示される、又は累加的なキーワードリストへの候補
と見なされる、或いは随意に強調しないように変更されるかもしれません。現
在、そして将来においても、受信側で解読されたシーテキストをどのように表
示するかを規定する規則はありません。解読されたシーテキスト（これはもう
シーテキストではない）をエンドユーザに適したやり方で表示できるようにす
るのは、それぞれのフロントエンド作成者の責任です。では、どのようにすれ
ばいいのかに関した助言とか忠告はたくさんありますが、これは全く異な事で
す。
Those principles also apply to decoding of a setext's logical,
rather than merely its typographical, structure. The format
does
not rely on some large set of predefined, unambiguous, mutually-
exclusive rules. Rather, it "knows of" just the barest
set of
typotags (1 required, 12 optional), knows their symbolic purpose
and what criteria to use when looking for and validating them
in
a setext. This approach differs some from the commonly
heard
programmers' wish for clearly-delimited data patterns that could
be scanned for quickly and their position used as an offset
to
the text to be displayed.
これらの原則は、単にシーテキストのタイポグラフ的な構造の解読だけではな
く、論理的構造の解読にもあてはまります。フォーマットは、予め定義された、
明瞭な、相互排除的な数多い規則に頼っているいるのではありません。そうで
はなく、このフォーマットは、最小限のタイポタグ（必須：１、オプション：
１２）を”知っている”だけで、それらの符号の目的、及びシーテキストでそ
れらのタグを検索し、検証する時にどの条件を使うか理解しているだけです。
この方法は走査を素早くできるように、はっきり限定したデータ型、及び表示
するテキストへのオフセット位置など一般によく耳にするプログラマーの希望
とは幾分異なります。
Setext has those patterns too but, since it relies primarily
on
defacto "invisible" elements that could also be part of the
text
itself, it must validate them first before proceeding with any
enhancements. Writing a real setext decoder is therefore
conceptually much closer to (though nowhere near as hard as)
writing an SGML application than it is to writing a macro routine
to munge some data in one predefined fashion. In spite
of all
that, setext tools should be easily implementable with, and
no
more complex than, typical HyperTalk, sed, awk and perl scripts.
The barest minimum required for such an attempt is an intelligent
search/ replace function in a programmable macro editor.
Though
yet to be proven, conceptually there is nothing in the format
to
prevent implementation of real-time setext browsers written
in,
say, some advanced pattern-matching macro language of a terminal
emulator program.
シーテキストもこれらのパターンを有していますが、主にテキストそれ自身の
部分にもなりうる事実上”目につかない”要素を使用しているので、構造性を
持たせる処理に入る前にまず第一に要素検証が必要です。ですから、実際のシ
ーテキストデコーダーを作成するのは、概念的には、既に定義されたやり方で
データを包括的に書き換えるマクロルーチンを書くというよりもＳＧＭＬアプ
リケーションを書く（その困難さにはおよびませんが）のにより近いです。こ
れらのことにもかかわらず、シーテキストツールは簡単にインプレメントでき、
典型的な HyperTalk、sed、さらに perl スクリプト以上に複雑であるべきで
はありません。その様な試みで、最低限必要なことは、プログラム可能なマク
ロエディター内のスマートな検索/置換機能です。証明はまだですが、概念的に
は、たとえば端末エミュレータプログラムの高度なパターンマッチマクロ言語
で書かれたリアルタイムシーテキストブラウザのインプレメンテーションの作
成を妨げるものはフォーマットの中には何もありません。
Where is setext
-----------------
シーテキストはどこにありますか
As of now (Aug '92) there is finally one validated setext browser
in existence, the Easy View 2.1 application, written by Akif
Eyler,
free to distribute and use. Though not yet capable of
decoding
style-typotags nor unwrapping (reflowing) paragraphs of text,
it
is a very nice application all the same. It allows for
cumulative
indices of TidBITS or any other setext, and is capable of parsing
and displaying a few other useful data formats as well (Info-Mac
Digest among others). Adam Engst has uploaded it to CompuServe
(MACCLUB #8), ZiffNet/Mac (ZMC:DOWNTECH #7), America Online
("look
for a new TidBITS library in the Hardware forum coming soon"),
and
the mother of all Macintosh archives, the <sumex-aim.stanford.edu>
(look for it in /info-mac/digest/tb or /info-mac/app directories).
It is, no doubt, already present at many private Bulletin-Board
Systems etc. Read "TidBITS#136/03-Aug-92" for more information
about the Easy View 2.1 and, if you use the application, do
write
Akif a note of appreciation.
今この時点（１９９２年８月）で、ようやく、正当と認められたシーテキスト
ブラウザが１つ存在しています。それは Akif Eyler が作った Easy View
2.1
というアプリケーションで、自由に配布及び使用できます。スタイルタイポグ
ラフの解読とテキスト段落内の改行排除（再流し込み）は出来ませんが、非常
によくできたアプリケーションであることに変わりありません。TidBITS また
は他のシーテキストの累加的索引を考慮しており、その上、他の幾つかの役立
つデータフォーマット（特に Info-Mac Digest）の要素分析（パース）と表示
もできます。Adam Engst は、それを CompuServe (MACCLUB #8)、ZiffNet/
Mac (ZMC:DOWNTECH #7)、America Online（近近できるハードウェアフォーラ
ムの中で新しい TidBITS ライブラリーを探してください）そしてすべてのマッ
キントッシュアーカイブの母である <sumex-aim.stanford.edu>（/info-mac/
digest/tb 又は /info-mac/app ディレクトリで探してください）へアップロ
ードしています。恐らく間違いなく、多くの個人的な掲示板システム等で既に
存在していることでしょう。Easy View 2.1 に関する詳細は”TidBITS#136/
03-Aug-92”を読んでください。このアプリケーションを使用する場合は、Akif
に感謝を表す短い手紙を出してください。
Other than that I have a working prototype of a setext front-end,
which has been "not far from completion" for the last half year
or
so (draw your own conclusions). A paging macro routine
for the
rn, a popular newsreader under unix, allowing forward jumps
to the
next topic of any TidBITS read online in comp.sys.mac.digest
group
has been published in TidBITS#110/09-Mar-92. On top of
that there
is a mailing list for developers and future setext publishers:
<setext-list@random.se>. If interested, please send
me a short
note stating degree of your future involvement (wants to write
a
setext tool or 'just an observer/ future user') and your Internet-
accessible email address and I will put you on the list and/
or
reply as soon as possible.
私もシーテキストフロントエンドの実用的なプロトタイプを作成していますが、
これは過去半年くらいずっと”完成からさほど遠くはない状態”のままです。
（これが何を意味するのかは各自の判断に任せます。）comp.sys.mac.digest
グループで、どんな TidBITS READ オンラインの次のトピック（話題）へでも
前方ジャンプできる rn（unixでの評判のよいニュースリーダ）用ページング
マクロルーチンが、TidBITS#110/09-Mar-92 で発表されました。
私は、開発者と将来のシーテキスト出版者のための郵送先名簿を管理していま
す：<setext-list@random.se>。関心のある方は、将来のかかわりの程度を明
記した短いノート（シーテキストツールを開発したい、または単なるオブザー
バ/将来のユーザなど）とインターネットにアクセスできるあなたの電子メール
アドレスを私まで送ってください。そうすれば、あなたの名前を郵送先名簿に
加え、そして/或いはできるだけ早く返事を出します。
When is setext
----------------
シーテキストの時期
Due to a varying work load and other distractions between the
original announcement of the planned release and the actual
date
of it, the browser that I am writing is not yet ready.
I do not
intend to repeat the mistake of preannouncing it again. Instead
please feel free to join the mailing list through which the
rest
of the specifications will be published. The full release
will
contain approximately 150K worth of setexts on setext along
with
a demo browser written in HyperCard (2.0) that will permit
showing of the format's capabilities in a dynamic rather than
the strictly textual and sequential fashion. Those of
you who
know me, know also of the high standards of coding that I try
to
adhere to.
変化する仕事量と気の散ることなどが原因して、最初に発表したリリース予定
には間には合わず、私のブラウザはまだ完成できていません。前もってリリー
スする日を発表すると言った間違いを、もう一度くり返そうとは思いません。
その代わりとして、どうか遠慮なく郵送先名簿に加わってください、仕様の残
りの部分はそのメール経由で発表されるでしょう。最終的な仕様書のリリース
は、シーテキストフォーマットで約１５０Ｋのシーテキストドキュメントと
HyperCard (2.0) で書かれたデモ用ブラウザを含んだものです。このブラウ
ザは、厳密にテキストで連続したやり方ではなく、ダイナミックなやり方でシ
ーテキストフォーマットの性能を示すことができるでしょう。私のことをを知っ
ている人は、私は常にコーディング水準を高くするよう心掛けていことをご存
知でしょう。
If you're among those that have already written a prototype
that's based mainly on a reverse-engineered layout of the current
TidBITS then you'd be well advised not to release it without
prior
validation of it by me. Please do not call your product
a
"setext browser" (or whatever) UNLESS it is truly capable of
parsing all (future) setextized docs, not solely the TidBITS.
主に現在の TidBITS をリバースエンジニアーした設計をベースにしてプロト
タイプを既に作成している場合、私が正当なものだと認めるまではそれをリリ
ースしないよう忠告します。TidBITS だけではなく、すべての（将来の）シー
テキスト化されたドキュメントの要素分析（パース）を正しく行える機能を持っ
ていなければ、その製品をシーテキストブラウザと（あるいははどんな名でも）
呼ばないでください。
How is setext
---------------
シーテキストの特徴
A lot can (and will) be said about it but there is one claim
no
other text encoding method can make: "there is a lot more of
me
than meets the eye" ;-))
シーテキストに関しては、多くのことが言えます（言えるでしょう）が、他の
テキストコード化方法が主張できないことが１つあります：”見かけ以上に隠
れた私がはいっている”、ことです。
Who is setext
---------------
シーテキストは誰
The setext format and its underlying philosophy isBroughtToYouBy
Ian Feldman <ianf@random.se>. I live in Stockholm,
Sweden, Europe.
I used to work as and describe myself variously over the years
but now simply contend myself with being just a free Human Factors
thinker and tinkerer.
シーテキストフォーマットとその根底にある考え方は、Ian Feldman
<ianf@random.se> が”あなたにもたらした”ということです。私は、スウェ
ーデン（ヨーロッパ）のストックホルムに住んでいます。私は長年色々な仕事
をし、また色々な肩書きを持ちましたが、今はただ単に、人間要因の自由な思
想家およびいじくりやで満足しています。
.. last line contains a twodot-tt, a tag signifying the logic end of
.. text while those three lines are all suppress-typotagged ones, i.e.
.. can be suppressed (hidden) by a front-end application by default.
..
最後の行には、テキストの論理的な終わりを意味する２点タイポタグ
"twodot-tt" が含まれており、これられの３行には、フロントエンドがデフォ
ルトで隠すことのできる行であることを示す、抑制タイポタグが付いています。
..
# From setext-list Sun Mar 15 16:35:03 1992
# From: Keepers
of The Setext Flame[tm] <setext-list@random.se>
# Date: Sun,
15 Mar 14:55:00 1992 +0100 (CET)
# Organization: random design -- any old TTY will do
# X-Bad-Address: no more mail to <not.bad.se> please
# Subject: what makes a setext
(sermon #1)
ermons etexts
rmonse textse
monset extser
onsete xtserm
nsetex tsermo
setext sermon
================
920315 #1
Hi everybody (or, perhaps, "Hallelujah!" ;-))
Welcome. Here's the first installment of the setext
mailing list.
My intention is to serve a lively mix of format specifications,
questions-and-answers and browser implementation trivia
("quick!
which of Macintosh word processors was first with a built-in
outliner?" ;-)) Please be forgiving of Muddy English[tm],
if any;
I now run without the benefit of a spelling checker but
even if
I had one, it would hardly matter, comprehension- or otherwise.
---Ian
皆さんこんにちは、（ハレルヤ！）
ようこそ。これはシーテキストのメールグループへ配布する第一回目のもので
す。フォーマット仕様、質疑応答、ブラウザのインプレメンテーションでの雑
学的な事柄などを混ぜて活発な討論ができることを希望します。（さて、どの
Machintosh 用ワードプロセッサーが最初にアウトライナーを組み込むでしょ
うか？） 私の英語の表現をおおめに見てください。スペルチェッカーは使っ
ていません。スペルチェックを使ったとしても、理解するうえで又はその他で、
ほとんど関係ないでしょう。
イアン
What makes a setext?
---------------------
シーテキストの条件？
As mentioned in the concepts document (available from TidBITS
fileserver; details on how to obtain it last in any TidBITS
issue)
the setext format relies on a small number of highly unobtrusive
tagging elements to encode the logical structure of source texts
intended for wider distribution. This structure can later
be
restored at the receiving end, according to rules implemented
by
each particular front-end's writer. Thus it is entirely
possible
to treat the same setext differently depending on behavior of
a
particular application used for reading it. Indeed, presence
of
key typotags in the same setext may in one instance be understood
only as flags for change of typefaces and sizes and in another
as
logic markers signalling that flagged elements be entered into
a
local database. This formal decoupling of logical structure
from
typography during the online-transport stage is part of the
beauty
of setext.
概念を述べたドキュメント（TidBITS ファイルサーバから入手可能：詳しい入
手方法は、TidBIT（出版物）の最後に出ています）に書いたように、シーテキ
ストは、より広い範囲での配布を目的としたソーステキストの論理構造をコー
ド化するための小数の非常に控え目なタグ要素に依存しています。この構造は
後に、各フロントエンドの開発者によってインプレメントされている規則に従っ
て、受信側で復元できます。ですから、同じシーテキストでも閲覧に使用する
アプリケーションよって違う扱いを受けるということも生じます。事実、同じ
シーテキスト内のキータイポタグが、ある場合はただ単に書体とサイズ変更の
ためのフラグとして、また他の場合ではフラグ付けされた要素はローカルデー
タベースへの登録を示す論理マーカーとして解釈されるかもしれません。シー
テキストの美点は、オンライン転送中、タイポグラフィーから論理的構造を一
定の形式によってこのように分離しているこです。
Still, before any decoding can take place a text has first to
be
verified whether it is a setext and not some arbitrarily-wrapped
stream of characters. Although there are more ways than
one to
achieve that goal there is one _primary_ test that has to be
passed with colors or else the text being tested cannot be a
setext. What ought to be done with thus "rejected" texts
will be
discussed in an upcoming notice. This one is all about
finding
out whether to proceed with parsing at all.
しかし、解読処理に移る前にテキストがシーテキストなのかかどうか、単に任
意にフォーマットされた文字の集まりではないのかまず検証する必要がありま
す。これを行う方法は幾つかありますが、シーテキストならパスしなければな
らない重要なテストが１つあります。それにパスしなければそのテキストはシ
ーテキストではありません。では、パスしなかったテキストはどうすればよい
のかに関しては近く予定されている通報の中で取り上げるでしょう。ここでの
内容のすべては、要素分析（パース）処理へ進むか否かの決定に関したもので
す。
Chief among the typotags are two that signal presence of setext
titles and subheads inside the text. A setext document
can be
formatted more or less properly, may contain or lack any other
of
its "native" elements but it has to have at least one proper
subhead or a title in order to be declared as "a certified
setext."
タイポタグの中で、特に重要なもなが２つあります：これらは、テキストの中
でシーテキストの表題（複数可）とサブヘッダー（複数可）の存在を示すタイ
ポタグです。シーテキストドキュメントは、おおよそ正しくフォーマットする
ことが可能で、シーテキストが用意している他の要素（タグ）を含んだり、含
まなかったりできますが、正真正銘のシーテキストだと断言するためには、正
しいサブヘッダー又は表題を少なくとも一つ含んでいなければなりません。
Here are a few demo setext subheads:
------------------------------------
シーテキストサブヘッダーの例：
_ _ _ _ Which Share Just One _ _ _ _
------------------------------------
これらの例は、subhead-tt として目に見える右端までの文字長が同という特
徴があります。
----------> UnifyinG FeaturE
------------------------------------
of EQUAL RIGHTMOST VISIBLE character
------------------------------------
length as that of its subhead-tt's
------------------------------------
[this line is called subhead-string]
------------------------------------
この行はサブヘッダー文字列です。
[the one below is called subhead-tt]
------------------------------------
すぐ下の行はサブヘッダータイポタグ (subhead-tt)です。
[together they make a valid subhead]
------------------------------------
これらを組み合せると、有効なサブヘッダーとなります。
(!) and of course, subheads do not have to be of the same
length ;-)
-----------------------------------------------------------------------
勿論、サブヘッダーの長さは、全部同じである必要はありません。
(nor have to begin in column 1)
---------------------------------
また、行の第１桁から始める必要もありません。
although it is recommended that they stay below 40 characters
--------------------------------------------------------------
もっとも、４０文字以内から始めること推奨しています。
Second Setext In This File
==============================
このファイルの中で、二番目のシーテキスト
((end of examples))
-------------------
((_not_ a subhead))
用例の終わり
これはサブヘッダーではありません
Chief among the reasons why one should first look for presence
of
subheads rather than titles is that it is fully conceivable
that a
setext might have been created without an explicit title-tt
in
order to allow decoder programs to distinguish between part
one
and any subsequent ones in a possible multi-part mailing. This
absence of a title-tt could be enough of a signal to start looking
for possible "part x of y" message in either the subject line,
filename or anywhere "above" the first detected subhead of the
current text.
表題ではなくサブタイトルがあるかないかを最初に探す主な理由は、解読プロ
グラムが、複数の部分からなるメールで、第１部分とそれに続く部分を区別す
ることができるように、明示的なタイトルタタイポタグを付けずにシーテキス
トを作成している可能性も十分考えられるからです。ですからタイトルタイポ
タグが存在していない場合は、サブジェクト行、ファイル名、或いは現在のテ
キスト内で見つかった最初のサブヘッダーよりも”前の”どこかで、可能性の
ある、”ｙのｘ部分”についてのメッセージ（要約、説明）を探し始めるとよ
いでしょう。
Therefore, here's a formal definition of what makes a setext:
これがシーテキストであるための正式な定義です：
+-------------------------------------------------------------+
| a text that contains at least one verified setext subhead
|
| or setext title
|
+-------------------------------------------------------------+
シーテキストは、正当なシーテキストサブヘッダー、又は表題を少なくとも１
つ含んだテキストです。
RIGHTMOST VISIBLE char length of subheads and titles
-----------------------------------------------------
サブヘッダーと表題の、目に見える右端の文字までの長さ
What, pray, is meant by that? It is a very important point: a
properly-formatted setext subhead is made up of a subhead-string,
(less than 80, preferably no more than 40 characters long for
ease of implementation reasons), followed by a line consisting
of
an equal number of dash characters, (ASCII 45/ hex 2d) counted
from column 1 to the RIGHMOST VISIBLE subhead-string column,
incl.
possible leading white space. For instance, the subhead
above is
made up of a subhead-string with a total length of 56 characters,
of which 1 is a leading and 4 are trailing ("invisible") blanks.
Rightmost visible length of both the subhead-string and its
all-dash-typotag line is 52 characters however. This is
what
makes that pair of lines into a verified setext subhead.
この意味はいったい何ですか？ これは大変重要な点なのです：正しくフォー
マットされたシーテキストサブヘッダーは、１つのサブヘッダー文字列（８０
文字以内、インプレメンテーションのしやすさを考慮すると４０文字以内が望
ましい）とそれに続く、第１桁から、サブヘッダー文字列（もしあれば、先頭
の空白も含む）の目に見える右端の桁までの文字と同数のハイフォン (ASCII
45/ Ox2D)の行からなります。例えば、上のサブヘッダーは、最初の空白と最
後の（目に見えない）４つの空白文字を含む合計５６文字のサブヘッダー文字
列と５２のハイフォン文字の行から成り立っています。これで、この２行が正
しいシーテキストのサブヘッダーとなります。
Indeed, this positive-vetting mechanism is the basis on which
the
setext format rests... all-dash or all-equal-sign lines
doing the
double duty of being both machine-recognizable flags for detection
of subheads or titles AND visual underline elements in their
own
right. Trailing blanks and tabs are simply a nuisance
which has
to be taken into the account. They may have been appeared
there
inadvertedly or as a result of either line having been pasted
in
from another source and survived the encoding process.
Automatic
setext-assembly routines will create 100%-clean subheads but
since
setexts are so easy to code wholly by hand the possibility of
subheads with in reality invisible trailing tabs or spaces cannot
be discounted entirely (as is the case with several among the
demo subheads above). Therefore the only proper way to
validate
a subhead (or a title) is to do it in like fashion:
実際、シーテキストフォーマットは、この明確に定めた検証方法を基礎として
います。ハイフォン、又は等符号だけからなる行は、サブヘッダー又は表題を
見つけるためのマシーン認識フラグ、及びそれそのもが目に見える強調要素の
二役を兼ねます。あとに続く空白とタブは、考慮する必要がある厄介なことで
す。不注意に、或いは他のソースから行の張り付けを行いその後のコード化処
理の間も残った結果そこにあるのかもしれません。自動的にシーテキストを組
み立てるルーチン等は、１００％きれいなサブヘッドを作成するでしょうが、
シーテキストは手でコード化することも簡単なので、（上の幾つかのデモサブ
ヘッダーのように）サブヘッダーに隠れたタブとか空白文字が残っている可能
性も考慮する必要があります。結果として、サブヘッダー（又は表題）を検証
する正しい唯一の方法は、次のとおりです：
(a) scan forward for a line that's made up of at least 2 leading
dash characters (=minimum length; a practical consideration)
with possible trailing white space (spaces, tabs
and other
defacto invisible [control] characters). If applicable,
grep
all such lines globally using the pattern "^--[-]*[\s\t]*$"
先頭に少なくとも２つ（最低限必要な長さ＝２：実用的考慮）ハイフォンがあ
る行（空白文字、タブ、その他の事実上隠れた［制御］文字などの空白が後ろ
に続いている可能性もある）を前方へ検索します。使える場合は、
"^--[-]*[\s\t]*$" パターンを使って、グローバルに grep でマッチするす
べての行を見つけてください。
(b) if no lines found, repeat the search for title-typotags ("=").
そのような行が見つからない場合、表題タイポタグ (title-typotag ("=")で
検索をくり返えします。
(c) if no lines found then the text is not a setext. Display it
using the default behavior. End of verification
process.
それでも、該当する行が見つからない場合はシーテキストではありません。デ
フォルト機能を使って表示します。検証処理終了。
(d) if either (a) or (b) returns one or more lines, then each of
these will have to be checked for being part of
a setext
subhead or title.
(a)又は(b)で、該当する行が見つかれば、シーテキストサブヘッダーなのかそ
れとも表題なのか、それぞれの行について確認する必要があります。
(f) if first returned line is equal to the first physical line in
the buffer or file then proceed with the next instance.
First
possible line number on which a typotag could be
present is 2.
As long as the list is not empty repeat for each
line in the
returned list:
最初に見つかった行が、バッファーまたはファイル内での物理的な最初の行と
同じ場合、それは無視して次の行の処理を行います。タイポタグとして存在で
きるのは２行目以以降からです。見つかったすべての行に対して、次の処理を
くり返します：
(g) calculate which line it is, counting from the chosen index (like
the beginning of file or the text buffer).
Assign this value to
a variable "ttPtr."
（ファイルまたはテキストバッファーの先頭のような）定めたインデックスか
ら数えて何行目になるのか計算します。この値を、"ttPtr"変数へ設定します。
(h) strip (a copy of) line ttPtr of the text of any _trailing_ tabs,
spaces and possible other invisible characters
ttPtr 変数の示す行のテキスト（或いは、そのコピー）から後ろにくっついて
いるかもしれないタブ、空白、他の可能性のある隠れた文字を取り除きます。
(i) extract the character length (count the number of dash chars);
store it in a local variable "ttLength"
（ハイフォン文字を数えて）文字長を求めます；それをローカル変数 ttLength
へ保存します。
(j) strip (a copy of) line ttPtr-1 of the text of any _trailing_
tabs, spaces and possible other invisible characters;
store the
trailing-blankless result in a local variable "sString"
ttPtr 変数マイナス１の示す行のテキスト（或いは、そのコピー）から後ろに
くっついているかもしれないタブ、空白、他の可能性のある隠れた文字を取り
除きます；空白など後ろに続いていない文字列をローカル変数 sString へ保存
します。
(k) extract the number of characters in sString (incl possible
_leading_ indent); store it in a local variable
"sLength"
sString 内の文字の数（存在していればインデントも含め）を求めます；それ
をローカル変数 sLength へ保存します。
(l) compare ttLength to sLength; if they match then declare line
ttPtr-1 to be a subhead; output sString to display
(with chosen
typographical enhancements if needed; line ttPtr
itself doesn't
have to be displayed of course).
ttLength と sLength を比較します；同じ場合は、ttPrt-1の行はサブヘッダ
ーです。（必要なら選択されているタイポグラフ的な効果を加え）sString
を
表示します；勿論 ttPtr の行そのものは表示する必要はありません。
(m) start the next parsing loop
次の要素分析（パース）ループを続けます。
an example in HyperTalk
------------------------
HyperTalkでの例
Though the above appears complicated in reality it is a sequence
of very simple, straightforward operations. Here is how
it may be
implemented in HyperTalk using just one recursive grep() XFCN
call
(v 3.1 by Greg Anderson):
上記の処理は複雑なように見えますが、実際は非常に簡単で単純な作業の集ま
りです。HyperTalk ではどのようにできるかを、再帰的（リカーシブ）な
grep() XFCN コールだけを使って示します (v 3.1 by Greg Anderson)：
get greptts("-") ---result is EITHER a verified list of subheads
or
--------------------titles OR empty --> the text cannot be a
setext
----a second greptts("=") call is required for detection of titles!
----text being verified is assumed to have been read into a global;
----it takes 6-8 seconds on an SE to verify a sample 44KB file
made
----up of 2 titles + 12 subheads incl. a few confusing non-subheads
この関数の結果は、見つかったサブヘッダー又は表題のリスト、又は何も見つ
からないかのいずれかです。見つからなければ、テキストはシーテキストでは
ありません。
表題があるかどうか調べるために、二度目の greptts("=")コールが必要です。
確かめているテキストは、グローバル領域に読み込まれているものと仮定しま
す。２つの表題、１２のサブヘッダー、そしてサブヘッダーではないが紛らわ
しいものもを幾つか含んだ４４ＫＢのサンプルファイルを検証するのに、ＳＥ
で６から８秒かかります。
function greptts ttchar ------------ttchar may be either "-" or
"="
global myText
get "^" &ttchar &ttchar --first grep pattern is
2 leading ttchars
put "[" &char offset(ttchar,"-=") of "=-" "e
~~ --second pass
&"!-,\./;<>-~]" into pattern -----is required to
account for this
get grep(v,pattern,grep(n,it,myText)) ---grep XFCN implementation
if it<>empty then return topicList(it,ttchar="=") else
return ""
end greptts --else: no RAW title/ subhead-typotags were encountered
----- ttcharは、"-" or "="のどちらかです。
----- 最初の grep パターンは、先頭の ttchar ２文字です。
----- この grep XFCN インプレメンテーションには、二番目のパスが必要です。
function topicList ttList,titleflag --controls type of verification
global myText
if char 1 to offset(":",ttList)-1 of ttList =1
then delete line 1 of ttList
put empty into verifiedList -----------initialize return
variable
if ttList<>empty then
repeat with i=1 to number of lines in ttList
get line i of ttList
put (char 1 to offset(":",it)-1
of it)-1 into ttptr
get length(word 2 of it) ----------------------------ttLength
put blankLess(line ttptr of myText)
into sString
if length(sString)=it then
put ttptr &","
after verifiedList
if param(2) then get
return else get pure(sString) &return
put it after verifiedList
end if
end repeat
end if
return verifiedList
end topicList
--- 検証の種類をコントロールします。
--- 戻り値を初期化します。
function blankLess aStr ----string stripped of trailing white
space
get space &numtochar(9) ---------------assign a space-tab
pattern
repeat with i=length(aStr) down to 1 -----to local
variable "it"
if char i of aStr is not in it then return
char 1 to i of aStr
end repeat
return empty
end blankLess
--- あとに続く空白が取り除かれた文字列
--- ローカル変数 it へスペースタブパターンを設定します
function pure aStr --string stripped of leading and trailing blanks
return word 1 to 99999 of aStr -----an arbitrarily large
value is
end pure -----decoded faster by HyperTalk than "number of words
in"
--- 先頭および後方の空白が取り除かれた文字列
--- HyperTalkでは、単語の数を指定するよりも、任意の大きな値を指定する
ほうが早く解読されます。
Administrivia update 920907
----------------------------
管理に関する更新 920907
There are now 61 (up from 35 in March) names on this mailing
list,
all of you who have expressed interest, future front-end writers
or setext authors/ publishers. I've heard of a few TidBITS
browsers having already been written in HyperCard, none of them
a
proper setext tool, however, but most probably decoders of some
of
the more easily-recognizable layout elements of it. I
hope that
the above example is enough to demonstrate that doing it properly
isn't all that more difficult than doing it in a quickie-hack
fashion.
このメールリストには、（３月の３５人から増えて）現在６１人の名前があり
ます。関心を示した人、将来フロントエンドを開発しようと考えている人、シ
ーテキストを使う著者又は出版者といった人達です。HyperCard で、TidBITS
用のブラウザが幾つかもう既に開発されていると聞きましたが、それらはどれ
１つとして、正しいシーテキストのツールではないでしょう。ほとんど間違い
なく、幾つかの比較的簡単に見分けがつくシーテキストのレイアウト要素を解
読する機能を持つものでしょう。正しく行えは、大急でハッカーのようなやり
方で行うよりも簡単であることを上の例が十分に示していることを期待します。
------------------------------------------> end of setext sermon
#1
edited <----- Ian Feldman
inquiries --> setext-list@random.se
------------> setext, the structure-enhanced text concepts document
(last changed Aug 1992; do not reorder if you already have seen
it)
may be requested by sending "setext" alone on the Subject: line,
no
quotes, empty message body to -----------> <fileserver@tidbits.com>
..
# From setext-list Mon Mar 30 00:06:05 1992
# From: Keepers
of The Setext Flame[tm] <setext-list@random.se>
# Date: Sun,
29 Mar 23:48:00 1992 +0100 (CET)
# Organization: random design -- any old TTY will do
# X-Bad-Address: no more mail to <not.bad.se> please
# Subject: two types of setext
(sermon #2)
ermons etexts
rmonse textse
monset extser
onsete xtserm
nsetex tsermo
setext sermon
================
920329 #2
Two types of setext
--------------------
２種類のシーテキスト
The fact that the format has been optimized for requirements
(and
vagaries!) of online-transported text publications can easily
lead
one to believe that all setexts are by necessity confined to
pure
ASCII (7-bit) text. Actually, it is not so. The
setext has been
named for what it is primarily about, structural enhancement
of
any text, not just that of the ASCII text. Therefore none
of the
typotags chosen for encoding of the structure either relies
on or
cares about whether the text being wrapped is of the 7- or 8-bit
variety.
オンライン配布でのテキスト出版の要求（と変転！）を考慮して最適化されて
いるので、すべてのシーテキストは必要上、純粋な ASCII (７ビット)に限定
されているという誤解を招かせるかもしれませんが、実際はそうではありませ
ん。シーテキストの主な目的は、ASCII テキストのみならず、どんなテキスト
でもその構造性を高めることにあり、それにちなんだ名が付けられています。
ですから、コード化して構造性をもたせる目的で選んだタイポグラフのどれ１
つとして、テキストが７ビットまたは８ビットなのかに影響されず、また関心
すら持っていません。
Both types of source documents can be made equally structured,
with the only difference being their final suitability for the
intended transport medium. If a setext is to be distributed
via
the 7-bit electronic mail then, of course, no other option remains
than to make sure that it contains nothing but ASCII characters.
On the other hand, if it's to become part of an otherwise encoded
package (such as a binhexed archive in which documentation files
have been setextized) or distributed solely through 8-bit-safe
means then there may be no clear-cut reason not to use the full
8-bit character set where so called for.
これら２種類のソースドキュメントは、目的の転送媒体のための最終的な適合
性が唯一異なる点ですが、同じ程度にまで構造化できます。シーテキストが、
７ビットの電子メールで転送される場合は、もちろん ASCII 文字以外は何も含
めないようにするしか選択の余地はありません。他方では、（ドキュメントファ
イルがシーテキスト化されているものを含んでいるバイナリーヘキサ化された
資料（アーカイヴ）のような）別な方法でコード化されたものの一部となる、
又は８ビットが保証された手段で送られる場合は、要求される場面での８ビッ
ト文字セットの使用を禁止する明確な理由はありません。
Other considerations
---------------------
その他の考慮
Once a decision has been reached to use 8-bit characters in
a
setext a possibility arises to keep the paragraph text unwrapped,
rather than folded uniformly at the 66th character mark.
After
all, if the setext is primarily to be displayed inside an editor,
rather than on an 80-character terminal screen, then there is
not
much sense in prior folding of the lines to a specific guaranteed-
to-fit-on-a-TTY-screen length. The editor/ word processor
program
will fit the unwrapped text to window or the available display
area, and might actually prefer to have to deal with whole unwrap-
ped paragraphs rather than with otherwise relatively-short lines.
シーテキストで８ビット文字を使用するという結論に達すれば、段落（パラグ
ラフ）テキストを６６番目の文字で一律に改行するよりは、改行しないでおく
という可能性が出てきます。要するに、シーテキストが主に、８０文字ターミ
ナルではなくエディター内部で表示される場合、予め特定の TTY 画面長に適
合させて改行を入れるのは無意味なことです。エディター又はワードプロセッ
サーは改行の無いテキストをウィンドウ又は利用できる表示領域に適合さるの
で、実際は比較的短い行よりも改行のない全段落を処理する方をこのむでしょ
う。
Most text-processing programs with native word-wrap capabilities
actually consider return-terminated lines to be paragraphs in
their own right. Thus, if a setext is not to travel via
email
anyway (because of it being distributed differently or making
use
of accented characters) then it might as well arrive in unfolded
state so that no extra time need be spent on making the paragraphs
"whole again."
ほとんどのワードラップ（自動改行）機能付テキスト処理プログラムは、改行
で終了してしる行は段落とみなします。ですから、（他の方法で配布される、
又はアクセント付文字を使用する理由から）とにかくシーテキストが電子メー
ル経由で送信されるのではない場合、改行なしの状態で届くほうが段落を元の
状態に戻すための余分な時間が必要ないので好ましいでしょう。
Do observe, however, that it is not the state of the paragraph
text that makes or breaks a setext. No, the sole criterion
of
whether a text is a setext is the presence of at least one
verified subhead, as described in sermon #1. Thus even
texts with
unfolded paragraphs (i.e. terminated by carriage returns, equal
to
lines in HyperTalk that can be up to 30000 characters in length)
are setexts if they contain at least one subhead-tt.
しかしながら、シーテキストであるかないかを決めるのは段落の状態ではない
ことに注意してください。テキストがシーテキストかどうかを決める唯一の条
件は、第１説教で詳述したように正しいサブヘッダーが少なくとも１つ存在す
ることです。ですから、（改行で終了しており、長さが最大30,000 文字まで
可能な HyperTalk の行に匹敵する）改行のないテキストでも、サブヘッダー
タイポタグ (subhead-tt)を一つでも含んでいれば、それはシーテキストです。
The sole mechanism used in setext to encode which of such lines
are in reality paragraphs (as opposed to those that shouldn't
be
folded mechanically) is the character indent. In fact,
after the
subhead-tt the second most important typotag is the indent-tt,
made up of exactly two space characters, which denotes any such
indented lines as ready-candidates for reflowing by so inclined
front-ends (either on their own or as part of like-indented
lines
above and below it). So any potentially-long line of a
setext
that has been indent-tted will be understood (by any validated
setext front-end) as to be ready for wrapping-to-length if so
required.
シーテキストで、（機械的に改行してはいけない行に対して）改行のないテキ
スト段落であることをコード化する唯一の方法は、文字インデントを使うこと
です。実際、サブヘッダーに次いで二番目に重要なのは、空白２文字からなる
インデントタイポタグで、その様にインデントされた行（それ自身、或いはそ
の行の前後で同じくインデントされた複数行の一部として）を流し込み処理の
準備が整った候補だとフロントエンドへ知らせます。ですから、インデントタ
イポタグ付きシーテキストの長い行はすべて、必要なら長さに合わせて自動改
行されていいものと（正当なシーテキスト用フロントエンドによって）解釈さ
れます。
An example of unwrapped paragraph
----------------------------------
改行のない段落の例
For instance, this paragraph has specifically been unfolded
to demonstrate
the validity of the concept: indent-tted, yet still-unwrapped line
in a setext
piece makes it into a paragraph of its own. Depending on the
type of the
terminal software at your end it will most probably be folded at some
"mechanical 79-th character mark" and fill the available window's width.
Imported into a word processor it will end up word-wrapped and thus
become
easy to add to or delete from, since the program will simply reflow
the whole
"multi-line" paragraph as needed. And yet this paragraph, made
up of 5
sentences, 1037 characters in all, is in reality just one long line
of text
with a sole carriage return terminating character at end. Please
observe that
the initial (and _sole_) indent-tt in this paragraph makes a nice mark
of
where the subhead ends and the paragraph begins. Not even badly-
written
reflowing routines will fail to notice that a piece of text is indented,
and
therefore, most probably, not part of other text around it.
例えば、この段落は、インデントタイポタグ概念の妥当性を実例で明らかにす
るために、特に改行は付けていません：シーテキストの中で、インデントタグ
が付いてはいるが改行されていない行そのものは段落となります。使用してい
る末端ソフトウェアの種類に依存しますが、恐らく機械的に７９番目辺りの文
字を目安に改行され、そして使用できるウインドウ幅全長に適合されるでしょ
う。ワードプロセッサーで表示する場合、改行（ワードラップ）される結果と
なり、プログラムは必要に応じて”複数行からなる”段落全体をただ単に流し
込みなおせばいいので、結果として追加削除がしやすくなります。この段落は、
５つの文からなり合計で1037文字ありますが、実際は最後に一つだけ改行終結
（ターミナル）文字が付いた長い一行のテキストです。この段落の最初の（そ
して唯一の）インデントタイポタグ (indent-tt)は、サブヘッダーがどこで
終わり、段落がどこから始まるかを示す適切な印しとなっていることに注意し
てください。下手にコーディングされた流し込みルーチンでさえ、そのテキス
トはインデントされているから、ほとんど間違いなくその近くにある他のテキ
ストの部分ではないことを理解できるでしょう。
Primary setext-type distinction
--------------------------------
主なシーテキストタイプ識別
Still, if all the texts that fulfill the sole basic validated-
subhead requirement are to be considered setexts then the need
arises to distinguish between the "pure" variety of them, the
_rigidly_formatted_ ones encoded for 7-bit transport duty (=no
accented characters AND with ready-folded paragraphs), and all
the other ones. Indeed, this important point has also
been
addressed.
それでもやはり、基本的なサブヘッダー条件をただ１つ満たす全てのテキスト
がシーテキストだとみなされた場合、”純粋な”シーテキスト、即ち７ビット
転送のためにコード化されている、厳密にフォーマットされたもの（言い換え
れば、アクセント付き文字を含まず、段落はあらかじめ改行されている）とそ
うでないものを区別する必要が生じます。実際、この重要な点も取り組まれて
います。
As originally explained, setext documents in online distribution
should be denoted by the ".etx" suffix (which stands for both
"emailable" and "enhanced text.") In reality this suffix should
ONLY be used for the rigidly-formatted, "pure" setexts, as is
the
case with TidBITS that carry it at sumex and elsewhere.
All the
other setexts, either the not-fully-7-bit ones, or those with
unfolded paragraphs (as the one above) **may** carry a more
common
".txt" suffix, but not an ".etx" one. They are setexts
too but as
they definitely are _not_ guaranteed to fare well in electronic
mail transport then their titles should not signal that special
"setext.etx" status either (to readers and front-ends that are
aware of the distinction). It is enough that their titles
be
indicative of them being simply "text_documents.txt."
最初に説明したように、オンラインで配布するシーテキストドキュメントは、
（電子メールで使用できる、及びエンハンスドテキストの両方を意味する）拡
張子 ".etx"を使って示します。現実には、Sumex 等で TidBITS が使用するよ
うな、厳密にフォーマットされた、"純粋な"シーテキストだけがこの拡張子を
使うことができます。完全に７ビット化されていないものとか（上の例のよう
な）改行のない段落を含むもの、その他の純粋でないシーテキストは、より一
般的な拡張子".txt"を使い、".etx"を使ってはいけません。それらもシーテキ
ストですが、電子メール送信で問題が起こらない確かな保証はないので、（区
別を理解している読者またはフロントエンド）に 特別な"setext.etx"ステー
タスを示す名を用いるべきではありません。それらの肩書きは、単に"text_
documents.txt"と表すだけで十分です。
Therefore: fully 7-bit/ 66-char-folded setexts may carry the
.etx
suffix. All the other setexts: .txt ONLY suffix, please,
as does
this issue of the sermon (on account of the unwrapped paragraph).._.
ですから、完全に７ビットで６６文字改行のシーテキストだけが、拡張子".etx"
を付けることが許されます。その他のすべてのシーテキストは、どうか（改行
のない段落のために）この説教がそうしているように、拡張子".txt"を使用し
てください。
Change of topic: delete functions
----------------------------------
話題を変えて：削除機能
Akif Eyler, <eyler@trbilun.bitnet>, who's adapting an existing
document browser for setexts (a MacApp hack) writes on the subject
of by me suggested point to allow selective deletion of parts
of a
browsed setext:
Akif Eyler, <eyler@trbilun.bitnet>,（マックアプリケーションのハッカ
ー）、彼は既存のドキュメントブラウザをシーテキスト用に書きかえています、
はブラウズしているシーテキストドキュメントの（選択による）部分削除を許
可するという私の提案に関して書いています：
> We are talking about a browser, not an editor. I don't think
> text modification should be allowed here.
話題にしているのはブラウザであって、エディターではないので、テキストの
修正はここでは禁ずるべきです。
This is an important point that deserves a little more comment
than that. I believe that we may be talking about two
different
things. Although it is true that a "browser" is basically
an
application for structured paging of text there is nothing to
prevent such applications from offering additonal services that
may be appropriate or of great value to its users.
もう少し注釈を要する重要な点です。我々は、２つの異なった事について話し
ているのだと思います。ブラウザは、本質的にテキストを構造化してページ化
するためのアプリケーションですが、そのようなアプリケーションがユーザに
とって適切な、または大変価値のある追加的サービスを提供するのを妨げるも
のは何もないと思います。
So while technically we both may be right, in this respect, when
speaking of "browsers", I mean "setext tools" rather than the
more
traditional, straigh-browse-function-only, implementations.
ですから、技術的な点では双方とも正しいのですが、一方ブラウザについて言
うとき私は、この点でより慣例となっている、純粋なブラウザ機能だけのイン
プレメンテーションではなくシーテキストツールを意味します。
You should keep in mind the basic difference between a traditional
browser, designed for navigation in a potentially VERY LARGE
data
mass and that of a setext front-end, meant to be used with texts
of limited size (<50K or so). Such short texts are
inherently
easier to read without assistance of any special tools, even
if
using one is to be recommended. But let us not believe
that
people will start using a browser only because one is available.
After all, a "typical" setext might contain 20-odd "pages" of
text, which are not that hard to browse using the standard ways
and means of ANY application (scrollbars on the Mac etc).
多量なデータ内でのナビゲーションの可能性を考慮してデザインされた従来の
ブラウザとサイズ制限（約５０ｋ以下）があるテキストで用いられるシーテキ
スト用フロントエンドの基本的な違いを心に留めておくべきです。このような
短いテキストは、使用するように推奨している場合でも、特別なツールの助け
なしに見るのは本質的に簡単なことです。手近にあると言う理由だけで人はブ
ラウザを使い始める、と信じ込むのはやめましょう。結局、”典型的な”シー
テキストは２０頁余りのテキストを含んでおり、どんなアプリケーションであ
れ標準的な方法と手段（Mac のスクロールバー）を使ってブラウズするのは難
しいことではありません。
For that reason alone I feel that setext browsers should offer
a
few other facilities in order to make using them worthwhile
to the
users... with the prime among such values-added functions
being a
method to delete portions of read setexts, in as simple a manner
as possible. Please bear in mind that setexts are not
guaranteed
to survive editing at the receiving end anyway and that the
format
as such is intended mainly for periodic online publications.
And
what do we do with interesting articles in print magazines?
We
clip them out and discard the rest. Thus an easy delete
function
wouldn't entirely be out of place in a browser used for reading
of
periodic, time-topical online publications etc (no doubt it
would
be an unwanted feature when browsing of [large] _reference_
works
etc).
この理由だけでも、シーテキストブラウザは、ユーザにとって価値のあるもの
とするため、その他幾つかの機能（そのような付加価値機能の主なものとして、
できるだけ簡単な方法による、読み込んだシーテキストの部分的削除機能）を
提供するべきだと思います。いずれにしても、シーテキストが受け取った側で
編集後もシーテキストのフォーマットを維持できている保証はないこと、及び
シーテキストのようなフォーマットは定期的なオンライオン出版が主な目的で
あることを憶えておいてください。印刷雑誌の中に興味ある記事があればどう
しますか？その記事を切り抜き、残りは捨ててしまいます。ですから、簡単な
削除機能は、（確かに、[膨大な]参照物をブラウズする場合は、望まれない機
能でしょうが）、定期的、時節的話題のオンライン出版等の閲覧用に使われる
ブラウザでは、全く場違いというわけではありません。
So what constitutes such an "Easy-Delete"? In my view a browser
should allow _unobtrusive_ deletion of text in either or both
of
the following ways:
ではその様な「簡易削除機能」を構成するもののは？ 私の考えでは、ブラウ
ザは次の方法の何れか、或いは両方で、テキストの目立たない削除を許すべき
だと思います：
(a) a whole current topic may be flagged for deletion. That does
not take place until browsing of the setext is terminated,
however (by reading in of another setext or closing
of the
application), at which time the originally-read-in
setext gets
written back to disk less the flagged portions.
It goes without
saying that such flagging actions should be undoable
before the
rewritting takes place. The latter should
happen automatically,
without prior and explicit replace-confirmation?
dialogs.
現在の全トピックを削除するようにフラグ付けできる。削除は、シーテキスト
のブラウズが終了するまでは行われない。しかしながら、（他のシーテキスト
の読み込み、又はアプリケーションの終了により）その時点で読み込まれてい
たシーテキストは、フラグ付けされた部分を除いたものがディスクに書き込ま
れる。言うまでもなく、このようなフラグ状態は、書き込みが行われる前なら、
元に戻せる（undoできる）べきです。後者は、明白な置き換え確認？ダイアロ
グなしに自動的に行うべきです。
(b) selected text-chunk onscreen may simply be deleted by pressing
the delete or clear keys. It should disappear
from the display
at once but _could_ be removed from file first upon
termination
of the browsing-of-current-setext operation (as
per above).
This function does not have to be undoable as the
text may be
preserved by reading-in of it once again.
スクリーン上で選択されているテキスト部分は、単に削除またはクリアーキー
を押す操作で削除される。その部分は、直ちに表示から消えるべきですが、（上
記に従って）現在のシーテキストのブラウザ操作が終了した時にはじめてファ
イルから取り除くことができる。この操作は、もう一度同じテキストを読み込
みなおせば元に戻せるので、元に戻す（undo)機能は要求されない。
I.e. the browser keeps track of opened file(s) and if one such
is
opened again then it simply forgets about any queued selective
deletes in current text and replaces the contents of the buffer
with a clean copy from the disk.
即ち、ブラウザは、開かれているファイル（複数可）を見失うことなく管理し、
もしどれか１つが再オープンされた場合、そのテキストで待ち状態の選択削除
に関してはただ単にすべて無効とし、ディスクからのきれいなコピーでバッファ
ーの内容を書き換えます。
As above, no explicit confirmation should be required first.
If
you delete something then you delete something, and there should
be no need to explain it once again to the machine that you
did it
on purpose. On the other hand care should be taken to
prevent
inadvertent destruction of browsed setexts, perhaps by requiring
that selection of text be made with the option (or command)
key
pressed down, or that Command-Delete be required to flag a whole
topic for removal. On top of that the really-important
documents,
those not intended to be rewritten during browsing, should be
kept
locked on disk anyway.
上記のように、明示的な確認は必要ないでしょう。何かを削除する場合、それ
を実際に削除するのだから、再び意図的に削除したことをマシーンに説明する
のは必要ありません。これに反して、テキストの選択はオプション（又はコマ
ンド）キーを押して行う、或いは除去対象の全トピックのフラグ付けにはコマ
ンド削除を要求するなどして、ブラウズ中のシーテキストを不注意に破壊する
ことがないように気を配るべきです。いずれにしろ、ブラウズ中に書き換えさ
せない重要なドキュメントは、ディスク上でロックした状態に保つべきです。
------------------------------------------> end of setext sermon
#2
edited <----- Ian Feldman
inquiries --> setext-list@random.se
------------> setext, the structure-enhanced text concepts document
(last changed Aug 1992; do not reorder if you already have seen
it)
may be requested by sending "setext" alone on the Subject: line,
no
quotes, empty message body to -----------> <fileserver@tidbits.com>
..
# From: ianf@random.se (Ian Feldman, Keepers of The Setext Flame[tm])
# Newsgroups: alt.hypertext (complete, original headers at end of file)
# Date: Fri, 23 Apr 93 07:53:50 +0200
# Message-ID: <a7fd5104@random.se>
# X-URL: file://garbo.uwasa.fi/mac/tidbits/setext/setext+sgml_01.etx
# Reply-To: setext-list-request@random.se
# Organization: random design -- "Opinions, cheaply"
# Lines: 349
# Summary: setext is to plaintext as RTF is to RTFM
# Subject: Re: Looking for Electronic Publshing formats... [long]
SGML vs setext
================
by Ian Feldman_
Having fathered and mothered_ setext, the structure-enhanced
text
markup method designed for use primarily by _smaller_ periodic
online publications, I feel compelled to clarify certain miscon-
ceptions in regard to in this forum expressed doubts as to its
usability as an electronic hyper?text interchange format.
Please
observe the ambiguity of the subject of this debate: the original
query_ was about "electronic formats for printed materials"
for
deployment in a multi-format browser using "Amiga's system of
DataTypes to provide content-independent methods of viewing
data"
(both quotes author_ verbatim).
主に短い定期的なオンライン出版で使用する目的でデザインされた構造性を高
めたテキストマークアップ方法であるシーテキストを生み育てた者として、シ
ーテキストが電子ハイパーテキスト交換フォーマットとしての使用に耐えうる
かどうかに関してこのフォーラムで出された疑念にまつわるある種の誤解をはっ
きりさせることを余儀なくされたと感じています。どうか、この討論している
話題そのものが曖昧なものであることに注目してください：もともとの問いは、
”コンテントに依存しないデータ閲覧方法を提供する目的で、Amiga DataType”
を使ってマルチフォーマットブラウザで使用するための”印刷資料用電子フォ
ーマット”に関するものでした。（引用は著者の言葉どうりのものです。）
In time the discussion has come to be centered around SGML's
alleged superiority, inevitability and, to a lesser extent,
of the
setext being or not being a viable solution for online-distributed
matter. Having read just the basic introductory document
about
it, meant to provide the public at large with an easily-palatable
foundation, Eliot Kimber_ of IBM has declared_ it to be "a very
primitive, obviously easy to implement and interchange."
やがて論争はＳＧＭＬのいわゆる優越性と必然性に、そして少ない割合でシー
テキストがオンライン配布物のための効果的に機能するソリューションとなり
うるか否か、に変わってしまいました。一般の人々にも簡単に分かる基礎を提
供することを目的としたシーテキストの基礎的な前置き資料を読んで、 ＩＢＭ
の Eliot Kimber はシーテキストは”非常に幼稚なもので、明らかにインプレ
メンテーションや交換は容易いだ”と断言しました。
Admittedly, limited it may be, but 'primitive'? Anything judged
through the prism of the SGML will by definition appear primitive
(although the setext ALSO readable) to the naked eye.
In
contrast, SGML et al judged through the bias of human-readable-
text/ ASCII will appear unduly complex and mostly inaccessible
to
anyone having but the lowest common denominator hardware/ software
at their disposal (80% of all users? 90%?) Sure, everybody should
have a Corvette... er, a SparcStation_ I mean, but as
long as not
everybody does we might just as well judge the setext on its
own
merits.
正直なところ、シーテキストの適用範囲は制限されているかもしれませんが、
”幼稚な”とは？ ＳＧＭＬのプリズムを通して判断されれば、どんなもので
も定義上幼稚に見えるでしょう、（もっともシーテキストは肉眼でも読めます
が）。対照的に、人が読めるテキスト/ASCIIという観点で判断した場合、ＳＧ
ＭＬなどは過度に複雑で、最少共通項的な機能しかもたないハードウェアとソ
フトウェアしか自由に使えない者（全ユーザの８０％？ ９０％？）にとって
はほとんどアクセスできないように思われます。確かに、みんなコルベットを
持っていればいいのですが、つまりスパークステーションを持っていればいい
のですが、みんながそれを持っているのでない以上、理非曲直によってシーテ
キストを判断するほうがよいでしょう。
Eliot Kimber_ has many interesting things to say about the SGML,
data-notations_limits_ and markup methods in general, any of
which
I couldn't agree more fully with. However, he also seems
oblivious
to the loopsided logic present in this his advocated solution_
(here taken out of context but not misrepresentative of the
whole):
Eliot Kimber は、ＳＧＭＬ、データ表記法の限界、そしてマークアック方法
一般について興味深いことをたくさん述べています。それらについては全く同
感です。しかしながら、彼が支持する解決案には湾曲した論理がり、そのこと
は彼にも明白だと思われます。（下の文は文脈から抜き出したものですが、全
体をゆがめて伝えてはいないと思います）：
> simply add a layer between the source and the presentation
> system that translates the SGML source into setext dynamically:
> SGML Source --> SGML2SETEXT --> setext --> setext viewer
ただ単に、ＳＧＭＬソースをシーテキストへダイナミックに翻訳するプレゼン
テーションシステムとソースの間に一つの層を追加すれば良い：
It strikes me as no little ironic that in order to view enhanced
plaintext (i.e. the setext) in a basic-structured manner, say
an
outline of the submitted text, one would have to first encode
it
with SGML, then pipe it through a filter with a DTD acronym
thrown
in for a good measure. I'd have thought that, if setext
is deemed
adequate for some particular job, then surely it wouldn't have
to
be arrived at via the SGML-encoding route. In fact, and
if I may
contribute something of a truly-heretic nature, I'd have thought
that the opposite would be an altogether more-agreeable solution:
例えばこのテキストのアウトラインでもいいのですがこのような、基本的な構
造を持たせる仕方で構造性を高めた単純なテキスト（即ちシーテキスト）を見
るためにまずＳＧＭＬでコード化し、続いてＤＴＤ接頭語がたっぷりと書き入
れられたフィルターを通しパイプしなければならないのは少なからず皮肉なこ
とだと私には思われます。もしシーテキストがある特殊な目的で十分役立つも
のと考えられる場合、まさかＳＧＭＬエンコーディング経由でなくてもよさそ
うなものですが。実際、もし仮に全く異説的な助言を与えるとすると、正反対
の方が概してより快く同意できるソリューションだと考えたことでしょう：
plaintext --> setext --> setext2SGML --> SGML viewer
Obviously, Kimber has all the resources at his beck and call
and
expects that others will have them too. We may all yearn
to become
1Mbit/sec-access high-flyers of the Internet, but in the meantime
many of us have to make do with but Have-A-Mac and never enough
funding to equip it with enough RAM to satisfy our needs.
明らかに、 Kimber は彼の思い通りになるリソースをすべて持っており、他の
人も彼のようだと思っています。みんな 1Mbit/秒でアクセスできるインター
ネットの才物になろうとあこがれるでしょうが、我々のほとんどは、”ただ単
にマックを所有している”ことで我慢し、必要なＲＡＭを準備する資金も十分
にあるわけではないのです。
setext in multimedia
----------------------
マルチメディアでのシーテキスト
The originator of this debate, Greg R Block_ further had this_
to say:
この討論の発起人である Greg R Block は、更にこうも言っています：
> : For the moment, setext appears to me to be the most practical
> : (universal, useable, general consumption) standard around for
> : textual documents.
さしあたり、シーテキストはテキストドキュメント用の最も実用的（一般的、
有用な、一般消費的）なスタンダード（標準）です。
> But ONLY for textual documents, and that is where part of the
> problem lies. SGML's advantage is that it can structure things
in
> definite ways, and embed things that are not necessarily text.
しかしシーテキストの問題の一部は、対象がテキストドキュメントだけだとい
うことです。ＳＧＭＬの利点は、的確な方法で構造化できテキスト以外のもの
でも埋め込むことができることです。
Let me respectfully suggest that anyone claiming that setext's
use at best starts and ends with ASCII text had obviously not
done their homework. Those of you familiar with the NewsGrazer_
newsreader on the NeXT may recall that the data format there
employed is that of uuencoded richtext article _prepended_ by
ASCII version of the text of same. This enables it to
propagate
normally along the net, display as richtext on other NeXTs and
the relevant, _top_portion_of_it_, in plain elsewhere.
Had the
ASCII portions of it been setextized it'd allow it to provide
an
additional, more universally parseable, dimension of structure.
So _potentially_ setext is as valid an encapsulation method
for
distributed-multimedial use as may be the RTF, SGML and the
others. But unlike the others the text content of it will
ALWAYS
remain readable to the unaided eye while still offering limited
--but hardly "small"-- amounts of extractable structure.
シーテキストの用途は ASCII に始まり ASCII で終わると言う人は明らかに宿
題をやっていないと言わせて頂きたい。NeXT の NewsGrazer ニュースリーダ
ーに精通した人は、そこで使用されているデータフォーマットは、 uuencode
されたリッチテキストで、同じ内容の ASCII テキストを前に付加したものだ
ということを思い出すでしょう。これで、ネット上を正常に転送でき、NeXT上
ではリッチテキスト、それ以外では先頭部の単純テキスト部分を表示できます。
もし ASCII 部分がシーテキストでフォーマットされていれば、さらに一般的
な要素分析（パース）が可能な構造次元を一つ加えることができるでしょう。
ですから、シーテキストは配布用マルチメディア使用のためのカプセル化方法
として、ＲＴＦ、ＳＧＭＬ等と同じくらい効果的である可能性を秘めています。
しかし他と異なりシーテキストのテキストコンテントは、限られた（しかし決
して少なくはない）抽出可能な構造情報を提供している一方で、いつもでも肉
眼で読むことができます。
Nor has potential for use of setext in hypertext been overlooked.
While arguably providing only one dedicated tag for linking
of
(text) elements_, the concept that it follows resembles closely
the format employed by WorldWideWeb's email_server_ (unbeknownst
to one another, the WWW team and I have arrived at similar
solutions of verbose anchors in text referenced by expanded
URLs_
or comments at _end_ of documents). In this fashion even
when
viewed in unenhanced state the "administrivial" linkage data
need
not encroach upon the content of the document itself.
ハイパーテキストの中でのシーテキストの使用の可能性も見落としてはいませ
ん。論証上、（テキスト）要素のリンク専用に１つのタグしか用意されていま
せんが、その概念は、WWW (World Wide Web) の電子メールサーバで使用され
ているフォーマットとよく似ています。（お互いに気づいていなのですが、WWW
チームと私は、展開されたＵＲＬによって参照されるテキスト中のバーボウス
アンカーソリューション、又はコメントをドキュメントの最後に置く解決策に
到達しました。）このやり方だと、構造性を高めていない状態で見たときでも、
”管理しやすい”リンクデータがドキュメントそのもののコンテントに押し入
ることはありません。
Philippe-Andre Prindeville_ adds_ this:
Philippe-Andre Prindeville は次のように加えています：
> SGML allows one to put wrappers on data-types that SGML itself
> isn't capable of parsing. This shows a reasonable amount of
> forethought (wish certain "commercial" standards had half a mind
> to do so). We obviously can't foresee all possible media types.
> But we can plan for their advent.
ＳＧＭＬは、要素分析できないデータ型にはラッパー（カバー）を付けること
を認めています。これは将来への適度な配慮を示しています（ある種の”営利
本位の”スタンダード（標準）がこの半分でもそうする気があればと願うしだ
いです。可能なすべてのメディアタイプを見越すことが不可能なのは分かりきっ
たことです。しかしそれらの到来に先立って計画を立てることは可能です。
Ditto for the setext... no limits on encapsulated data
types.
Anything that can be encoded in transportable manner may be
appended last after the human-readable portion of a document
and,
optionally, made into by-default-in-setext-viewers suppressed
matter (in three different ways). Yet, although a dedicated
browser is always a preferable solution, setexts do not
automatically _require_ one in order to be viewable. This
in
marked [sic!] contrast to the in the SGML_FAQ_0.0_ expressed
statement:
シーテキストも同様に、カプセル化されたデータ型に関する制限はありません。
転送できる方法でコード化されたものは何であれ、肉眼で読めるドキュメント
部分よりも後ろの後部に追加でき、そして随意に（３種の異なる方法で）シー
テキストビューアがデフォルトで隠すことができる部分にすることができます。
専用ブラウザが常に望ましいソリューションですが、シーテキストは閲覧のた
めの専用ブラウザを必ずしも必要としているわけではありません。これは、
SGML FAG 0.0で述べられている内容と比較したときの著しい相違です：
# <A>99% of the fun with SGML can be had only with a parser,
# so you do need one.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
パーサー（要素分析するもの）だけでＳＧＭＬの面白さの９９％は味わえます。
ですから、パーサーが１つ必要ですよ。
A thought or two
------------------
一考 or 二
If past experiences are anything to go by, the biggest obstacle
to
wider acceptance of the setext seems to be a common inability
to
think in terms of other document models than those indented
for
paper printout. Surprizingly many people, even among the
_hypertext.rules_ community, seem unawares that they **really**
are subconsciously thinking of text ending up on paper, rather
than (and despite any usual claims to the contrary of) that
of
all-electronic delivery and "consumption." That and a second,
equally-common misconception, that anything that's understandable
also must be primitive, thus defacto unusable for the higher
task
at hand, whatever the latter may be.
過去の経験があてになるとすれば、シーテキストが幅広く受け入れられるうで
の最大の障害は、用紙印刷を目的としたもの以外のドキュメントモデルの見地
で物事を考えることが一般的にできないことだと思われます。驚くほど多くの
人々が、ハイパーテキストが支配する集団においてでさえ、**実際**テキスト
は最終的には電子配布及び”電子消費物”ではなくむしろ（その逆だと指摘す
るための通例の主張にもかかわらず）紙の書類になると無意識に思いこんでい
ることに気づいていないようです。二番目に、同じくらい一般的な誤解は、理
解できるものはすべて単純なものなので、手近にある重要（高度）な仕事（そ
れが何であれ）には事実上使えないに違いないと思い込んでいることです。
As an extra service for the diagram-und-table individuals among
yourselves here is an off-the-cuff attempt to summarize some
of
setext's attributes in relation to those of SGML and RTF.
Not an
expert on either one of these I ask for your forgiveness should
I
happen to have misrepresented something.
これは、図と表を好む人のために特別に、ＳＧＭＬ及びＲＴＦ属性に関連させ
てシーテキスト属性の幾つかの要約を非公式に試みたものです。ＳＧＭＬ及び
ＲＴＦの専門家ではないので何か誤って伝えていることがあるとすればお許し
ください。
Easy-O-Meter[tm]
-----------------
容易さの度合
______________ ___________ RTF ___________ SGML
__________ setext
basic document flat file with an entity made
any text file
model
embedded typo- up of definable interspaced by
graphic /tags logical elements subheads (also
and no sense of denoted by rigid other unobtrusive
syntaxt (format syntax and un- optional elements
proprietary) ambiguous <tags> may be employed)
-------------- --------------- ----------------
-----------------
基本的ドキュメン 埋め込まれたタイ 厳密な構文(シンタ
サブヘッダーを含ん
トモデル ポグラフィック/
クス)と明瞭な<タグ だテキストファイル
タグ付きの平面フ タグ>で示される定 なら何でもよい
ァイル、そしてシ 義可能な論理要素か (更に、他の目立た
ンタックス(構分) らなる物
ないオプション的要
を全く解さない。
素も使用可能)
(書式の所有権あり)
generalized
no
YES
yes
markup?
-------------- --------------- ----------------
-----------------
広汎性マークアッ いいえ
”はい”優れている はい
プ？
primary richtext
machine-assisted bringing order to
objective interchange
large-scale amorphous online-
format text
processing distributed data
-------------- --------------- ----------------
-----------------
主な目的 リッチテキスト
機械の助けを借りた 無定型なオンライン
交換フォーマット 大規模なテキスト処 配布データを順序づ
理
ける
papercopy-as
YES
yes
NO
ultimate-
and
-objective
noo
document model
-------------- --------------- ----------------
-----------------
用紙コピーが最終 はい
そうであり、またそ いいえ
目標であるドキュ
うでない
メントモデル
smallest a character
a character a word
emphasis (multistyled)
(multistyled) (single style)
granularity
-------------- --------------- ----------------
-----------------
最も小さい強調粒 １文字(マルチス １文字(マルチスタ
１語
子度
タイル化可能) イル化可能)
(単一スタイルのみ)
type of tags /descriptor
<start> <\end> _this_ and ~that~
# employed ?
unlimited # 2 + 11 optional
-------------- --------------- ----------------
-----------------
タグの種類 /記述子
<start> <\end> _あれ_~これ~
使用タグ数 ？
無制限
２＋オプションの１１
#typographical a finite set unlimited
set 3 typographical
tags employed?
1 hypertextual
-------------- --------------- ----------------
-----------------
使用できるタイポ 有限数
無制限
タイポグラフタグ：３
グラフタグの数
ハイパーテキストタグ：１
tag overhead +25%?
+30%?
+9% (verified)
-------------- --------------- ----------------
-----------------
タグオバーヘッド +25%?
+30%?
+9% (確認済み)
parser/browser
yes
YES
no
required
-------------- --------------- ----------------
-----------------
パーサー/ブラウ 必要
絶対必要 いいえ
ザが必要？
encoder
no
YES
no
required but recommended
but would be nice
-------------- --------------- ----------------
-----------------
エンコーダー(コ いいえ、しかし推 絶対必要
いいえ、
コード化ツール) 奨しています。
しかしあれば役立つ
が必要？
でしょう
availability many commercial a few commercial
a free browser
of tools readers
full-scale for the Macintosh
a few authoring implementations several end-user
implementations 1 known Windows implementations
a few freeware free browser + 1 PC/ unix parser
resources free source code
engine undergoing
parser/ browser tests
-------------- --------------- ----------------
-----------------
ツールの入手は可 市販のリーダーが フル装備の市販イン
Macintosh用フリー
能？
多数
プレメンテーション ブラウザが1つ
オーサリングイン が数種
エンドユーザインプ
プレメンテーショ 既知のWindows用フ レメンテーションが
ンが数種
リーウェアブラウザ 数種
フリーウェアのリ が１つとフリーのソ テスト段階のPC/
ソースが数種 ースコードパーサー
Unix用パーサエン
/ブラウザが１つ ジン
installed predominantly
professional/ 50,000-100,000
base
word processors large, always weekly readers
(under Windows) requiring
predominantly Mac
93-04-23 MS Word native
dedicated tools growing fast
============== =============== ================
=================
インストールされ 主に(Windows用) 専門家用/多数、
５万から百万の週ぎ
るベース ワードプロセッサ
専用ツールが常に め読者
MS Wordの標準機能 必要
主に Mac 使用
読者数は急速に増加
１９９３年4月２３日
中
Wrapping it up in more ways than one
--------------------------------------
複数の方法でフォーマットする
As an afterthought: it may come as a surprize to everyone that
the
SGML <FAQ version="0.0" date="1991-12-15">, penned by Erik
Naggum_
comes up in the Easy View browser for the Mac with certain of
its
elements emphasized as underlined richtext (version 2.3.1 of
the
EV, as yet being debugged, do not ask for a copy, please).
Why is
it so, you may wonder, has Erik been forced to employ some
``bastard'' format because SGML wouldn't do? No, of course not.
Erik, at the time of writing it definitely oblivious of the
very
existence of setext, has simply seen the need to add _visible_
emphasis to a FAQ intended for wide distribution, in a fashion
that's commonly used on the net.
あとから思い付いたこと：Erik Naggum が書いている SGML <FAQ version=
"0.0" date="1991-12-15">で、マック用 Easy View ブラウザ内で下線付き
リッチテキストとして特定要素の強調化を提案しているので皆さん驚いたかも
しれません。（EVのバージョンは2.3.1で、まだデバッグが必要です。どうか
コピーを要求しないでください。） どうして？、ＳＧＭＬが役に立たないの
で、Erik は”粗悪な”フォーマットを使用するよう強いられたのかと、不思
議に思っているかもしれませんが、決してそうではありません。EVを開発して
いる時点でシーテキストの存在は確かに明らかだった Erikは、広い範囲の配
布を目的とした FＱＡへビジュアルな強調を、インターネットで一般に使われ
ている方法で、追加する必要性をただ単に感じたのです。
The setext neither has ambition nor makes any claims to be a
"revolutionary" markup method -- whenever it was possible I
had
formalized the best of the current online usage and called it
setext typotags this-and-that. Thus this SGML_FAQ_ has
defacto
been _enhanced_ in its plaintext state with no extra explicit
encoding overhead. Now and then I also see on the net
examples of
what I'd call spontaneous-setexts, texts subdivided with valid
setext subheads and title elements by their makers with no
apparent knowledge of it whatsoever. If neither of this
provides
a strong argument for _usability_ of the method as such then
I
don't know what else might do.
シーテキストは、野心もなけれは”革命的な”マークアップ方法だと主張して
いるのでもありません。可能な限り、現在のオンライン使用で最良のものを形
式化し、そしてシーテキストタイポタグ”なになに”と名付けました。ですか
ら、この SGML FAQ は、事実上単純なテキストのまま余分な明示的なコード化
のオバーヘッドなしに構造性が高められています。私が自発的なシーテキスト
と呼んでいる、シーテキストの明白な知識のない者が作ってはいるが妥当なシ
ーテキストサブヘッダーと表題要素で再分されたテキストのサンプルをネット
上で時折見かけます。この事実以上に、シーテキストのような方法の有用性に
関する強力な証明を私は知りません。
Yes,
------
はい
this posting is a setext (the word stands both for the method
and
a single structure-enhanced text). Had you been reading
it in a
dedicated mail shell_ or newsreader_ you could have been presented
with something akin to:
この郵送物は、シーテキストです。（この言葉は、方法そのもの及び構造性の
高められたテキストの両方を意味します。）専用のメールシェル又はそれと同
類のものとして贈られたニュースリーダーを使って読みましたか：
(306) "Re: Looking for Electronic Publshing formats..." (Ian Feldman,
Keep...
-----------------------------------------------------------------------------
返信：電子出版用フォーマットを探しています
SGML vs setext <0>
setext in multimedia <1>
A thought or two <2>
Easy-O-Meter[tm] <3>
Wrapping it up in more ways than one <4>
Yes, <5>
and then been able to access its parts in non-linear fashion.
If
nothing else then at least the setext has a capacity to provide
unambiguous yet unobtrusive _anchors_ within texts that are
supposed to be universally accessible everywhere. WWW, WAIS_
and
Gopher people please take note.
次に、非線形的なやり方でテキストの部分をアクセスできました。シーテキス
トは、少なくともどこからでもあまねくサクセスできると考えられるテキスト
内で、明瞭だが見立たないアンカーを提供する機能を有しています。WWW、WAIS、
Gopherの関係者は注目してください。
There are other markup formats and many may well be "better"
for
their respective applications but generally speaking there are
no
other that can make the following claim: there is MORE to me
than meets the eye.
他にもマークアップフォーマットはあります。そしてほとんどがそれぞれのア
プリケーションにとってはより優れたものかもしれません、がしかし一般的に
言って次のことを主張できるものは他にはありません：私にとって見かけ以上
に隠れたものがあります。
__Ian "Xanadude in waiting" Feldman <ianf@random.se>
XU/Server[tm] not responding --
still trying
$$
.. ; The following matter may be more in the realm of wishful
.. ; thinking than is the rest of the setext, as no browser yet
.. ; exists to parse and execute here enclosed linkage information.
.. ; The principle of parseable anchors in text and expanded URLs
.. ; (Universal Resource Locators) appended last has been fully
.. ; validated by a similar construct deployed in WorldWideWeb's
.. ; email server document format however. In addition to that
all
.. ; setext lines matching the reg-exp ^\.\.\s[^\.]* will by default
.. ; be supressed from view but still recognizable to the parsing
.. ; front-end. Finally, the enclosed list of links is appended
.. ; in alphabetically-reverse order, to provide any browser with
.. : a minimal check that the list has, indeed, been generated by
.. ; mechanical means, therefore may easily be trusted when decoding
.. ; and executing the linkage data. Lines that contain no links but
.. ; comments like this one have furthermore been made distinguishable
.. ; by mechanical means from other suppressed matter --so that a
.. ; browser may filter them out easily prior to verification of the
.. ; trustworthiness of the links. Primitive, eh?
ここに含んだリンク情報を要素分析（パース）し実行できるブラウザはまだ存
在しないので、以下のことは、シーテキストの残り全部よりもさらに希望的観
測の域を越えないことかもしれません。しかしながら、テキスト内のパース可
能なアンカー及び最後に追加されてる展開されたＵＲＬs (Universal Resource
Locators)の原理は、WWW (World Wide Web)の電子メールサーバドキュメン
トフォーマット内で使用されている類似した構成で十分に確認されています。
そのほか、reg-exp ^\.\.\s[^\.]* パターンにマッチするシーテキストのす
べての行は、デフォルトで隠されて見えなくなりますが、パース用フロントエ
ンドは認識することができます。最後に、ブラウザが照合しやすいように、同
封したリンク一覧はアルファベットの逆の順で追加されています。この一覧は、
実際、機械的な手段で生成されているので解読及びリンクデータを実行する際
にももちろん信頼できます。ブラウザが、リンクの信頼性を確認するに前に簡
単にフィルターで分離できるように、このようなリンクは含んでいないがコメ
ントを含む行は、更に機械的な手段で他の隠されるものと区別することができ
ます。これでも、幼稚ですか？
.. ;
.. _this news:1qn588INN27o@uwm.edu
.. _solution news:19930420.063124.67@almaden.ibm.com
.. _shell (in the domain of wishful thinking
.. _query (by Gregory R Block <gblock@csd4.csd.uwm.edu>)
.. _publishable (or "Publshable" since nobody following it up in the
beginning
has corrected the spelling and now it is too late for
machine-readable-reference reasons)
.. _newsreader (in the realm of wishful thinking)
.. _mothered (with Adam C Engst of
# From: ianf@random.se (Ian Feldman, Current Setext Oracle)
# Newsgroups: alt.hypertext (complete, original headers at end of file)
# Date: Sun, 25 Apr 93 22:03:47 +0200
# Message-ID: <a800bb38@random.se>
# X-URL: file://garbo.uwasa.fi/mac/tidbits/setext/setext+sgml_02.etx
# Organization: random design -- "any old TTY will do"
# Reply-To: setext-list-request@random.se
# Lines: 536
# Summary: setext is pure potential embossed in plaintext
# Subject: Re: Looking for Electronic Publshing formats... [long]
setext and SGML
=================
by Ian Feldman_
In his last-referenced <news:19930423.072919.779@almaden.ibm.com>
article <\news:19930423.072919.779@almaden.ibm.com> Eliot
Kimber_
adds a few timbers_ to the fire in what has now become a wholly
different debate. My previous post bore a title "SGML
vs setext"
and was meant to provide a glimpse of the structure-enhanced
markup method for the setext-illiterati and to compare pure
usability aspects of it (in online publishing) to same of RTF
and
SGML, both often **taken** to provide rougly the same level
of
services. I know that it isn't so, but that's besides
the point
right now, as far too many people have <it>figured<\it>
it out
that way. This article is all about "setext _and_ SGML,"
to
underline threads common to both, clarify a few more points
and,
perhaps, muddy up some others.
Eliot Kimberは、彼が前回参照した資料
<news:19930423.072919.779@almaden.ibm.com> の中で、今はまったく異な
る論議となてしまった火の中へさらに薪をくえています。私の前回の郵送物の
表題は、"SGML vs setext"で、シーテキストを知らない人のために構造性を
高めたマークアップ方法をちらっと見せ、(オンライン出版での)シーテキスト
の純粋な有用特性とＲＴＦ及びＳＧＭＬ(このふたつはおおよそ同じ水準のサ
ービスを提供するものとみなされている)の有用特性を比較することが目的でし
た。しかし実際はそうではないということは分かっていますが、余りにも多く
の人がそのように理解してしまったので、今この時点ではもうそも言いってお
られません。この資料の内容のすべては、”シーテキストとＳＧＭＬ”に関し
たもので、双方に共通した糸を強調し、さらに幾らかの点を明らかにしそして
たぶん他をぼやかす、ためのものです。
Eliot has gone to some lengths to study the concept of the setext
as that described in the basic introductory document available
from the TidBITS listserver. It certainly isn't the most
descrip-
tive one around and could probably been made both longer and
more
technical in scope. This, however, has never been its
intention,
but only of providing the interested Mr & Ms Public with
a first
glance at the method. Last in that doc I explicitly welcome
further inquiries from those parties that are fascinated and
motivated enough to take time off their busy schedules to call.
This may to a large degree explain Eliot's inability to approach
and judge the setext as another <Autoritative!Answer> generalized
markup method <\Autoritative!Answer> and, instead, declare
it to
be just a mere **formatting** language_ and/ or a more or less
clever data notation_. Not so. There's more to setext
than meets
the eye. It has been designed this way.
Eliot は、TidBITS のリストサーバから入手できる基礎的な前置き資料で記述
されているシーテキストの概念をかなり詳しく調べています。しかしその資料
が、既存のものの中でいちばん良く説明できているというわけではなく、もっ
と長く内容はもっと技術的なものにすることもできました。しかしながら、本
来の目的はそうではなく、興味を持っている一般の初めての人にこの方法をち
らっと見せるというためだけのものでした。シーテキストに魅せられて、多忙
なスケジュールにもかかわらず電話をしたいと考えた人からのさらに詳しい質
問は、私はあの資料の終わりではっきりと歓迎しています。Eliot がシーテキ
ストをもう一つの広汎性マークアップ方法として接しそして判断することがで
きないで、シーテキストをただ単なるフォーマット言語で多少巧妙なデータ表
記法だと言っていることを、このことはかなりまで説明しているでしょう。実
際はそうではありません。シーテキストには見かけ以上に隠れたものがありま
す。シーテキストはそのようにデザインされています。
Silence. Camera? Action!
--------------------------
静寂に。カメラ？ アクション！
Eliot says:
Eliot が言うことには：
> Setext is a *formatting* language. Except for marking hyperlink
> anchors, it does nothing more than indicate text that is to be
> emphasized. This is not a criticism of setext, just a statement
> of fact.
シーテキストは、フォーマット言語の１つです。ハイパーリンクアンカーの印
し付けを除いては、強調されるテキストを示しているにすぎません。これは、
シーテキストを非難しているのではなく、事実を言っているのです。
It is not a <true>statement of fact <\true>, it is an assumption.
Setext may be limited but is every bit as generalized a language
as is the SGML. It does, however, march to the sound of
two
different drums: that of an Instant-Aha! comprehension_ and
the
ease of implementation. Setext is not primarily a method
to
format text for online distribution; it uses the constraints
(or,
in scientispeak, the semantics) of the lowest common denominator
medium to capture (or encode) a limited, but hardly "small,"
amount of logical structure into linearly-arranged matter.
The
fact that I had consciously chosen to **label** four out of
its 11
_optional_ typotags_ bold-, italic-, underline- and hot-tt has
nothing to do with their "weight" or meaning. For starters,
they
have no intrinsic meaning. They're only labels and are
not
<repeat> not <\repeat> bound to any strictly-typographical
constructs, although they ~may~ be treated as such if a front-end
author so desires.
それは、正しい事実を示しているのではなく仮定です。シーテキストは事実制
限されたものかもしれませんが、全ての点でＳＧＭＬと同様に広汎的な言語で
す。しかし、シーテキストは２つの異なるドラムの音にあわせて進行します：
即座に理解できることとインプレメンテーションの容易さの２つです。シーテ
キストは、本来、テキストをオンライン配布のためにフォーマットする方法で
はありません。線形に整列された物(linearly arranged matter)へ、制限さ
れてはいますが、”決して少なくはない”数の論理的構造をコード化するため
に最少共通項的媒体の束縛(学者の言葉では、セマンティックス：記号の意味関
係)を使用します。私が、１１種のオプションタイポタグの中の４つを意識的
に、太い、斜体、下線、ホットタイポタグと名称づけていることとこの４種の
持つ”重要性”又は意味とは何ら関係はありません。まず第一に、それらは、
本質的な意味はもっていません。ただ単なる名称であって厳密なタイポグラフ
的構成に制限されるものでは決してありません、もっともフロントエンドの作
者が望めばそのように取り扱うことも可能です。
Acc. to my private theory most online-people, weaned on
a decade
of mindlessly-applied WYSIWYG, _intuitively_ associate structure,
with that of typographical richness. We can all debate
why this
is so, but this undeniably is closer to a <statement-of>
fact
<\statement-of> than the previous claim. In view of
that I really
saw no option but to label the typotags in such fashion that
could
easily be associated with tangible (or visible) effects...
and
should they later happen to be mistaken for strictly-typographic
markup then I could envision worse disasters. The alternatives
were in any case unacceptable: call them Emphasis- Style-1 -2
-3
--or, I don't know which would be worse still-- General-Tag-This
-That -And -So -On.
私の個人的な仮説では、オンラインを利用する人のほとんどは、この１０年の
間思慮なく利用されたＷＹＳＩＷＹＧの結果、構造といえばタイポグラフ的に
豊富な構造を直感的に連想します。なぜそうなのか討論するのは可能です、が
しかしこのことの方が先の主張よりも明らかに事実に近いことです。そのこと
を考慮すると、具体的な（又は目に見える）効果と容易に関連できるやり方で
タイポグラフに名称を付けつるよりほか実際に選択肢が見つかりませんでした
..そして後に厳密なタイポグラフマークアップと間違えられた場合、より大き
な災難が想像できました。他の選択肢はいずれにせよ容認できませんでした：
強調スタイル-１ -２ -３と呼ぶか、又はどちらがより悪趣味か私にはわかり
ませんが、汎用タグ何々等。
That said, the setext does have one typotag that is more typo-
graphical in flavour_ that are all the others: it is the quote-tt,
leading right-chevron/ bigger-than-character, followed by a
space,
that indicates that a line
> has been included in a text from some other source.
そう言たとおりですが、シーテキストには他のどれよりも、よりタイポグラフ
的な特色を持ったタイプタグが１つあります：それは参照タイポタグで、先頭
桁の右シェヴロン/大なり符号（＞）とそれに続く空白１文字で、これはテキス
トの中に他のソースから引用した行が含まれていることを示します。
Such instances, if displayed, are to be shown in a monospaced
font, where multifonts are used, so as to underline their foreign,
included, status. Still no default binding to any particular
size
or face. End of typographic markup.
そのようなタグは、表示される場合、他からの引用であることを強調するため
に、複数のフォントが使われているところでは固定長フォントを使用して表示
します。しかし、まだ特別なサイズと（活字）書体を指示するデフォルトの制
限はありません。タイポグラフ的マークアップの終わり。
Euphemism Alert
-----------------
婉曲な警戒
> SGML languages, at their purest, are *NOT* formatting languages,
> but are intended to capture the logical structure of the content
> *as it relates to constructs in the real world*, in exactly the
> same way that object-oriented programs and user interfaces are
> intended to model the properties and behaviors of objects in the
> real world.
最も純粋な形態のＳＧＭＬ言語はフォーマット化言語ではなく、コンテントが
実際の世の中の構成物に関連しているようにその論理的構造を取り込むことを
目的としています。それはちょうどオブジェクト思考のプログラムとユーザイ
ンターフェースが実際の世の中に存在する物（オブジェクト）の特性とふるま
いをモデルにしているのとまったく同じです。
Which the latter are nowhere near good at, when we think of it,
but that's another matter. Still, long as we speak of
emulating
**constructs in the real world** we may perhaps bear in mind
that,
apart from print media, there are no universal/ valid/ U-name-it
models in strictly-electronic/ online publishing yet.
Therefore
using the SGML to model something that's chaotic at best, intan-
gible at worst is not in itself any better than using the setext.
At least the latter enforces a certain degree of universal online
order, where none previously existed. With the SGML you
are
certainly _creating_ order, but ONLY if source text is submitted
to an available, dedicate front-end.
後者は、考えてみると、とうてい良いとはいえないものですが、それはまた別
問題です。それでもなお、実際の世の中にある構造物のエミュレーションにつ
いて話す時、印刷媒体を除けば厳密な意味での電子的/オンライン出版での全般
的な/効果的な/どんなモデルも今だに存在していないことを憶えておくべきで
しょう。ですから、せいぜいよくて無秩序なもの、最悪の場合は実態がないも
のをモデル化するのにＳＧＭＬを使うことが、本質的にシーテキストを使うよ
りも優れているということはありません。いずれにせよ、シーテキストは、前
にはなかったところへ、ある程度まで全般的なオンラインの秩序を強制します。
ＳＧＭＬを使っても確かに秩序づけていますが、それはソーステキストを利用
できるＳＧＭＬ専用フロントエンドで閲覧する場合に限ります。
> It is clear from Ian's responses and the comparison chart below
> that he has not fully grasped this distinction and is thus
> comparing apples (setext, RTF, etc.) to oranges (SGML languages
> that do not contain or model formatting semantics).
Ian の返事及び下の比較図から明らかなことは、彼はこの違いを十分に把握し
ていない、だからリンゴ（setext,RTF等）とオレンジ（フォーマット化セマン
ティックスを含まない又はモデルとしないＳＧＭＬ言語）を比較しているので
す。
So that we all may hereafter sleep soundly at night I hereby
declare that I do, have grasped that distincion fully, or at
least
to the extent that it is graspable without extensive reprogramming
at some SGML summer camp ("Sun, Fun and SGML, too" ;-)).
And
whether it may be wholly inappropriate to compare the SGML with
the lesser mortals or not, we could probably agree that (a)
the
three previously listed are all graphic markup languges, (b)
RTF
is often considered a viable alternative to the SGML because
of
its potential market saturation factor and (c) how else, but
via
open-minded comparison can the public ever arrive at valid
conclusions?
みんな夜ぐっすり眠れるように、次のことを断言します：私はその相違点を十
分に把握しています、或いは少なくとも（"Sun, Fun and SGML, too")のよう
なＳＧＭＬのサマーキャンプで詳細にわたる再プログラミングなしにできる程
度は把握しています。そしてＳＧＭＬと他の劣る物とを比較することが全く不
適当なことなのか否か、我々はたぶん次の点では同意できるでしょう：（１）
前回列挙した３つは全てグラフィックマークアップ言語である、（２）ＲＴＦ
の潜在的な市場飽和的要因により、ＲＴＦはしばしばＳＧＭＬ言語に取って代
わりうる生存能力のあるものと見なされてる、そして（３）偏見のない比較に
よる以外、一体どのように一般の人は妥当な結論に達することができるのです
か？
In addition to all that I claim that the setext, though limited
in
scope, is every bit as generalized as is the SGML.
これらすべてに加えて、適用範囲は限られていますが、シーテキストはどの点
から見てもＳＧＭＬと同程度まで広汎性があると私は断言します。
Advantages weighted and classified
------------------------------------
評価された長所、及びその類別
> SGML as a data notation, divorced from any application semantics,
> has certain advantages and disadvantages. It's chief advantage
is
> that it is a true standard. It's chief disadvantage is that
it is
> a complex notation that does take some programming and processing
> power to fully process.
すべてのアプリケーションセマンティックスから分離すると、データ表記法と
してのＳＧＭＬは、幾らかの長所と短所があります。ＳＧＭＬの主な長所は、
それが正真正銘のスタンダード（標準）であるということ、主な短所はデータ
を完全に処理するには、多少のプログラミングおよび処理パワーを要する複雑
な表記法であることです。
We all agree on its advantages. The setext has come about to
address what could be called the effect of the disadvantges
of it and other visually-obtrusive coding methods, applied to
simple text that should be easiy to read everywhere.
長所については誰もが合意していることです。どこでも手軽に読むための簡単
なテキストに利用された場合、ＳＭＧＬおよび他の目立つコーディング方法の
不都合な影響とみなされる問題に取り組むためにシーテキストは作られました。
> Setext as a data notation has certain advantages and
> disadvantages. Its chief advantage is that it is simple (in
stark
> contrast to RTF, for example). Its chief disadvantages are
that,
> being simple, it is somewhat limited, and not being a standard,
> cannot be relied on to the same degree that standard notations
> can be.
データ表記法としてのシーテキストは、幾らかの長所と短所をもっています。
主な長所は、（例えば、ＲＴＦとの純然たる相違において）シーテキストは簡
単であること、主な短所は簡単であるがゆえに幾分制限される、そして標準（ス
タンダード）ではないので、標準となっている表記法と同等には信頼できない
ことです。
All true, albeit the limitations of it are that price that online
publishers pay for the privilege of having a text that's bith
universally readble AND structure-enhanced at the same time.
I
had never intended the setext to be used for other than periodic
online publications of time- and subject-topical kind, where
the
content:graphic-enhancement ratio never been very high anyway.
And if past experiences are anything to go by, I believe that
the
concept has proven to be successful.
どこででも読め、同時に構造性を高めたテキストを使用するうえでオンライン
出版者が払わなければならないその代価は、シーテキストの能力限界ですが、
言っていることは全部正しいです。とにかくコンテントとグラフィックエンハ
ンスメントの比率が決して高くない、時と題目を扱った類の定期的なオンライ
ン出版以外でのシーテキストの使用は決して予定していませんでした。過去の
経験をあてにすると、この概念は成功だと証明されたと私は信じています。
> The second aspect of the comparison is the richness of semantic
> expression. SGML has unlimited potential for semantic expression,
> in other words, capturing the details of what a given bit of
> information is *about*, not how it looks or should be processed.
> This is the distinction between truly generic markup and
> typesetting schemes that have some indirection in them.
この比較の第二の様相は、セマンティック表現の豊富さです。ＳＧＭＬは、制
限のないセマンティック表現の可能性を持っており、換言すれば与えられた情
報部分は何に関してなのかの詳細をコード化することであり、どのように見え
るか、又はどう処理されるべきかではありません。これが、偽りのない包括的
なマークアップと目的の不明確さを幾分含んでいる植字体系との相違です。
Nolo contendere. Italian for "pass the ice-cream bowl,
please."
On the other hand the ASCII publishing has a large graphic
potential than is seldom realized. Most people, in their
mind
thinking of the richtext WYSIWYG, never even try to execute
the
options that are at their disposal... creative use of
tables,
logical text constructs, delimiters, pseudo-graphics etc.
Yet if
Vladimir Mayakovsky could why can't they? So in view of that
I
can't see the SGML route as other than pure overkill for strictly
small-size online-publishing use.
Nolo contendere. イタリア語で”アイスクリームのボウルを回してくださ
い。”他方では、ASCII出版はまれにしか実感されない以上にグラフィックの
大きな可能性を持っています。多くの人々はリッチテキストＷＹＳＩＷＹＧの
ことだけを考え、表の創作的使用、論理的なテキスト構造物、区切り文字、擬
似グラフィクスなど、自由に使えるオプションをやってみようともしません。
それにもかかわらず、Vladimir Mayakovsky には可能なのに、どうして彼ら
にはできないということがありえるのですか？ そのことを考慮すると、ＳＭ
ＧＬによる方法は、短いサイズであることが厳密に守られているオンライン出
版での使用では全くの過剰機能としか思えません。
The parrot is dead, anyway
----------------------------
とにかく、オウムは死んだ。
> Setext does not meet this definition of generic markup, and as
> such, is not appropriate or useful for applications that need true
> generic markup.
シーテキストは、包括的マークアップのこの定義を満足していないので、本当
の包括的マークアップを必要とするアプリケーションにとって適切でも、ある
いは実用的でもない。
Yes it does.
No it doesn't
はい、適切で実用的です。
いいえ、適切ではない。
Yes it does.
No it doesn't
Does.
Doesn't.
Does.
Doesn't.
Does, does, does, does.
Doesn't, doesn't, doesn't, doesn't.
Anyway, the parrot has long been dead, we can all
agree on
that ;-))
誰もが同意できることは、とにかくオウムはとっくの昔に死んだ、ということ
です。
> I make the assumption that anyone who goes to the trouble to use
> or to consider using SGML for text and data management needs the
> full power of generic markup, *whether they realize it or not*.
私は次のような仮定を立てます：誰でもテキストとデータの管理が目的でわざ
わざＳＧＭＬを使用する、又は使用を考えてい者は、実現させるか否かにかか
わらず包括的マークアップのフルパワーが必要です。
It may well be true, but is the opposite equally so?
正しいかもしれませんが、その逆もまた等しく正しいのでは？
"Anyone considering use of generic markup needs the
full
power of the SGML, **whether they realize
it or not**"
誰でも包括的マークアップの使用を考えている者は、実現させるか否かにかか
わらず、ＳＧＭＬのフルパワーが必要です。
This rhetoric question is here preanswered for you: NOT.
BTW, it's an Authoritiative Answer from the Authoritative-
Answers Server[tm].
この修辞疑問の解答を、ここで事前にします：NOT（違います）。ちなみに、
これは権威解答サーバ（登録商標）からの権威ある解答です。
> Since the original question about online formats was asked in
> comp.text.sgml, I made the assumption that an SGML solution was
> desired. I then attempted to show how setext could be made
to be
> an SGML solution.
オンラインフォーマットに関する最初の質問は、comp.text.sgmlで質問され
ていたので、ＳＧＭＬによる解決策が望ましいと考えました。次いで、シーテ
キストが、どのようにＳＧＭＬソリューションとなり得るかを示そうと試みま
した。
Funny you should mention it, I saw the original as being
directed _primarily_ to alt.hypertext (first on the Newsgroups:
line of Greg_ R Block's posting and following) and so I replied
there. I do not partake in discussions in the sgml forums as
I consider myself an amateur at best in this respect.
そのことを話に出すとは、滑稽です。私は、最初に alt.hypertext 宛に出さ
れたものをオリジナルとして見ました（最初はニュースグループで：Greg_
R
Blockの出したメッセージ、そしてそれに続くやり取り）。ですからそこへ返
事を出しました。私はせいぜいよくみてもこの点に関してはアマチュアだと思
うので、ＳＧＭＬフォーラムでの討論には参加していません。
Catering to the lowest common denominator
-------------------------------------------
最少共通項の要求を満たす
> Note that setext has, from my point of view, somewhat limited
> utility because what it does *only serves the lowest common
> denominator*. SGML solutions can serve the whole range of
> applications, from the simplest to the most complex.
シーテキストはただ単に最少共通項的な要求を満たすことしかししないので、
私の考えでは、少々限られた有用性しか持ち合わせていないことに注目してく
ださい。ＳＧＭＬソリューションは、最も単純なものから最も複雑なものまで、
アプリケーションのすべての範囲の要求を満たすことができます。
Alas, this is yet another unfortunate effect of your orginal
first-sight dismissal of setext as non-generalized markup, there-
fore of lesser interest. Setext does not **only** serve
the
lowest common denominator media, it conforms to the constraints
of
them in order to be readable everywhere. There is nothing
in it
preventing arrival of an advanced implementation, say a richtext/
indexing/ you-name-ing browser, post-processor and incremental-
database front-end. As with the SGML the beauty of it
is in the
eye of the beholder, though never as is with the SGML dependent
on
the very _presence_ of a browser.
ああ、これもまた、一見してシーテキストを非包容的マークアップだと決め付
け、だから関心はないと簡単に片付けてしまった残念な結果です。シーテキス
トは、ただ単に最少共通メディアの要求だけを満しているだけではありません。
どこででも読めるように、それらの束縛に適合します。例えばリッチテキスト/
索引付け/あらゆる種類のブラウザ/ポストプロセッサーと増進データベースフ
ロントエンドのような、高度なインプレメンテーションの出現をシーテキスト
が妨げるようなことは一切ありません。ＳＧＭＬとは違ってブラウザの存在に
頼ることは決してありませんが、ＳＧＭＬがそうであるようにたで食う虫も好
きずきです。
In fact, were I to attempt to categorize it in relation to the
SGML, I'd definitely underline the fact that both are generalized
methods but only the setext provides an ability to be "consummed"
ALSO in the lowest common denominator state. More technically,
I
believe that --setext's limitated scope readily admitted-- the
main difference between the two is the SGML's potential of being
decoded acc. to different DTD's in the same front-end.
This will
probably never happen with the setext, since the implementations
of browsers for it would then have to become as complex as those
for the SGML. Rather, it should be said, that each dedicated
setext front-end will be an instance implementation of a single,
hardcoded DTD. Er... I hope it all makes logical
sense, as it
does here ;-))
実際、もしＳＭＧＬと関連させてシーテキストを類別しようと試みるとすると、
双方とも広汎的な方法ですが、シーテキストは更に最少共通項状態でも”使用”
できるという事実を私ならはっきりと強調するでしょう。もっと技術的に言う
言うと、私の信じるところでは、--シーテキストの限られた適用範囲について
は容易く認めたうえで--、両者の主要な相違は同一のフロントエンド内で異な
るＤＴＤに従って解読できるというＳＧＭＬの潜在能力です。これはシーテキ
ストにおいては恐らく実現されないでしょう、と言うのもそうするためにはブ
ラウザのインプレメンテーションはＳＧＭＬと同程度まで複雑なものにならざ
る得ないからです。言っておくべきですが、それよりも、それぞれ専用のシー
テキストフロントエンドは、単独のハードコード化されたＤＴＤのインプレメ
ンテーションでしょう。えーと、これらのことすべてが論理的に意味をなして
いることを望みます。
Points taken & reconsidered
-----------------------------
もっともな点、考え直された問題点
>> Eliot Kimber_ of IBM has declared_ it to be "a very
>> primitive, obviously easy to implement and interchange."
ＩＢＭのEliot Kimberは、シーテキストは非常に幼稚であり、明らかにインプ
レメンテーションと交換は容易であると断言しました。
> This is a statement of fact.
これは、事実を言っているのです。
This is not a statement of fact. It is an informed, if
somewhat
hastily arrived at, and in my view mistaken, opinion.
これは、事実ではありません。少々あわてて結論に達した、情報に基づいては
いるが、私の考えでは誤解した、意見です。
> Compared to other languages for the structuring of information for
> online retrieval and presentation, setext is primitive. IBM
has
> invented a 300+ element_ language with complex semantics [....].
> If setext is not primitive compared to this, I obviously don't
> understand the meaning of the word "primitive".
オンライン抽出およびプレゼンテーションのための情報の構造化を目的とした
他の言語と比較すると、シーテキストは幼稚です。ＩＢＭは、300以上の要素と
複雑なセマンティックスからなる言語を発明しました。もしシーテキストがこ
れと比較して幼稚でないとすれば、私は明らかに”primitive（幼稚な）”と
いう単語の意味を理解していないのでしょう。
Apparently not. The word "primitive" is, apart from its
meaning
of "simple" also a low-value judgement of which you cannot have
been unaware. Now, that is a statement of <fact> fact
<\fact>.
明らかに、理解していません。”単純な”という意味は別として、”primitive”
という単語は、意図的に低い価値判断を下す、ことも意味します。そら、それ
こそが事実です。
> Again, this is not to say that setext is not useful, just that in
> terms of the functions it provides and the semantics it captures,
> it cannot compare to other systems of much greater complexity,
> including the OSF, Docbook, IBMIDDoc, and Daveport designs, not to
> mention other HyTime-based work such as the various IETM projects
> and other industry-specific applications like the ATA and CALS
> work.
繰り返しますが、これはシーテキストが実用的でないと言っているのではなく、
ただシーテキストが用意している機能、及びそれが理解するセマンティックス
の点からみると、色々なIETMプロジェクトのような他のHyTimeをベースとした
もの、及び ATA と CALS のようなインダストリー固有のアプリケーションは
言うまでもなく、OSF、DOcbook、IBMIDDoc、Daveportデザインを含む他のもっ
と複雑なシステムと比較はできない、と言いたいだけです。
No, indeed not, but can _they_ provide a solution for the net-
worked have-nots, perpetually squeezed-in between the ever
NEWER-FASTER-SLEEKER-BETTER hi-tech and the trend$y lo-tech
of
the haves? Setext is an example of what I call ADEQUA-TECH[tm],
the bicycle-like vehicle among the gas-guzzling monsters on
that internetwork of ours. No, I don't fancy cars either.
ええ、実際比較はできません、がしかしネットーワークに接続されてはいるが
最小限の機能しか持っていない者、更に常により新しく/より高速な/より奇麗
な/より優れた高度な先端技術とトレンディな低級技術の間に永久に押し込まれ
た所有者にソリューションを提供できますか？ シーテキストは、私が妥当な
技術 ADEQUA-TECH（登録商標）と呼んでいるものの一例であり、我々のインタ
ーネット上でガソリンをがぶがぶ飲むむ怪物（フェラーリ等）に囲まれた自転
車のような乗り物です。いいえ、私は車もまた好きではありません。
>> contrast, SGML et al judged through the bias of human-readable-
>> text/ ASCII will appear unduly complex and mostly inaccessible
to
>> anyone having but the lowest common denominator hardware/
software
>> at their disposal (80% of all users? 90%?)
対照的に、人が読めるテキスト/ASCIIという観点で判断した場合、ＳＧＭＬな
どは過度に複雑で、最少共通項的な機能しかもたないハードウェアとソフトウェ
アしか自由に使えない者（全ユーザの８０％？ ９０％？）にとってはほとん
どアクセスできないように思われます。
> I beg to differ. As the folks at Exoterica will attest, SGML
can
> be made no less human readable than setext.
異議を申し上げたい。Exoterica の人びとが証明しているように、ＳＧＭＬは
少なくともシーテキストと同程度まで人が読めるようにできます。
I am not familiar with what those folks at Exoterica might be
doing, but if you are thinking of the shortrefs, which I take
to
be a minimal-size embedded notation that is expanded later via
aliases? in the DTD or equivalent then, clearly, we're talking
two
different strategies. Setext is, at its simplest, entirely
devoid
of any visible tags. It will thus appear as merely some
rigidly-
formatted piece of plaintext yet at the same time continue to
carry the minimal structure (== subdivisions of the whole into
parts above the paragraph level, a basic outline notation).
No
amount of SGML-minimizing can approach that.
Exoterica で行っていることに関して詳しくは知らないのですが、あなたが考
えているのは SHORTREF のことですか？ SHORTREFは、ＤＴＤまたは同等なも
のの中でエイリアス経由であとで膨張させる極微エンベッド表記法と理解しい
ます。もしそうだとすると明らかに、全く異なる２種類の方法について論じて
いることになります。シーテキストは、最もシンプルな状態では目につくタグ
は全くありません。ですから、単に固定フォーマットされた単純テキストとし
て見えるものの、しかしながら最小限の構造（全体を段落レベルより上位の部
分への再分：基本的なアウトライン表記法）を含んでいます。ＳＧＭＬの最少
化では、全く比べ物になりません。
Who has missed who's point and vice-versa
-------------------------------------------
相手の論点を理解しそこなったのはどっち？
>>> SGML Source --> SGML2SETEXT --> setext --> setext viewer
>> It strikes me as no little ironic that in order to view enhanced
>> plaintext (i.e. the setext) in a basic-structured manner,
say an
>> outline of the submitted text, one would have to first encode
it
>> with SGML, then pipe it through a filter with a DTD acronym
thrown
例えばこのテキストのアウトラインでもいいのですがこのような、基本的な構
造を持たせる仕方で構造性を高めた単純なテキスト（即ちシーテキスト）を見
るためにまずＳＧＭＬでコード化し、続いてＤＴＤ接頭語がたっぷりと書き入
れられたフィルターを通しパイプしなければならないのは少なからず皮肉なこ
とだと私には思われます。
> You have missed my point. The point was not to first encode
an
> setext document into SGML to then immediately transform it back
> into setext, but to use an setext viewer to view *any* existing
> SGML document by mapping that document into setext. Remember
that
> setext is a *formatting notation* and that is the way I have used
> it here.
あなたは、私の論点を理解していません。論点は、シーテキストドキュメント
をまずＳＧＭＬへコード化し、次いで直ちにシーテキストへ変換して戻すこと
ではなく、既存のどんなＳＧＭＬドキュメントでもそれをシーテキストへマッ
ピングしてシーテキストビューアを使って見るということでした。シーテキス
トはフォーマット化表記法であり、私はここでシーテキストをそのようなもの
として使用していることを忘れないように。
He, he.... I have not missed your point, you have missed
mine.
Setext is an alternative to SGML in certain applications, where
neither the generalized complexity, nor the cost of the SGML
route
can be justified. Mapping SGML-notation documents onto
setext,
as you say, is missing the point up to a point, and twice over.
For one, such setext viewer(s) would then have to be much more
complex than otherwise would be the case. For another,
adding
SGML-markup to source texts automatically lowers the overall
comprehensibility of these, shortrefs or no refs. Setext
is
designed _also_ to cater to all those among ourselves that,
even
though they may have ready tools at their disposal, would rather
"type" or "cat" files as they come in, because of the force
of
habit, procrastination or choice. After all, if you know
that
the text in question is a setext, thus readable anyway, then
why
should you bother to launch, enter, load in, access &c just
for
the privilege of casting an eye on **some** text?
ヒー、ヒヒー。私があなたの論点を理解していないのではなく、あなたが、私
の論点を理解していないのです。シーテキストは、広汎性の複雑さ又はＳＧＭ
Ｌによる方法に伴う費用を正当化できないある種のアプリケーションにとって
はＳＧＭＬの代用となるものです。あなたの言っているＳＧＭＬ表記ドキュメ
ントをシーテキストへマッピングすることは、要点をある程度誤解しています、
それも２度。一つは、その様なシーテキストブラウザは、そうしない場合より
もはるかに複雑になってしまう。もう一つは、ソーステキストへＳＧＭＬマー
クアップを加えると、SHORTREF又はREFなしでも、テキストの総合的な理解の
しやすさが自動的に損なわれます。シーテキストは、更に自由に使えるツール
を持っているけれど、習慣で、又はぐずぐず延ばしてしまい、或いは好みによ
り、到着したファイルを type または cat コマンドを使って表示したいとい
う人のことも考慮してデザインされています。結局、問題のテキストがシーテ
キストで、いずれにしてもそのまま読むことが出来ることを知っていれば、ど
うして”ある種の”テキストをただ一瞥するために、%C をわざわざ起動させ、
タイプし、ロードし、アクセスするのですか？
Cost of basic structure encoding
----------------------------------
基本的構造コード化のコスト
> I'd have thought > that the opposite would be an altogether
> more-agreeable solution:
正反対の方が概してより快く同意できるソリューションだと考えたことでしょ
う：
>> plaintext --> setext --> setext2SGML -->
SGML viewer
> There's nothing wrong with this path, but it misses the point made
> above.
この道筋で悪いところは何もありませんが、上で指摘した論点を見落としてい
ます。
I beg to differ, no less for strictly cost-of-basic-encoding
reasons. Not having studied it in depth I should perhaps
not
deliver any official prognoses but it appears to me that basic
hand-encoding of setext can be much, much cheaper than that
of
enSGMLising.
厳密に”基本的コード化”のコストに劣らない理由で、失礼ながら私の意見は
異なります。徹底的に調査したわけではないので、公式な返答を述べるべきで
はないですが、手によるシーテキストの基本的なコード化のほうがＳＭＧＬ化
に要するコストよりもはるかに安いと思われます。
>> Obviously, Kimber has all the resources at his beck and call
and
>> expects that others will have them too. We may all yearn
to become
明らかに、 Kimber は、彼の思い通りになるリソースをすべて持っており、他
の人も彼のようだと思っています。
> I have no more resources than anyone else with a desktop computer,
> access the Internet, and a C compiler, at least for the purposes
> of this discussion.
他のことはともかくもこの討論のため、私はデスクトップコンピューター、イ
ンターネットへのアクセス、Ｃコンパイラーを持っている者と同程度のリソー
スしか持っていません。
Well, perhaps your outlook in relation to text encoding standards
would have changed had you but had an asynchronous, 2400bps
uucp
connection to a mainframe at your disposal and never enough
time
to master a C compiler, much less make it perform ;-))
それじゃあ、自由に使えるが大型コンピュータへの非同期式、２４００bps
uucp
接続で、Ｃコンパイラーをマスターする時間がなく、それを実行させる時間は
もっと少ないといった状態なら、テキストをコード化する標準に関するあなた
の見解は変わっていたことでしょう。
> I haven't proposed anything that can't be done by anyone who can
> write a little C code to Windows, or XWindows, or Mac, can
> integrate ARCSGML or SGMLS into a program, and has a computer to
> run it on. This may require cleverness and skill, but not
> resources out of the ordinary.
Ｃ言語による Windows、XWindows、又はMac用の短いコードを書くことができ、
ARCSGML又はSGMLSをプログラムへ統合でき、それを実行できるコンピューター
を持っている者に不可能なことは何も発議してはいません。巧妙さと特殊技術
が要求されるかも知れませんが、並はずれたリソースは必要ありません。
PARSED! -->ANOTHER INSTANCE OF INTERNET-HI-FLIER ATTITUDE!<--
解明できた！-->インターネットの野心家である態度の一つの現れだ！<--
> I didn't suggest that everyone license DynaText or buy Omnimark
> or get a RISC machine. That's clearly what big enterprises
with
> big problems and big budgets need to do. But someday, probably
> very soon, that degree of power will be available to everyone
> and will be the lowest common denominator.
みんなが DynaText の使用をライセンスし、又は Omnimark を購入する、或
いは RISCマシーンを手に入れたらいいと言っているのではありません。そう
いったものは明らかにもっと大き問題と膨大な予算のある大手企業が必要とし
ていることです。しかし、いつか、恐らく直にその程度のパワーはすべての人
が入手できるようになり、最少共通項となるでしょう。
We'll cross that bridge when we come to it. In the meantime....
取り越し苦労はしません。さしあたり...、
>> 1Mbit/sec-access high-flyers of the Internet, but in the meantime
>> many of us have to make do with but Have-A-Mac and never enough
>> funding to equip it with enough RAM to satisfy our needs.
みんな 1Mbit/秒でアクセスできるインターネットの才物になろうとあこがれる
でしょうが、我々のほとんどは、”ただ単にマックを所有している”ことで我
慢し、必要なＲＡＭを準備する資金も十分にあるわけではないのです。
> You've obviously never tried to order RAM within IBM :-).
明らかに、ＩＢＭでＲＡＭを注文したことがないのようですね。
No, but could hardly think it more taxing than having to pay
for it out of your own pocket.
いいえ、しかし自腹を切って払わなければならない以上の負担だとは考えられ
ません。
> Easy-O-Meter[tm]
------------------
>> ______________ ___________ RTF ___________ SGML
__________ setext
>> generalized
no
YES
yes
>> markup?
> I would argue that, from my argument above, setext does not
> qualify as the same sort of generalized markup that SGML enables.
> Setext is generalized to the degree that there is an indirect
> mapping between the setext codes and their actual presentation
> effect, but it does not capture information semantics the way
> SGML languages can and do.
私の上記の理由で、シーテキストはＳＧＭＬが可能にしているのと同じ品質の
広汎的マークアップとは見なせないと主張します。シーテキストは、シーテキ
ストコードとそれらの実際のプレゼンテーション効果との間で間接的なマッピ
ングがあるといった段階の広汎性は持っていますが、ＳＧＭＬ言語が可能であ
り、行っているようには情報セマンティックスを理解していません。
No, of course not, but then I **did** weight the YES in favour
of the SGML. Or did you think that that uppercase YES appeared
there for no reason at all? By mistake?
ええ、勿論おっしゃる通りです。しかし、大文字のYESを使ってＳＧＭＬに有利
になるように評価しました。大文字のYESがまったく意味をもたないで書かれた
と思ったのですか？ 誤って書かれたと？
>> -------------- --------------- ----------------
-----------------
>> #typographical a finite set unlimited
set 3 typographical
>> tags employed?
1 hypertextual
> In the sort of SGML languages I consider worth talking about,
> there are no "typographical" tags at all, because SGML languages
> capture information semantics, not formatting. SGML data
> structured with languages of this sort is no more typographical
> than SGML databases.
論ずるに値すると考えられる類のＳＧＭＬ言語には、タイポグラフタグはまっ
たく存在していません、というのもＳＧＭＬ言語が情報セマンティックスを理
解するのであってフォーマット化を行うのではないからです。このような種類
の言語で構造化されたＳＧＭＬデータは、ＳＧＭＬデータベースと同程度のタ
イプグラフ的要素を有しているだけです。
Right, agreed. Unfortunate usage of words in an attempt to make
it more easily understandable to the world at large. Try to
sell
SGML to any small-time publisher and the first thing they'll
inquire about will be its ability to express styles.
正しいです、同意します。世人全般により容易に理解できるようにと試みた結
果、不適切な言葉を使用してしまいました。ＳＧＭＬを三流の出版社へ売り込
もうとすと、まず最初に尋ねられるえことはスタイル（印刷様式）を表す能力
でしょう。
>> -------------- --------------- ----------------
-----------------
>> tag overhead +25%?
+30%?
+9% (verified)
> With SGML's tag minimization features, SGML can have no more
> overhead than setext. I've seen some of the things the Exoterica
> folks have done with shortrefs and datatag, and it's pretty
> amazing (gives me the willies, though).
ＳＧＭＬのタグ最少化機能を用いれば、ＳＧＭＬはシーテキスト以上のオバー
ヘッドにはならないはずです。Exotericaでshortrefとデータタグを用いて行っ
たものを幾つか見ましたが、（ぞっとするけれど）それらは非常に驚くべきも
のでした。
Of course, this is a point that will vary widely with the
application. Yet because the setext _is_ limited in scope
it's
overhead can never be much above the verified figure of 9%.
もちろん、これはアプリケーションによって大きく異なってくる点です。それ
にもかかわらず、シーテキストは適応範囲が限られているので、シーテキスト
のオーバヘッドは確かめられた９％とうい数字よりもずっと大きくなることは
決してありません。
Is it over yet? I have a date
-------------------------------
まだ終わらないのですか？ 私は、デートの約束があります。
> I want to emphasize that my intent is not to denegrate setext,
> because it is, as I've said, an elegant solution to a difficult
> problem. My intent is only to emphasize the difference in focus
> and approach to the solutions to the sorts of problems setext
> solves and the full range of problems that SGML can solve, and
> that a comparison between notations like setext and fully-generic
> SGML languages is not a valid comparison.
私は決してシーテキストをけなそうとしているのではないことを強調したく思
います。と言うのも、前に言いましたが、シーテキストは困難な問題に対すりっ
ぱな解決策です。私の目的はただ単にシーテキストが解決する問題の類に対す
る解決策へのアプローチ及び焦点とＳＧＭＬが解決できる問題の全領域に対す
る解決策へのアプローチ及び焦点の違いを強調することと、更にシーテキスト
のような表記法と完全に包括的なＳＧＭＬ言語の比較は妥当ではないことを強
調することです。
Nor have I taken it as such, on the contrary; open debate is
always preferable to no debate. At the very least it allowed
me
to cast a light on the setext, in not too-inappropriate a forum,
be it just a "notation" or another generalized graphic markup
method. OK, OK, "bask in the enlightened light of the
SGML"...
have it your own way ;-))
私もそのような意味にはとっていません。それどころか、討論されないよりも
公開で討論される方が常により望ましいことです。非常に少なくとも、不適当
すぎないフォーラムで、シーテキストの解明に役立ちました：シーテキストは
単に１つの表記法又は包括的グラフィックマークアップ方法である。はい、は
い、”ＳＧＭＬの啓発された光を浴び...” 勝手にしてください。
__Ian Feldman <ianf@random.se> "Those that do not understand
Unix are bound to invent it, poorly"
--Henry Spencer
”Unixを解さない者が創案するUnixはみすぼらしい”
$$
.. The sharp-eyed among you will note, that here-appended notation
.. of hypertextual anchor expansion differs from that served in the
.. previous post of mine (news:a7fd5104@random.se). Indeed, this
.. portion of the setext is still largely undefined and so I am
.. experimenting with various methods to arrive at an optimal
.. solution to the problem. Ye sharp-minded 'uns will also
.. immediately understand the reason for those changes.
観察力の鋭い人は、ここに追加表記されているハイパーテキストアンカー展開
は、私が前回郵送したもの(news:a7fd5104@random.se).と異なっているのに
気づくでしょう。事実、シーテキストのこの部分はまだ十分に定義されてはい
ません。ですから、問題に対する最良の解決策にたどり着くためにいろいろな
方法を試みています。観察力の鋭い人はこれらの変更のわけが直ちに理解でき
るでしょう。
.. _typotags (so named because at worst they will appear as mere typos
in
text)
最悪でも、テキストの中でほんのタイプミスとしか見えないのでこの名前を付
けました。
.. _timbers (hey! I like the timbre of that sentence ;-))
.. _notation news:19930423.072919.779@almaden.ibm.com/"one of many
similar
schemes"
.. _language news:19930423.072919.779@almaden.ibm.com/"it does nothing
more"
.. _flavour (well, if gluons can come in flavours so why not the typotags?)
.. _element (bully for you)
.. _comprehension ("ability to understand")
.. _Kimber <drmacro@ralvm13.vnet.ibm.com> (Eliot Kimber)
.. _Greg news:1qn588INN27o@uwm.edu
.. _Feldman <ianf@random.se> (Ian Feldman, Current Setext Oracle)
..
# original headers, suppressed on account of appearing AFTER a twodot-tt
# From ianf Sun Apr 25 23:42:30 MET DST 1993
# Path: random.se!ianf
# From: ianf@random.se (Ian Feldman)
# Newsgroups:
alt.hypertext,comp.multimedia,alt.news-media,comp.text,comp.text.sgml,comp.sys
.amiga.multimedia
# Date: Sun, 25 Apr 93 22:03:47 +0200
# Message-ID: <a800bb38@random.se>
# X-URL: file://garbo.uwasa.fi/mac/tidbits/setext/setext+sgml_02.etx
# X-URL:
file://ftp.ifi.uio.no/pub/SGML/comp.text.sgml/by.msgid/a800bb38@random.se
# X-Aftp: <garbo.uwasa.fi> :/mac/tidbits/setext/setext_concepts_Aug92.etx
# References: <1qn588INN27o@uwm.edu> <19930416.063132.922@almaden.ibm.com>
#
<19930420.063124.67@almaden.ibm.com> <4942@ulysse.enst.fr>
#
<a7fd5104@random.se> <19930423.072919.779@almaden.ibm.com>
# Content-Type: setext/plain; charset=ascii_827
# Organization: random design -- "any old TTY will do"
# Lines: 507
# Summary: setext is pure potential embossed in plaintext
# Subject: Re: Looking for Electronic Publshing formats... [long]
>From SGML Mon Apr 26 09:32:09 MET DST 1993
Newsgroups: alt.hypertext,comp.multimedia,alt.news-media,comp.text,
comp.text.sgml,comp.sys.amiga.multimedia
From: Erik Naggum <SGML@ifi.uio.no>
Message-ID: <19930426.003@erik.naggum.no>
Date: 26 Apr 1993 03:14:00 +0200
References: <1qn588INN27o@uwm.edu> <19930416.063132.922@almaden.ibm.com>
<19930420.063124.67@almaden.ibm.com> <4942@ulysse.enst.fr>
<a7fd5104@random.se> <19930423.072919.779@almaden.ibm.com>
<a800bb38@random.se>
Subject: Re: Looking for Electronic Publshing formats... [long]
Lines: 107
Status: R
[Erik Naggum speaking]
======================
Through the barrage of silliness in the referenced article, a few gems
can still be seen. I think we should focus on them, so I have
cut more
than liberally in the article, which IMNSHO the author should have
done
before posting it.
参照している配布資料の内容はばかげたことでいっぱいですが、それでも少し
は宝石のようなものも見られるので、それらのことに集中するべきだと思いま
す。ですから、自由に資料にハサミを入れました。もっともこれは著者が郵送
する前に行っておくべきことですが。
[Ian Feldman]
:
| According to my private theory most online-people, weaned
on a decade
| of mindlessly-applied WYSIWYG, _intuitively_ associate
structure with
| that of typographical richness.
:
私の個人的な仮説では、オンラインを利用する人のほとんどは、この１０年の
間思慮なく利用されたＷＹＳＩＷＹＧの結果、構造といえばタイポグラフ的に
豊富な構造を直感的に連想します。
| [As] long as we speak of emulating constructs in the real
world, we may
| perhaps bear in mind that there are no universal models
in strictly-
| electronic/online publishing yet.
:
それでもなお、実際の世の中にある構造物のエミュレーションについて話す時
は、印刷媒体を除けば、厳密な意味での電子的/オンライン出版での全般的なモ
デルは存在していないことを憶えておくべきでしょう。
| I had never intended setext to be used for other than
periodic online
| publications of time- and subject-topical kind, where
the content to
| graphic-enhancement ratio never were very high anyway.
And if past
| experiences are anything to go by, I believe that the
concept has
| proven to be successful.
:
とにかくコンテントとグラフィックエンハンスメントの比率が決して高くない、
時と題目を扱った類の定期的なオンライン出版以外でのシーテキストの使用は
決して予定していませんでした。過去の経験をあてにすると、この概念は成功
だと証明されたと私は信じています。
| Setext does not _only_ serve the lowest common denominator
media, it
| conforms to the constraints of them in order to be readable
everywhere.
:
シーテキストは、ただ単に最少共通メディアの要求だけを満しているだけでは
ありません。どこででも読めるようにそれらの束縛に適合します。
| Setext is, at its simplest, entirely devoid of any visible
tags. It
| will thus appear as merely some rigidly-formatted piece
of plaintext
| yet at the same time continue to carry the minimal structure
(i.e.,
| subdivisions of the whole into parts above the paragraph
level, a basic
| outline notation).
:
シーテキストは、最もシンプルな状態では目につくタグは全くありません。で
すから、単に固定フォーマットされた単純テキストとして見えるものの、しか
しながら最小限の構造（即ち、全体を段落レベルより上位の部分への再分：基
本的なアウトライン表記法）を含んでいます。
| [B]ecause setext _is_ limited in scope its overhead can
never be
| much above the verified figure of 9%.
シーテキストは適応範囲が限られているので、シーテキストのオーバヘッドは
確かめられた９％とうい数字よりもずっと大きくなることは決してありません。
I have a few comments on what I consider to be a cause of the confusion
so
far, and some final comments on where setext and SGML fit in.
今までの混乱の原因だと考えられることについて二三のコメントと、更にシー
テキストとＳＧＭＬをどこへはめ込むのかに関する幾つかの最終的な注釈をし
たいと思います。
Coombs, Renear and DeRose : Markup Systems and the Future of Scholarly
Text
Processing, in CACM 30/11 (1987) pp 933-947, discuss markup systems
in
general, and give some valuable pointers to what we might otherwise
take
for granted. Our writing system introduces us to punctuational
and
presentational means of conveying the structure of information, the
latter
including horizontal and vertical spacing, numbering of lists, paragraphs,
chapters and the like. The article discusses four types of markup:
no markup (not even punctuation), presentational, procedural, and
descriptive. The procedural markup systems associate control
words with
procedures with fixed actions. The descriptive markup systems
associate
markup constructs with types of elements of the structure.
Coombs、Renear、DeRoseは： CACM 30/11 (1987) 頁933-947の”マークアッ
プシステムと学問的テキスト処理の将来”の中で、マークアップシステム一般
を詳細に論じ、指摘されなければ当然のことと思うかもしれないことへ幾つか
の貴重な指針を示しています。我々の記述体系 (writing system)で、情報の
構造を伝える句読的な及び表象的な方法を経験できます。表象的な方法は、水
平及び垂直スペーシング、表/段落/章などの番号付けを含みます。この資料は、
４種類のマークアップについて論じています：マークアップなし（句読すらな
い）、表象的マークアップ、手続きマークアップ、そして記述的マークアップ
の４種類です。手続きマークアップシステムは、制御語（コントロールワード）
を固定された特定の処理を行う手続きに関連させます。記述的マークアップは、
マークアップ構成物を構造の要素タイプと関連させます。
Against this background, SGML is a purely descriptive markup system,
and as
a language, it provides declarations for the elements (among other
things),
such that they are akin to variables in other languages. As elsewhere,
the
meaning of variable names can differ according to context, but an SGML
system provides the application with a structure of named elements
that it
can act up on in any number of ways. In SGML, the markup is rigid
and this
is exploited by offering validation services for SGML documents as
part of
the processing. Indeed, the idea that the markup is or is not
"valid"
independent of its processing is one of SGML's strongest points.
この背景に対して、ＳＧＭＬは純粋な記述的マークアップ体系であり、言語と
しては他の言語での変数に類似している（特に）要素のための宣言を提供して
います。ほかの場合同様、変数名の意味は状況によって異なりますが、ＳＧＭ
Ｌ体系はアプリケーションが色々なやり方で処理できるそれぞれ固有な名のあ
る要素の構造をアプリケーションに提供します。ＳＧＭＬにおけるマークアッ
プは厳密であり、だから処理の一部としてＳＧＭＬドキュメントの検証サービ
スを提供することで活用されています。実際に、マークアップがその処理とは
無関係に”有効”又は”無効”であるという考え方が、ＳＧＭＬの最も顕著な
長所の一つです。
Compare now setext, which is a sort of cross-breed between punctuational
and presentational markup system with delusions of grandeur if I may
put it
in a hostile form. One of the disadvantages of punctuational
markup, as
detailed in the above article, is its complexity and the difficulty
of
authors to adhere to conventions. Precisely this complexity will
make it
very hard to validate punctuational markup systems, which is all the
more
necessary because of the difficulty in adhering to them. Presentational
markup systems suffer from a large variety of means to convey the same
structural information, as found in variations in indentation, vertical
spacing, etc. Since such systems are mainly intended to be "processed"
by
the human eye, "validity" will also be largely undefined for documents
in
this system. setext's redeeming quality is that it attaches descriptive
semantics to the punctuational-presentational markup, instead of procedural
semantics, which is definitely the more usual.
ではシーテキストを比べてみましょう。これは句読法的マークアップと象徴的
マークアップの混成物のようなもので、敵意のある表現になりますが誇大妄想
的なマークアップシステムです。上記の資料で詳述されているように、句読的
マークアップの欠点の１つは、複雑であることと作家がマークアップ体系の規
則を厳守するのが難しいことです。まさにこの複雑さが句読法マークアップ体
系の検証を非常に困難なものにしていますが、規則を厳守することが困難なの
で尚更これは必要です。象徴的マークアップ体系は、インデント、垂直スペー
シング等の多様性で見られるように、同じ構造情報を伝える方法が複数存在す
るという欠点があります。そのような体系は主に人の目で”処理”されるよう
に意図されているため、この体系内でのドキュメントに関する”妥当性”もほ
とんど定義されないでしょう。シーテキストを救っている良い点は、明らかに
より通例となっている手続きセマンティックスの代わりに、記述的セマンティッ
クスを句読的象徴的マークアップへ結び付けたことです。
This still does not make setext any more a descriptive markup system
than a
typewriter is a typesetting system, even if it can use more than one
font.
複数のフォントが使用できるとしても、タイプライターが自動植字システムで
ある以上に、これがシーテキストをより記述的マークアップ体系にするもので
はありません。
We should diligently strive to call a spade a spade, and not wander
off
into unknown territory claiming this and that about breakthroughs in
short-distance mud transportation technologies. If setext is
intended for
the ASCII-based on-line publications where before they had only ASCII,
and
most readers will continue to have only ASCII terminals as their primary
means of viewing the publications, then setext may be a good candidate
for
that specific field of application. It is quite clear that setext
is an
end-user presentational gimmick with high-feature ambitions that may
be
useful to ill-equipped readers if we compare it with SGML. If,
however, we
compare like with like, we find that "final formatted form" is explicitly
excluded from SGML's field of application, and that it is central to
setext's field of application, so never the twain shall meet.
("Formatted"
was changed to "imaged" in the amendment to the standard, but the original
was better, IMHO.)
価値のない短距離運搬テクノロジーでこれこれの躍進があったと主張しながら
未知の領土へ踏み迷うことなく、我々はありのままに言うよう熱心に努力する
べきです。もしシーテキストが以前はＡＳＣＩＩ以外なかったＡＳＣＩＩベー
スのオンライン出版を目的とし、そして読者の大半がそのような出版物を見る
主な手段としてただ単にＡＳＣＩＩ端末しか持っていない状態が続く場合は、
シーテキストは、そのような特殊なアプリケーションの分野での良い候補かも
しれません。シーテキストはＳＧＭＬと比較した際、装備の整っていない読者
に役立つかもしれないといった高い野望を持ったエンドユーザー用プレゼンテ
ーションの新案物であることはほとんど間違いありません。しかし、似た物ど
うしを比較すると、”最終的にフォーマットされたフォーム”はＳＧＭＬのア
プリケーション分野には明確に含まれず、しかしシーテキストのアプリケーショ
ン分野では主要なものなので、この対は決して交わることはありません。（”フ
ォーマットされた”はスタンダード（標準）の改正後”イメージ化された”に
変更されていますが、前の方が良かったと思います。）
Publications who might want to look into several media for presentation
and
on-line publication may well find setext to be suitable for their _output_
needs, in addition to postscript and DVI files. However, neither
of these
formats are suitable as _input_ formats. This is where SGML comes
in.
プレゼンテーションとオンライン出版のために数種の媒体を調べている出版者
は、ポストスクリプト及びＤＶＩファイルに加えて、シーテキストは彼らの出
力要求に向いていると見いだすかもしれません。しかし、これらのフォーマッ
ト（書式）のどれ１つとして入力書式としては不適切なものです。そこでＳＧ
ＭＬが有用になります。
"If you must compare apples and oranges, don't use redness and smoothness
as your criteria ... unless, of course, you're deliberately trying
to
mislead." -- Michael A. Padlipsky, 1985
Best regards,
</Erik>
--
リンゴとオレンジを比較しなければならない場合、赤みとなめらかさを判断基
準としてはいけない、勿論、わざと欺こうとしているのであれば別だが。
Erik Naggum
ISO 8879 SGML
+47 2295 0313
Oslo, Norway
ISO 10744 HyTime
<erik@naggum.no>
ISO 9899 C
Memento, terrigena
<SGML@ifi.uio.no>
ISO 10646 UCS
Memento, vita brevis
$$
>From ianf Tue Apr 27 01:52:43 MET DST 1993
From: ianf@random.se (Ian Feldman, Current Setext Oracle)
Newsgroups: alt.hypertext,comp.multimedia,alt.news-media,comp.text,
comp.text.sgml,comp.sys.amiga.multimedia
Date: Mon, 26 Apr 93 21:12:58 +0200
Message-ID: <a80200d3@random.se>
X-URL: file://garbo.uwasa.fi/mac/tidbits/setext/setext+sgml_03.etx
References: <1qn588INN27o@uwm.edu> <19930416.063132.922@almaden.ibm.com>
<19930420.063124.67@almaden.ibm.com> <4942@ulysse.enst.fr>
<a7fd5104@random.se> <19930423.072919.779@almaden.ibm.com>
<a800bb38@random.se> <19930426.003@erik.naggum.no>
Content-Type: setext/plain; charset=ascii_827
Organization: random design -- "Opinions, cheaply"
Lines: 188
Summary: little silliness is what makes this medium human
少々の愚行がこの媒体を人間味のあるものにします
Subject: Re: Looking for Electronic Publshing formats... [long]
Status: R
beating the setext drum, proudly
==================================
誇り高く、鳴り物入りでシーテキストを宣伝します
by Ian Feldman_
Rising up in the dead of the night to the defense_ of domains
of
the SGML, Erik Naggum_ delivers a nicely-put summation of hither-
to-gained common knowledge of the strengths and weaknesses of
by
myself advocated structure-enhanced text markup method for online
publishing use.
Erik Naggumは、ＳＧＭＬの領地を守るため真夜中に立ち上がり、私が擁護し
ているオンライン出版で使用するのための構造性を高めたマークアップ方法の
利点と弱点に関して今までに得られている共通の知識を上手に要約して述べて
います。
Given that I readily admit the limits to usefulness of the setext,
esp. in heavy-duty, "professional," applications where
nothing
but the SGML WILL DO, perhaps nothing further needed to be said
about it. We all realize that should ever a different
markup be
required in similar circumstances, it would have to be as complex
as is the SGML. Therefore, why bother?
特にＳＧＭＬしか役に立たないような激務に耐える必要のある”専門家”用の
アプケーションでは、私はシーテキストの実用性の限界を躊躇なく認めている
ので、恐らくそれに関して更に付け加える必要はなにもないでしょう。同じよ
うな状況で異なるメークアップが要求される場合は、ＳＧＭＬのような複雑な
ものにならざるえないということは我々全員が了解していることです。ですか
ら、なぜかまうの？
Still, no less for the sake of completeness before we wrap this
debate up, I feel that I ought to mention that several of Erik's
points have indeed been addressed in setext, to the extent that
it
was deemed possible. I have yet to read the referenced
CACM
article_, which sounds an appropriate basis enough for the purpose
of this discussion, but the accumulated effect of other works
in
the field that I've read must have inspired me enough to come
up
with such an Obviously Grand-Delusional Scheme To Wrap Text
Up ;-))
それでもやはりこの討論に決着をつける前に、徹底させるという理由で Erik
の論点の幾つかはシーテキストで実際に可能だと思える程度まで取り組まれた
ということに触れておくべきだと感じます。この討論の目的には十分で且つ適
切な基礎だと思われる参考資料(ＣＡＣＭ)を読む必要があるのですが、私が今
まで読んだこの分野における他の著書の累計的効果がこういう明らかに誇大妄
想的なテキストフォーマット方法を考え出す上で大いに影響を与えたことはほ
ぼ間違いありません。
For starters, both the important document-validation and adherence
(to punctuational markup; difficulties of) aspects have not
passed
unmentioned in the setext. They are also explicitly documented,
albeit not in precisely such semantically-correct terms, in
the
two sermons_ that have been issued and are stored at the setext
archival site_ (which is _not_ the same as the TidBITS listserver,
see below).
まず第一に、重要なドキュメント検証、及び(句読法的マークアップを)厳守(す
ることの困難さ)の様相の２点はシーテキストで触れられなかったわけではあり
ません。これらは、セマンティックス的に正確な用語ではありませんが、発布
されそしてシーテキストのアーカイブサイト（これはTidBITSのリストサーバと
は異なります；下を参照してください）に保管されている２つの説教の中で詳
しく記録されています。
Erik Naggum says:
-------------------
> In SGML, the markup is rigid and this is exploited by offering
> validation services for SGML documents as part of the processing.
> Indeed, the idea that the markup is or is not "valid" independent
> of its processing is one of SGML's strongest points.
ＳＧＭＬにおけるマークアップは厳密であり、だから処理の一部としてＳＧＭ
Ｌドキュメントの検証サービスを提供することで活用されています。実際にマ
ークアップがその処理とは無関係に”有効”又は”無効”であるという考え方
がＳＧＭＬの最も顕著な長所の一つです。
Agreed. Setext "employs" a technique of _detection_ whether
any
submitted doc is a setext or not -- I suppose it could be called
a
form of validation prior to decoding. If not containing
at least
one valid subhead or title, then the document is to be treated
(and _paged_ through by mechanical means if displayed) as just
another plaintext. All the other typotags are considered
optional
and of lesser importance so, as much for reasons of simplicity,
as
for the need to prevent delays at runtime, they're not subjected
to checks until decoding. Admittedly this process is a
simple
one, but it's there nevertheless.
同意します。シーテキストは提出されたドキュメントがシーテキストかどうか
を調べる検出技術を用いています。これは、私は解読に先立つ検証方式と呼ん
でいいと考えているもので、少なくとも１つ正当なサブヘッダー又は表題を含
んでいないテキストは、ただ単に単純なテキストとみなされ、（表示される場
合、機械的な手段でページをめくるように見ることができます。）その他のタ
イポタグはすべてオプションで重要度は低いものとみなされます。ですから実
行時の遅れをなくす必要性と同じく簡略化の理由で、それらのタグは解読時ま
で確認の対象とはなりません。正直なところ、この処理は簡単なものですが、
それにもかかわらずこの処理を加えています。
> setext, is a sort of cross-breed between punctuational and
> presentational markup system with delusions of grandeur if
> I may put it in a hostile form. One of the disadvantages of
> punctuational markup [...] is its complexity and the difficulty
> of authors to adhere to conventions.
シーテキストは句読法的マークアップと象徴的マークアップの混成物のような
もので、敵意のある表現になりますが誇大妄想的なマークアップシステムです。
上記の資料で詳述されているように、句読的マークアップの欠点の１つは複雑
であることと作家がマークアップ体系の規則を厳守するのが難しいことです。
Precisely in order to address that latter point, effectively
to _lower_ the threshold of complexity and raise that of input
tolerance, setext's SOLE elements of importance, the subheads
(and
titles), require but that the writer/ publisher create them
using
a monospaced font (which, surprizingly enough, is not a widely-
understood base prerequisite for all publishing intended for
online distribution and -consumption).
まさにそのとうりです。効果的に複雑さを緩和し入力許容度を上げるという後
者の点と取り組む目的で、著者又は出版者はシーテキストの唯一重要な要素で
あるサブヘッダー（及び表題）には固定長フォントを使うことが要求されます。
（固定長フォントは、意外にもオンライン配布と消費を目的とした出版全般の
ための、広範に理解されている、基礎必須条件ではありません。）
Subheads and titles, you may care to recall, are both defined
as
"string of characters, that may be indented by any number of
spaces, followed by a line ALWAYS beginning in column 1 and
made
up of as many dashes (or equal-signs for the titles) as there
is
the number of _rightmost_visible_ characters in the subhead/
title
above."
サブヘッダーと表題は、思い出してください、どちらも”制限されない数の空
白文字でインデントできる文字列で、必ず第一桁から始まり上部のサブヘッダ
ー或いは表題の目に見える右端の文字までの数と同じ数のハイフォン（又は表
題の場合は等符号）からなる一行が続きます。
Imagine a "2-line-box" that is anchored firmly at the left margin,
where the asterisk is below, and that the last _visible_
character of the line above it is the plus (+). Grab hold of
the latter and move freely left-right, never mind any trailing
spaces, here expressed with underscore characters "_"
The all-
dash line's length is supposed to equal that of line's above
length counted in characters from column 1 to that of the +
下の行の左端に星印（アステリスク）があり、そしてその上の行で目に見える
最後の文字がプラス(+)といった、左余白でしっかりと固定された”２行”を想
像してください。このプラスを摘まみ、後ろにひきずっている空白文字（ここ
では下線 "_" 文字で表されている）は気にせず左右自由に移動させてください。
ハイフォンだけからなる行の長さは、その上の行の第一桁からプラス文字まで
の文字数と等しくすることになっています。
your possibly-indented
subhead here+_________
*--------------------------------------------____
Indeed, both the first, subhead-string, and the subhead-typotag
lines can carry trailing, to the eye defacto invisible, white
space and still be considered valid. Perhaps this may
strike
someone as needlessly complex and confounding but as the method
stands and falls on this _sole_ instance of non-negotiable
adherence to punctuational exactness, equal rightmost-visible
monospaced length of two lines of which one is a tag for the
other, I decided to make it as tolerant of input errors as
possible. After all, either line could end up with trailing
spaces unbeknownst to the author/ publisher.
実は、最初のサブヘッダー文字列とサブヘッダータイポタグ行は、後ろにひき
ずる空白文字（事実上目には見えない）を含むことができ、その場合でもなお
妥当だと見なされます。このことは不必要に複雑でそして当惑させるという印
象をことによると与えるかもしれません。しかし、固定長文字で目に見える右
端までの長さが同じ２行で、そのうちの一方は他方のタグであるといった、こ
のただ一つの譲歩できない句読法的条件を厳密に守ることにすべてがかかって
いる方法なので、私は入力エラーをできるだけ許容するように作ろうと決めま
した。結局、どちらの行も著者または出版者に気づかれないまま空白を後ろに
ひきずっている可能性があります。
As for the need for adherence in regard to the other typotags
--
the setext is explicitly targeted towards _publishers_ of online
periodic matter, rather than towards (mere ;-)) authors.
This is
an important distinction, since publishers can more readily
be
expected to ensure compliance with a given markup, whether they
have full validation tools at their disposal or not (or else
they're "worse publishers" than the other guys). I had
never
considered it generic enough for use by everybody and his brother
(in-law['s {cousin's /neighbor/}]). Whatever it is that
makes
Erik Naggum, Eliot Kimber_, myself and a few other individuals
(too few) adapt our writing style to the rigours of this narrow-
bandwith medium, hand-code our texts in some near-optimal fashion,
could therefore be expected of other _publishers_ as well, those
for whom the setext primarily has been defined. We are
authors,
but we're also publishers. Those that do not care how
(chaotic)
their thoughts may appear online are "typing" at best, not writing
and definitely not "publishing." They post, therefore they exist.
その他のタイポタグに関して厳守の必要性はどうかといえば -- シーテキスト
は単なる著者でななくオンラインによる定期的出版物の出版者をはっきりとし
た対象としています。出版者の方が、自由に使える完全な検証ツールのあるな
しにかかわらず、与えられたマークアップにより従順に従うことが期待できる
ので（でなければ、他よりも下手な出版者です）これは重要な区別です。私は
決してシーテキストが、みんな（兄弟姉妹、義理の兄弟姉妹、いとこの兄弟姉
妹、及び彼らの隣人）が使用できるほと包括的だと考えたことはありません。
Erik Naggum、 Eliot Kimber、私自身そして他の個人（余りにも少ない）が、
我々の書法方式をこの狭い帯域幅（バンドウイドス）媒体のきびしさに適応さ
せる、或いはほぼ最適化されたやり方でテキストを手でコード化する理由はな
んであれ、他の出版者も同様にそのことが求められるでしょう。シーテキスト
は本来このような出版者のために定義されました。我々は著者であり同時に発
行者です。彼らの意見がオンラインでどんなに（混沌と）公表されようと気に
かけない人は、せいぜいタイプしているだけであって文章を書いているのでも
なければ、決して”出版”しているのでもありません。彼らは電子出版物を郵
送する、それゆえに彼らは存在しているのです。
areas of application
----------------------
応用範囲
> If setext is intended for the ASCII-based on-line publications
> [...] then [it] may be a good candidate for that specific field
> of application. It is quite clear that setext is an end-user
> presentational gimmick with high-feature ambitions that may be
> useful to ill-equipped readers if we compare it with SGML.
もしシーテキストが以前はＡＳＣＩＩ以外なかったＡＳＣＩＩベースのオンラ
イン出版を目的とし、そして読者の大半がそのような出版物を見る主な手段と
してただ単にＡＳＣＩＩ端末しか持っていない状態が続く場合は、シーテキス
トは、そのような特殊なアプリケーションの分野での良い候補かもしれません。
シーテキストはＳＧＭＬと比較した際、装備の整っていない読者に役立つかも
しれないといった高い野望を持ったエンドユーザー用プレゼンテーションの新
案物であることはほとんど間違いありません。
It is intended for precisely that kind of audience and acc.
to my
experiences the ill-equipped readers are the norm in RealLife[tm],
rather than the exception. It is the Academia and the
High
Commerce that are the freaks here ;-)) So it is gimmicry, smoke
and mirrors is what we have to contend ourselves with, in lieu
of
absence of more suitable tools.
シーテキストはまさにそのような読者のために意図されたもので、私の経験に
よれば、不十分な装備しか持っていない読者のほうが実生活 RealLife[tm]で
は、例外ではなくむしろ典型的なのです。ここでは学究的な世界に関係する人
および高級品を好む者が変わり者なのです。ですから、より適切なツールがな
くて我慢する代わりに、我々が安んじなければならない(content)のは手品師
の小道具、煙、カガミです。
> If, however, we compare like with like, we find that "final
> formatted form" is explicitly excluded from SGML's field of
> application, and that it is central to setext's field of
> application, so never the twain shall meet.
しかし、似た物どうしを比較すると、”最終的にフォーマットされたフォーム”
はＳＧＭＬのアプリケーション分野には明確に含まれず、しかしシーテキスト
のアプリケーション分野では主要なものなので、この対は決して交わることは
ありません。
Sure, how can we compare something to That Which Has No Equals?
確かに、では同等なものが存在しなものはどう比較できるのですか？
uses of setext for input
--------------------------
シーテキストの入力用使用
> Publications who might want to look into several media for
> presentation and on-line publication may well find setext to be
> suitable for their _output_ needs, in addition to postscript and
> DVI files. However, neither of these formats are suitable as
> _input_ formats. This is where SGML comes in.
プレゼンテーションとオンライン出版のために数種の媒体を調べている出版者
は、ポストスクリプト及びＤＶＩファイルに加えて、シーテキストは彼らの出
力要求に向いていると見いだすかもしれません。しかし、これらのフォーマッ
ト（書式）のどれ１つとして入力書式としては不適切なものです。そこでＳＧ
ＭＬが有用になります。
The last sentence is disputable at best... by virtue of
its
inobtrusive and highly "natural" notation (observe the quotes)
the
setext may be a more appropriate method for hand-encoding of
_basic_ structure into (limited-size) documents than is the
SGML.
Once done they may later be enhanced further still in more-appro-
priate, validated markup environemnts. Else this wish-list
from
a known Internet high-flyer figure_ has no basis in reality:
最後の文は、いくらよく見ても議論の余地があります。 目立たなく、非常に
”自然な”表記法（引用に注意してください）のおかげで、シーテキストはＳ
ＧＭＬよりも、（限られたサイズの）ドキュメントへ基本構造を手でコード化
するためのより適切な方法と言って差し支えありません。一度行っておけば、
後でより適切な実証済みのマークアップ環境で更に質を高めることができます。
でなければ、一般に知られているインターネットの野心家的人物が出したこの
欲しいもの一覧は、実際には根拠を持たないでしょう：
> Some concrete things to do for setext:
シーテキストのためのに行う幾つかの具体的なこと
> - do the setext to troff, setext to postscript, setext to rtf
> formatters so we can put things onto paper
> - do the setext to RFC format converter so we can write RFCs
> in setext and then convert them off easily
> - get setext blessed by Postel et al in the IETF so we can
> do proper MIME stuff
> - nail down the URL business
> - do the setext to HTML bit
setextからtroff、setextからpostscript、そしてsetextからrtfへの書式プ
ログラムを作成する。そうすれば用紙上に出力できます。
シーテキストからRFC書式へのコンバーターを作成する。そうすればRFCをシー
テキスト書式で書くことができ、その後わけなく変換できます。
IETFのPostelなどでシーテキストを賞賛してもらう。それで我々は然るべきMIME
に関することができるようになります。
URLビジネスを見極める。
シーテキストからHTMLへの変換を行う。
> ah, there is plenty of work to be done...
ああ、やる事がいっぱいある...
Delusions of grandeur, eh?
誇大妄想、じゃないの？
__Ian "The ``I had the bug narrowed down to a subroutine and then
I lost all interest'' hacker"
Feldman <ianf@random.se>
”サブルーティンまでバグをしぼりその後すべての興味を失った”ハッカー
.. _site file://garbo.uwasa.fi/mac/tidbits/setext/
.. _sermons file://garbo.uwasa.fi/mac/tidbits/setext/?sermon_*
.. _figure (delusions of grandeur or NOT, I am no name-dropper; let
him come
forward and disclose his own views in person)
.. _defense news:19930426.003@erik.naggum.no
.. _article news:19930426.003@erik.naggum.no/"Coombs, Renear and DeRose"
.. _Naggum <erik@naggum.no> (Erik Naggum)
.. _Kimber <drmacro@ralvm13.vnet.ibm.com> (Eliot Kimber)
.. _Feldman <ianf@random.se> (Ian Feldman)
$$
本サイトに関するお問い合わせ先: webmaster@piedey.co.jp
ソフトウェアに関するお問い合わせ先: support@piedey.co.jp
作成: 株式会社ピーデー・川俣 晶/autumn@piedey.co.jp