Обсуждение:Элемент cite
Материал из FictionBook.
Возможно имеет смысл оформить список подчиненных элементов примерно таким образом
Элемент | Кол-во | Ограничения |
---|---|---|
<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 либо вопросительный знак, либо амперсант, если "?" уже есть. И тут то я и обломался...