| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
Alex
Постоянный участник форума
Зарегистрирован: 24.12.2004
Сообщения: 648
Откуда: Kiev, UA
|
 Добавлено: Пт Ноя 25, 2005 16:01 Заголовок сообщения: |
 |
|
Admin
А что дерзать? Неужели картинок мало?  По ним вроде все понятно...
Ладно, еще, примеры пойму... 
_________________
С уважением, Алекс.
Sony Clie PEG TJ-37 + MS 256 Mb (Palm OS 5.2.1 + PalmFiction 0.14t)
Siemens S75 + ReadManiac 2.6
а иногда я еще и бумажные книги читаю... |
|
| Вернуться к началу |
|
 |
Alan
Автор ридера Alreader и клона Haali
Зарегистрирован: 25.01.2005
Сообщения: 421
|
| Добавлено: Пт Ноя 25, 2005 19:15 Заголовок сообщения: |
|
|
Shaman
| Цитата: | | Однако товарисча Алана понесло на личности. И с этого момента он прочно перелез в категорию "... в штатском". Плесень. Я серьезно. |
ты с чего то взял, что меня должны волновать твои невротические позывы? Меньше отвлекайся:) |
|
| Вернуться к началу |
|
|
Gremlin
Зрелый участник форума
Зарегистрирован: 14.02.2005
Сообщения: 155
|
| Добавлено: Пт Ноя 25, 2005 20:06 Заголовок сообщения: |
|
|
| Admin писал(а): | | Уф-a! Закончил подготовку заготовок для описания элементов и выложил все схемы. Так что терзайте. |
Сразу предложения по изменению изложения материала 
1. На странице UsingTags описать дерево структуры, а потом индекс tag'ов (Элементов) и индекс аттрибутов (если окажется много для одной страницы, то можно разбить по подстраницам). Например:
Структура:
- FictionBook
- stylesheet
- describtion
- title-info
- src-title-info
- ...
- body
- ...
Элементы:
Аттрибуты:
Причем надо перечислить все элементы и аттрибуты.
Тогда и в описаниях вроде annotation не придется писать "...В последовательности дочерних элементов <title-info> занимает четвертое место после обязательных элементов genre, author, book-title, но перед keywords, date, coverpage, lang, src-lang, translator, sequence..." проще будет состлаться на родителя (здесь title-info), где для каждого элемента будет указан его порядок и число вхождений (хотя про обязательность не вредно и в описании аттрибута упомянуть). |
|
| Вернуться к началу |
|
|
Glassy
Модератор
Зарегистрирован: 05.11.2004
Сообщения: 1074
Откуда: Москва
|
| Добавлено: Пт Ноя 25, 2005 20:14 Заголовок сообщения: |
|
|
Gremlin
Мне кажется, что проще описать все на одной странице, чтобы не возникало вопросов в дальнейшем. |
|
| Вернуться к началу |
|
|
Admin
Администратор информационного портала FB
Зарегистрирован: 11.06.2004
Сообщения: 1610
Откуда: Воронеж
|
| Добавлено: Пн Ноя 28, 2005 8:54 Заголовок сообщения: |
|
|
| Alex писал(а): | А что дерзать? Неужели картинок мало? Shocked По ним вроде все понятно...
Ладно, еще, примеры пойму... Embarassed |
Ну, лично для меня достаточно и схемы, но надо учитывать, что еще не все легко читают схему. Кроме того, анализ содержимого библиотеки показал, что есть товарищи, которые не к месту пользуются тегами, значит надо рекомендации и примеры. И в итоге надо оценить достаточность и необходимость тега, чтобы понять, куда двигаться дальше. | Gremlin писал(а): | Сразу предложения по изменению изложения материала Smile
|
Сьруктура описания соответствует структуре схемы. Кроме того, аттрибуты не имеют смысла в контекста элемента, аттрибуты одного названия (например, type) в разных элементах имеют разный смысл. | Gremlin писал(а): | | Тогда и в описаниях вроде annotation не придется писать "...В последовательности дочерних элементов <title-info> занимает четвертое место после обязательных элементов genre, author, book-title, но перед keywords, date, coverpage, lang, src-lang, translator, sequence..." проще будет состлаться на родителя (здесь title-info), где для каждого элемента будет указан его порядок и число вхождений (хотя про обязательность не вредно и в описании аттрибута упомянуть). |
Это я описывал первый элемент. Теперь, когда выложена структура, я так и сделаю, то есть перепишу, сославшись (дав ссылку) на родительский элемент. | Glassy писал(а): | | Мне кажется, что проще описать все на одной странице, чтобы не возникало вопросов в дальнейшем. |
К сожалению, в wiki ограничены размеры страницы, там даже просто схема не умещается, поэтому ссылки на всю схемы - внешние. |
|
| Вернуться к началу |
|
|
Gremlin
Зрелый участник форума
Зарегистрирован: 14.02.2005
Сообщения: 155
|
| Добавлено: Пн Ноя 28, 2005 11:01 Заголовок сообщения: |
|
|
| Admin писал(а): | | Gremlin писал(а): | Сразу предложения по изменению изложения материала Smile
|
Сьруктура описания соответствует структуре схемы. Кроме того, аттрибуты не имеют смысла в контекста элемента, аттрибуты одного названия (например, type) в разных элементах имеют разный смысл. |
Мое дело предложить... (а если серьезно, я это изложил здесь, чтобы можно было обсудить и прийти к оптимальному решению... пусть даже только на некоторый этап).
Идей в моем предложении было несколько:
1. Дерево предлагалось как более компактное отображение структуры из схемы, хотя признаю, что грамотно напихать туда все возможные комбинации и трудно... и может сбить с толку... и просто станет слишком громоздко. Если не делать общей лесенки, а расписывать только структуру текущего элемента... то и в самом деле получится что-то вроде того что есть .
2. Аттрибуты я предложил, поскольку увидел их под вывеской "Простые типы". Кстати то, что они имеют разное значение - не помеха тому чтобы перечислить все эти значения в описании,и указать ссылки на тэги (где они будут описаны подробнее). Впрочем можно их и вовсе в индекс не выносить (и не создавать им отдельных статей).
3. Не вижу особого смысла в делении тэгов на "простые" и "сложные". Думаю что должен быть полный индекс, ну и в качестве бонуса еще можно напридумывать категорий, например: "описание книги", "структура текста", "форматирование(стили)" куда их и поотносить.
4. А еще можно (кстати тут и могут помочь наработки в wiki) написать более подробные комментарии для схемы, чтобы при очередной генерации оттуда документации получилось что-то более подходящее для читателей схемы. Тем более, что семантику все равно формально не описать. |
|
| Вернуться к началу |
|
|
Admin
Администратор информационного портала FB
Зарегистрирован: 11.06.2004
Сообщения: 1610
Откуда: Воронеж
|
| Добавлено: Пн Ноя 28, 2005 11:37 Заголовок сообщения: |
|
|
| Gremlin писал(а): | Дерево предлагалось как более компактное отображение структуры из схемы, хотя признаю, что грамотно напихать туда все возможные комбинации и трудно... и может сбить с толку... и просто станет слишком громоздко. Если не делать общей лесенки, а расписывать только структуру текущего элемента... то и в самом деле получится что-то вроде того что есть Smile.
|
Я первоначально так и хотел сделать, но посмотрел, как генерирует формальную документацию Stylus XML (последняя ссылка в перечне элементов в wiki, и мне это тоже показалось разумным, причем именно оттуда я выдрал рисунки, рисовать все для другой организации описания (как я делал это год назад) мне не хочется - рисунки требуют много времени. | Gremlin писал(а): | | Не вижу особого смысла в делении тэгов на "простые" и "сложные". |
Вся структура схемы опирается на простые и сложные типы. Если реализовывать дерево, то пришлось бы описывать однотипные элементы в разных родительских элементах. А так мы просто указываем что в аннотации применяется тип "р" и в секции применяется тип "р". А тип "р" описываем отдельно - это более компактно и проще ориентироваться, тем более что при описании и аннотации и секции можно просто сделать ссылку на описание типа "р". Простые и сложные типы имеют фундаментальные различия в XML и это надо подчеркнуть. | Gremlin писал(а): | | А еще можно (кстати тут и могут помочь наработки в wiki) написать более подробные комментарии для схемы, чтобы при очередной генерации оттуда документации получилось что-то более подходящее для читателей схемы. Тем более, что семантику все равно формально не описать. |
Это я и подразумевал, тем более, что замена содержимого тега документации никак не влияет на реализации редактором и ридеров, но делает схему более понятной. Кроме того, документацию в схеме надо сделать так, как я сделал в FBAuthor, то есть на русском и английском языке. |
|
| Вернуться к началу |
|
|
Gremlin
Зрелый участник форума
Зарегистрирован: 14.02.2005
Сообщения: 155
|
| Добавлено: Пн Ноя 28, 2005 14:32 Заголовок сообщения: |
|
|
| Admin писал(а): | | Я первоначально так и хотел сделать, но посмотрел, как генерирует формальную документацию Stylus XML (последняя ссылка в перечне элементов в wiki, и мне это тоже показалось разумным, причем именно оттуда я выдрал рисунки, рисовать все для другой организации описания (как я делал это год назад) мне не хочется - рисунки требуют много времени. |
То что много времени не страшно. На то и Вики - кто-нибудь заполнит, и его поправят в случае ошибки.
Главное здесь определиться именно со структурой изложения материала, чтобы не превратиться в свалку бесполезных сведений.
| Admin писал(а): | | Gremlin писал(а): | | Не вижу особого смысла в делении тэгов на "простые" и "сложные". |
Вся структура схемы опирается на простые и сложные типы. Если реализовывать дерево, то пришлось бы описывать однотипные элементы в разных родительских элементах. А так мы просто указываем что в аннотации применяется тип "р" и в секции применяется тип "р". А тип "р" описываем отдельно - это более компактно и проще ориентироваться, тем более что при описании и аннотации и секции можно просто сделать ссылку на описание типа "р". Простые и сложные типы имеют фундаментальные различия в XML и это надо подчеркнуть. |
А можно поподробнее о "простых" и "сложных" типах?
У меня сложилось впечатление, что это деление на элементы и аттрибуты (p и align).
Или здесь имеется в виду что-то другое, например xs:simpleType и xs:complexType из схемы? Тогда тем более нет смысла. Тот кто понимает схему - посмотрит в нее, а того кто не понимает это только собъет с толку. Перечислять нужно только те элементы, которые могут встретиться в xml, а детали того как это описано в xsd (там более, что можно было и по другому записать - главное, какие ограничения на xml получаются) здесь несущественны. Ну а разбираться (в особенности тому, кто схему не представляет) относится tag к "сложным" или "простым" что бы посмотреть на него документацию - лишнее. |
|
| Вернуться к началу |
|
|
Admin
Администратор информационного портала FB
Зарегистрирован: 11.06.2004
Сообщения: 1610
Откуда: Воронеж
|
| Добавлено: Пн Ноя 28, 2005 16:38 Заголовок сообщения: |
|
|
| Gremlin писал(а): | | Или здесь имеется в виду что-то другое, например xs:simpleType и xs:complexType из схемы? Тогда тем более нет смысла. Тот кто понимает схему - посмотрит в нее, а того кто не понимает это только собъет с толку. Перечислять нужно только те элементы, которые могут встретиться в xml, а детали того как это описано в xsd (там более, что можно было и по другому записать - главное, какие ограничения на xml получаются) здесь несущественны. Ну а разбираться (в особенности тому, кто схему не представляет) относится tag к "сложным" или "простым" что бы посмотреть на него документацию - лишнее. |
Сложные типы - это типы, имеющие в своем составе дочерние элементы и/или атрибуты. С точки зрения получения информации они указывают только связи, порядки, подчиненность. Сама информация, т.е. текст находится в простых типах и именно они нас и интересуют с точки зрения получения текста. То есть разница существенная. Что касается схемы, то описание, не заменяет, а дополняет схему. Для тех, кто хочет разобраться в схеме, оно будет помощником, для тех кто не хочет - филькиной грамотной, причем малополезной.
Добавлено спустя 3 минуты 21 секунду:
Кроме того, не надо придумывать чего еще нет, когда пишешь описание, недостатки структуры сами выплывают, сегодня я добавил в структуру еще три элемента, которые не учел ранее. |
|
| Вернуться к началу |
|
|
Gremlin
Зрелый участник форума
Зарегистрирован: 14.02.2005
Сообщения: 155
|
| Добавлено: Пн Ноя 28, 2005 18:57 Заголовок сообщения: |
|
|
| Admin писал(а): | | Сложные типы - это типы, имеющие в своем составе дочерние элементы и/или атрибуты. С точки зрения получения информации они указывают только связи, порядки, подчиненность. Сама информация, т.е. текст находится в простых типах и именно они нас и интересуют с точки зрения получения текста. То есть разница существенная. Что касается схемы, то описание, не заменяет, а дополняет схему. Для тех, кто хочет разобраться в схеме, оно будет помощником, для тех кто не хочет - филькиной грамотной, причем малополезной. |
Т.е. к простым типам относится только <empty-line/>? С этой точки зрения лучше делить типы на относящиеся к описанию, к структуре, способные содержать непосредственно текст...
Но все равно для нормального поиска нужно привести общий индекс всех элементов (чтобы не пытаться понять классификацию если тебе нужно узнать описание конкретрого тэга). Кроме того Align, DocGenerationInstruction и ShareModes нужны только для того чтобы сбить с толку. В схеме их нет (кроме аттрибута align, который лучше описывать в таблицах), тем более и в выходном xml их быть не может. Режимы же, относящиеся к платному документу должны быть доступны через свою статью (из элементов/FAQ) а не через исскуственно придуманные элементы.
| Admin писал(а): | | Кроме того, не надо придумывать чего еще нет, когда пишешь описание, недостатки структуры сами выплывают, сегодня я добавил в структуру еще три элемента, которые не учел ранее. |
Добавить то, что было упущено - не проблема. Меня пока останавливает от редактирование именно непонимание того, что мы хотим получить, а корежить страничку туда-сюда как два беседочника один шалашик не хочется.
И все-таки хочется получить что-то понимаемое чуть легче, чем схема, иначе польза от всего этого крайне сомнительна.
P.S. А то что все имена "типов" (элементов?) начинаются с большой буквы - это ограничения wiki или какая-то задумка? |
|
| Вернуться к началу |
|
|
Admin
Администратор информационного портала FB
Зарегистрирован: 11.06.2004
Сообщения: 1610
Откуда: Воронеж
|
| Добавлено: Вт Ноя 29, 2005 9:00 Заголовок сообщения: |
|
|
| Gremlin писал(а): | | Кроме того Align, DocGenerationInstruction и ShareModes нужны только для того чтобы сбить с толку. В схеме их нет (кроме аттрибута align, который лучше описывать в таблицах) |
??? Ты схему-то смотрел? | Gremlin писал(а): | | Меня пока останавливает от редактирование именно непонимание того, что мы хотим получить |
Я уже не первый раз говорю, описание соответствуем схеме. | Gremlin писал(а): | И все-таки хочется получить что-то понимаемое чуть легче, чем схема, иначе польза от всего этого крайне сомнительна.
|
Сомнительным будет отрыв от схемы. | Gremlin писал(а): | | А то что все имена "типов" (элементов?) начинаются с большой буквы - это ограничения wiki или какая-то задумка? |
Это wiki-имя. |
|
| Вернуться к началу |
|
|
Gremlin
Зрелый участник форума
Зарегистрирован: 14.02.2005
Сообщения: 155
|
| Добавлено: Вт Ноя 29, 2005 9:41 Заголовок сообщения: |
|
|
| Admin писал(а): | | Gremlin писал(а): | | Кроме того Align, DocGenerationInstruction и ShareModes нужны только для того чтобы сбить с толку. В схеме их нет (кроме аттрибута align, который лучше описывать в таблицах) |
??? Ты схему-то смотрел? |
Нет, я ее ушами слушал
Ну нет там таких тэгов!
Есть правда, то что в DTD называется ENTITY c похожими именами (например shareInstructionType ...) но это во первых не то что ты описал (приписка Type помимо просто различия в названии позволяет легче понять что это не элемент), а во вторых тэгами не является и в xml'е появиться не может.
ИМХО информация об этих сущностях нужна только программисту, а правильной программист (неправильный же программист должен давать неправильный мед ) лучше поймет схему, чем то описание которое получается.
| Admin писал(а): | | Gremlin писал(а): | | Меня пока останавливает от редактирование именно непонимание того, что мы хотим получить |
Я уже не первый раз говорю, описание соответствуем схеме. | Gremlin писал(а): | И все-таки хочется получить что-то понимаемое чуть легче, чем схема, иначе польза от всего этого крайне сомнительна.
|
Сомнительным будет отрыв от схемы. |
И как это я столько лет пользовался DTD (который вообще не пользовался этими "типами")?
А если схему перевести в rng это уже другой стандарт будет? | Admin писал(а): | | Gremlin писал(а): | | А то что все имена "типов" (элементов?) начинаются с большой буквы - это ограничения wiki или какая-то задумка? |
Это wiki-имя. |
Неудачно конечно. И почему не был выбран хотя бы megawiki, в котором (только-что посмотрел на wikipedia.org) допускается в статье отображать ссылки со строчной буквы?
Ну ладно придется пользоваться тем, что есть, но хотя бы в тексте следует записывать имена элементов в правильном регистре.
Я правильно понял, что этот проект несет своей целью не разъяснение использования тэгов (как можно было предположить из названия) а написание комментариев для имеющейся схемы?
Может мне стоит начать отдельную страничку на которой затеять именно описание тэгов? (И назвать ее "Understanding the Schema" чтоб сбить с толку террористов ... попробую придумать более подходящее название). |
|
| Вернуться к началу |
|
|
Admin
Администратор информационного портала FB
Зарегистрирован: 11.06.2004
Сообщения: 1610
Откуда: Воронеж
|
| Добавлено: Вт Ноя 29, 2005 10:32 Заголовок сообщения: |
|
|
| Gremlin писал(а): | Ну нет там таких тэгов!
Есть правда, то что в DTD называется ENTITY c похожими именами (например shareInstructionType ...) но это во первых не то что ты описал (приписка Type помимо просто различия в названии позволяет легче понять что это не элемент), а во вторых тэгами не является и в xml'е появиться не может.
ИМХО информация об этих сущностях нужна только программисту, а правильной программист (неправильный же программист должен давать неправильный мед Smile ) лучше поймет схему, чем то описание которое получается. |
Так. Подробно принцип описания. Каждый элемент имеет свой тип. Разные элементы могут иметь один тип, например, <subtitle> и <p> имеют один и тот же тип pType. Схема описывается от корневого элемента по нисходящей. Чтобы не описывать несколько раз одно и то же, на некотором этапе отдельно описывается тип, который в свою очередь может состоять из элементов. Это разумно. Именно по этому пути я и пошел. Дело в том, что для каждого элемента важно не только то, из чего он состоит, но и то место, где он может встречаться и при каких условиях. В данном случае, описывается и то, и другое.
Добавлено спустя 46 минут 25 секунд:
Кстати, к этому описанию можно наложить отдельно список элементов и даже атрибутов со ссылкой на те места, где они описаны. Будет и полноценное описание и справочник по элементам. |
|
| Вернуться к началу |
|
|
Gremlin
Зрелый участник форума
Зарегистрирован: 14.02.2005
Сообщения: 155
|
| Добавлено: Вт Ноя 29, 2005 14:27 Заголовок сообщения: |
|
|
| Admin писал(а): | | Gremlin писал(а): | Ну нет там таких тэгов!
Есть правда, то что в DTD называется ENTITY c похожими именами (например shareInstructionType ...) но это во первых не то что ты описал (приписка Type помимо просто различия в названии позволяет легче понять что это не элемент), а во вторых тэгами не является и в xml'е появиться не может.
ИМХО информация об этих сущностях нужна только программисту, а правильной программист (неправильный же программист должен давать неправильный мед Smile ) лучше поймет схему, чем то описание которое получается. |
Так. Подробно принцип описания. Каждый элемент имеет свой тип. Разные элементы могут иметь один тип, например, <subtitle> и <p> имеют один и тот же тип pType. Схема описывается от корневого элемента по нисходящей. Чтобы не описывать несколько раз одно и то же, на некотором этапе отдельно описывается тип, который в свою очередь может состоять из элементов. Это разумно. Именно по этому пути я и пошел. Дело в том, что для каждого элемента важно не только то, из чего он состоит, но и то место, где он может встречаться и при каких условиях. В данном случае, описывается и то, и другое. |
Запутано, для меня схема понятнее (там хоть типы элементами не называются, а здесь все вперемежку). Хотя бегать по ней от элемента и вверх по типам, чтобы понять какие подэлементы и аттрибуты допускаются утомляет (но здесь не легче).
Как читать схему мне понятно, а то что здесь затруднительно.
В общем, не лежит у меня душа к такой структуре (да и недоосознал я ее - почти схема, но куча мелких отличий).
Пока начну так как мне представляется более разумным на TagsDescription. А там посмотрим (опять же народ послушаем) куда объединять и как менять.
| Admin писал(а): | | Кстати, к этому описанию можно наложить отдельно список элементов и даже атрибутов со ссылкой на те места, где они описаны. Будет и полноценное описание и справочник по элементам. |
Может то, что получится у меня и подойдет под часть из этого. |
|
| Вернуться к началу |
|
|
Admin
Администратор информационного портала FB
Зарегистрирован: 11.06.2004
Сообщения: 1610
Откуда: Воронеж
|
| Добавлено: Вт Ноя 29, 2005 14:38 Заголовок сообщения: |
|
|
| Gremlin писал(а): | | Пока начну так как мне представляется более разумным на TagsDescription. А там посмотрим (опять же народ послушаем) куда объединять и как менять. |
Делай как считаешь нужным, в любом случае, хоть что-то будет делаться, ибо мне одному не управиться. Там будет видно. |
|
| Вернуться к началу |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
Powered by phpBB © 2001, 2005 phpBB Group
|
POCKET 
WIKI 
FAQ 
Поиск 
Пользователи 
Группы 
Регистрация 
Профиль 
Войти и проверить личные сообщения 
Вход
