Оцените, пожалуйста, формат разметки

[arseniiv]

Я придумал его на основе простого html-подобного языка, который себе для программ делал для хранения данных (INI неудобный, XML тяжёлый, другое не нравилось) и на основе вида $\TeX$, может, реализую себе. Прошу комментариев очень. Если он будет интересен, может сделаю модуль для Delphi так, чтобы можно было выложить на люди. И вообще интересно, что можно сказать.

Описываю: данные в формате ut внутренне представляются подобно LISP-выражениям (в Mathematica тоже такая модель), т.е. файл содержит одно выражение структуры

Заголовок(Выраж1 ... ВыражN)

Как "реализуются" данные: на уровне документа можно перемежать куски текста с "тэгами" (уж это уже совсем не похоже на тэги) следующих видов (справа то, что они представляют):

/hr.                    (hr)
/hr[]                   (hr)
/hr[width=78%]          (hr (width 0.78))
//                      "/"

Парсер "знает", что p - парный тэг (для b указано). В закрывающем может быть опущено название:
/p[align=none id=p1]    (p (align "none") (id "p1")
  /b:Тэкст/.123           (!t (b (!t "Тэкст")) "123")
/p.                     )

Любой текст, не являющийся аттрибутами тэгов (т.е. свободный) помещается в структуру с именем !t. Вообще, с ! планируются начинаться все "системные" конструкции, которые должны будут поддерживаться любым (для начала самым первым) парсером:

/![ комментарий ]
/!paired[p pairedtag ul]     Перечисление парных тегов, если они не указаны в программе (например, документозависимых)

/ и . сами не входят в "описание" структуры (когда используются параметры в скобках [], точка не используется), поэтому вложенные данные надо описывать так:

