Обсуждение:Элемент cite
Возможно имеет смысл оформить список подчиненных элементов примерно таким образом
| Элемент | Кол-во | Ограничения |
|---|---|---|
| <p> | 0..n | нет |
| <subtitle> | 0..n | нет |
| <empty-line> | 0..n | нет |
| <poem> | 0..n | нет |
| <table> | 0..n | нет |
| <text-author> | 0..n | только последним |
На мой взгляд таблица более наглядно представляет все нюансы применения подчиненных элементов. В имеющимся же варианте, во-первых придется вчитываться в текст, во вторых из него не понятно что text-author одолжен быть именно последним. Есть еще пара замечаний...
Таблица явно требует доформотрирвания и возможно некоторой смысловой раскраски. Если вы за, то просто перенесите ее в основной текст. Против -- прибейте комментарий (BergShrund 06 февраля 2006 00:16 )
На самом деле и таблица и мой (оригинальный) варианты имеют ряд недостатков. Идеи которые применялись в моей записи:
- Вложенные списки (если список нумерованный - это значит, что последовательность важна, если нет - то как раз или один из списка, или произвольная последовательность из элементов (то, что я указывал текстом).
- Пометки обязательности/числа элементов (у меня указывается как "численное" обозначение, так и словесное). Это я сам считаю перебором и подумываю обзначать просто "+", "?", "*", ну и можно "." или ничего для случая один и обязательно... a-la DTD).
Твоя таблица, смотрится несколько аккуратнее и более структурировано, но ты же сам и указываешь на невнятность в случае последовательностей и выбора.
Пока у меня назревает идея несколько формализовать свой вариант представления ... заодно его можно запихнуть и в твою таблицу (ну а для порядка везде указывать ссылку на легенду):
| Структура | Элемент | комментарии |
|---|---|---|
| 1 (*) | ||
| • (?) | <p> | |
| • (?) | <subtitle> | |
| • (?) | <empty-line> | |
| • (?) | <poem> | |
| • (?) | <table> | |
| 2 (?) | <text-author> |
Хотя запись вида:
- (*) -
- - <p>
- - <subtitle>
- - <empty-line>
- - <poem>
- - <table>
- (?) - <text-author>
Смотрится не хуже, хотя оба варианта и требуют легенды для расшифровки, но по крайней мере позволяют задать однозначные ограничения (правда тут тоже спорно, в какой степени это описание должно дублировать схему...)
Кроме того можно подумать о картинках (на которых нарисовать что-то вроде структурной диаграммы), но их хорошо сделать в дополнение к списку.
В любом случае надо подобрать оптимальный вариант.
P.S. Запустил Konquer (3.2.3) - никаких проблем с уникодными путями не заметил - а это уже достаточно древний. Может у тебя результат неудачной борьбы с возможной подменой на основе IDN?
--Gremlin 11:30, 6 февраля 2006 (MSK)
если список нумерованный - это значит, что последовательность важна
ИМХО Постороннему человеку это совершенно не очивидно, как неочевидно мне сейчас. Мало того, даже если где-то об этом правиле оформления написать, то все равно пользы не будет никакой, потому что документацию в большинстве случаев читают с середины. Нужно представить информацию так, чтобы посторонний человек посмотрев на страницу смог понять какие именно ограничения накладываются на подчиненные элементы. На мой взгляд столбец "ограничения" решает эту задачу, а нумерованный список -- нет.
подумываю обзначать просто "+", "?", "*", ну и можно "." или ничего для случая один и обязательно... a-la DTD
Ни в коем случае! ;-)
Пользователь совершенно не обязан даже знать что такое DTD чтобы пользоваться этой документацией, и тем более разбираться в принятых в нет условных обозначениях. В качестве примера могу привести себя. Я весьма приблизительно знаю что такое DTD, и это нисколько не мешает мне создавать fb2 книги. На мой взгляд обозначения типа 1..n будут понятны более широкому кругу пользователей. Для более удобного чтения можно попробовать раскрасить ячейки в разные цвета в зависимости от того в каком количестве можно применять тег. Но текст в ячейке должен быть однозначно понятен любому пользователю с задатками технического образования.
С цветами это должно быть примерно так:
| Элемент | Кол-во | Ограничения |
|---|---|---|
| <genre> | 0 .. 1 | нет |
| <author> | 0 .. n | нет |
| <book-title> | 1 | нет |
| <annotation> | 0 .. 1 | нет |
| <keywords> | 0 .. 1 | нет |
| <date> | 0 .. 1 | нет |
| <coverpage> | 0 .. 1 | нет |
| <lang> | 1 | какое-то ограничение |
| Ну и так далее.... |
"Кроме того можно подумать о картинках (на которых нарисовать что-то вроде структурной диаграммы), но их хорошо сделать в дополнение к списку."
Я не видел еще ни одной картинки из которой было бы что-то понятно. По крайней мере те диаграммы которые были в предидущим вики, так те просто ни в какие вороты. Они могут быть понятны либо тем кто и так схему уже знает, либо крутым спецам по подобного рода диаграммах.
Вот.
Я тут наверное немного раскину пальцы и поясню на каком основании я делаю вывод об очевидности и неочевидности: Дело в том, что я в течении какого-то времени был преподавателем, и притом преподавателем весьма неплохим. Один из необходимых элементов преподавания -- уметь посмотреть на пододаваемую информацию не с колокольни специалиста, а с точки зрения человека в предмете ничего не понимающим. Некоторым образом мне это удается. Так что когда я говорю о неочевидности, то следует понимать, что я эмулирую постороннего человека, смотрю его глазами на документ, и понимаю что этот посторонний человек ничего не понимает. А моими глазами все очевидно. Я и схему могу почитать, с переменным правда успехом, но могу.
Что же касается Konqueror'а то проблемы там возникают при попытки скопировать url из окна в окно, или при попытке отредактировать url в текущем окне. У меня есть профессиональная привычка, если что-то не получается, то первым делом добавить в url либо вопросительный знак, либо амперсант, если "?" уже есть. И тут то я и обломался...
(BergShrund 06 февраля 2006 23:40 )