/display[
  caption="!!!"
  colors[text=#000 header=#02d]
  swapPanels
]

а не так:

/display[
  caption="!!!"
  /colors[text=#000 header=#02d]
  /swapPanels.
]

Вообще же, a=b просто синоним a[b], когда b — простое выражение. Оно может быть строкой (причём если в ней нет символов [, ], =, " и пробела, она может писаться без кавычек). Ещё оно может быть числом, дробным или целым в таких форматах:

23       десятичное
x23      шестнадцатеричное
#01fAcc  = x01fAcc, для цвета
#0fe     = x00ffee, тоже (взято из CSS)
28%      0,28
и стандартный дробный формат

Мне кажется, ничего так получилось (останется "только" написать код поддержки ). Чуть лучше, чем ini. А так как формат должен будет поддерживать Unicode (для начала хотя бы в форме UTF-8, потом можно и UCS-2), отпадает необходимость во всех этих ², хотя их тоже можно реализовать: /sup2.. Специально для XML у меня есть конструкция /. без указания имени закрываемого тэга. (А если большой текст не планируется, и она не нужна. Например, в файле настроек.)

Вот кусок какого-нибудь воображаемого файла:

/!doctype[ut version=1.0 utf-8]
/!aliases[c=catalogue]
/c[date="20.01.2010" path="c:\scr034\"]
  /curDate. /hr[width=90% c=#0A4] 345 /i:678/. 910
/c.

и его внутреннее представление:

(!t
  (!doctype "ut" (version 1,0) "utf-8")
  (!aliases (c "catalogue"))
  (c (date "20.01.2010") (path "c:\scr034\") (!t
    (curDate) (hr (width 0,9) (c x00AA44)
    "345" (i (!t "678")) "910"
  ))
)

[slilo]

http://gigamonkeys.com/book/practical-a ... reter.html
Не надо переизобретать велосипед

Пардон, невнимательно прочитал ваше сообщение.

[allchemist]

то, что вы предлагаете - тот еще велосипед.
раз оно преобразуется во внутреннее sxml-представление, значит не может выйти за рамки его возможностей. если вам не нравится непосредственно xml (и html), то попробуйте сам sxml. lisp-синтаксис предельно прост и кодить в sxml очень просто, проще некуда. а перегнать потом в обычный xml не проблема.

но если хотит - попробуйте, ведь если велосипеды строят, значит это кому-нибудь нужно.

-- Ср янв 20, 2010 20:37:54 --

Цитата:

http://gigamonkeys.com/book/practical-a ... reter.html

книгу почитать очень рекомендую. она, кстати, есть в русском переводе на http://lisper.ru/pcl/, в вики- и pdf-форматах. по поводу создания html в lisp-стиле попробуйте спросить на том же lisper.ru - помогут с радостью

[arseniiv]

Да не, зачем копировать в/из XML, когда можно обойтись без него?
SXML мне не понравился (сейчас почитал). Многострочные тексты в нём будет неудобно представлять (т.к. все они оформляются кавычками; придётся использовать что-то вроде \n там), а ещё в нём тэговые параметры в специальное выражение помещаются. (У меня, наоборот, текст в специальное выражение помещается. Тут уж да, ни то, ни это не хорошо. (Но в моих планах именно параметры использовать больше, а тексты только когда никак.)) Ходя идея та же. И ещё именно скобочное написание неудобно, т.к. легко запутаться.
Главы книги пооткрывал, сейчас почитаю, как лиспом делать html, тоже полезно.
То, что это велосипед, понимаю. В той же википедии нашёл их довольно много разных (лёгких), но они все какие-то недетерминированные.

[allchemist]

Цитата:

И ещё именно скобочное написание неудобно

мне со своей колокольни видится, что скобочная нотация самая унифицированная, простая и эффективная. может быть, она и непривычная, но после некоторой практики читается на ура.

[arseniiv]

!t[
  !doctype["ut" version[1,0] "utf-8"]
  !aliases[[c "catalogue"]]
  c[date["20.01.2010"] path["c:\scr034\"]
    !t[
      curDate[] hr[width[90%] c[#0A4]
      "345" i[!t["678"]] "910"
    ]
  ]
]

Во мне никак не установится равновесие. С другой стороны, скобки мне всё-таки нравятся. Давайте тогда придумаем естественный способ ввести текст в скобки так, чтобы ему было достаточно места там. Как-нибудь без кавычек.

[Maslov]

А чем Вас JSON не устраивает. Под него и парсеры есть для большинства языков.
Вот тут ещё можно почитать: http://www.json.org/

[arseniiv]

Я нечто подобное ему сделал и не понравилось. Громоздко.

[arseniiv]

В общем, что будет потом: списки-структуры оформляются скобками (), всё остальное нормально, но кроме просто "строк", можно использовать $[
многострочные
стро литералы
]. Вот так. (В таких строках возможны любые символы, кроме ] в начальной позиции. Тогда его надо продублировать]]). Ну как? Вот такое получше будет! Чем SXML даже, нет?

[Circiter]

2arseniiv
Сложно мне прокомментировать вашу задумку. Честно говоря не очень понял сути... Но к велосипедам я отношусь хорошо, особенно когда вопросы лицензирования при использовании внешних библиотек поджимают.

Пару лет назад у меня проскальзывала весьма мутная идея "императивной семантической разметки", тоже на основе lisp (+xml), тоже пытался приспособить для конфигурационных файлов. Отталкивался от такой идеи. Представьте, что "документ" представлен lisp-подобной "программой", например такой:

Используется синтаксис lisp

(document
    (header
        (title "Document title")
        (creation_date
            (date
                (day_of_month 30)
                (month July)
                (year 2000)
            )
        )
        (author "Name")
    )
    (content
        ...
    )
)
 
Парсинг занял 0.006 сек. Использовалась библиотека GeSHi 1.0.8.4

То есть, применялась разметка в xml-стиле, но со скобочным синтаксисом. Преимущество могло предположительно заключаться в большей гибкости при интерпретации данных. Действительно, в данном случае аналоги тэгов являются по-сути функциями, применяемыми к своим аргументам-данным. Эти функции могут (пере)определяться в самом документе, предоставляться читающей программой или браться из другого документа.

Например, можно создать набор функций-тэгов, в котором каждая функция просто печатает свои аргументы. Теперь, если "выполнить" документ в пространтсве этих функций, то он напечатает себя. Однако при печати могут происходить и некоторые преобразования. Таким образом, документ может в контексте одного набора функций напечатать себя как простой текст, в контексте другого -- как форматированный $\LaTeX$-исходник, в контексте третьего -- вообще, допустим, перевести себя с русского на французский.

Позже я модифицировал эту концепцию, задействовав lisp'овские lambda-функции, благодаря которым каждый такой документ стал функцией, "применяемой" к набору функций-тэгов. При таком "применении" тэги в "применяемом" документе связывались с конкретными функциями, а потом выполнялись. Документы стали сложнее, но красивше...

А cпустя ещё некоторое время я узнал о всех возможностях XSL, и, понятное дело, первоначальная идея lisp-разметки постепенно забылась как кошмарный сон.

Хотя, возможно, когда-нибудь к ней вернусь. К примеру, если некая программка имеет поддержку скриптов и кроме-того предоставляет веб-интерфейс, то почему-бы не подвести эти возможности под "общий знаменатель"? Почему-бы не выбрать в качестве языка скриптов lisp, а в качестве движка шаблонов для веб-интерфейса не использовать описываемую задумку? Сэкономил бы на XSL-процессоре, самопальную реализацию которого писать нет ни малейшего желания.

[allchemist]

Цитата:

А cпустя ещё некоторое время я узнал о всех возможностях XSL, и, понятное дело, первоначальная идея lisp-разметки постепенно забылась как кошмарный сон

хм, а что это за скрытые размерности возможности такие?
всегда считал, что xml и sxml (то, что вы называете lisp-записью) полностью идентичны.

[Circiter]

2allchemist

Цитата:

хм, а что это за скрытые размерности возможности такие?

А я и не говорил ни о каких скрытых возможностях. Просто я не знал до этого вообще о возможностях XSL (в частности XSLT), поэтому городил свое.

Цитата:

sxml (то, что вы называете lisp-записью)

Поправочка, lisp-записью я назвал именно самопальный велосипед; поймите же, не знал я тогда об sxml'е (хотя он уже существовал). Если бы знал, не проводил бы свои эксперименты.

То есть, рассматривайте мой предыдущий пост как пример велосипедизма в условиях незнания популярных технологий (идея была подчерпнута, или, лучше сказать, зародилась под влянием моего любимого редактора emaсs).

Кстати, sxml -- очень даже неплохая идея. Лично мне гораздо проще реализовать самостоятельно поддержку некоторого его подмножества закодив простенькую lisp-машину, которую можно применять в программульке заодно и для других нужд (скрипты).

-- Вс янв 24, 2010 16:10:45 --

Цитата:

всегда считал, что xml и sxml (то, что вы называете lisp-записью) полностью идентичны.

Несовсем. Документы sxml хоть и имеют древовидную структуру, но обычно представляются односвязным списком, вследствие чего при обходе дерева возникают некоторые проблемы с доступом к узлу-предку и другим узлам, выходящим из него. Хотя, конечному пользователю, как правило, эти детали реализации могут быть "по барабану".