Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.09.06 11:27
Оценка: 161 (21) +15 -2 :)))
Мнение Алана Голуба: Just Say No to XML

XML, вероятно, худший из когда-либо появлявшихся языков программирования. Я не говорю об XML как о языке описания данных, которым он был в своем первоначальном дизайне. Я говорю о извращении XML для программирования приложений. Неуместно использовать XML как скриптовый язык (например, ANT), как язык описания тестов (например, TestNG), как язык описания объектно-реляционного отображения (например, Hibernate, JDO), как язык описания потоков управления (например, JSF) и т.д. Подобные XML "программы" нечитаемы, несопровождаемы, на порядок больше в размерах и безрассудно не эффективны в время исполнения.

Так почему же XML используется таким неподходящим образом? Насколько я могу судить, это потому, что многие так называемые программисты просто не знают, как сделать компилятор...

...Знать как сделать компилятор -- это, определенно, один из элементов в списке того, что нужно знать. Компиляторы являются фундаментом того, что мы делаем каждый день как программисты. Знание того, как компилятор работает позволит вам сделать грамотные решения о структуре программы, решения, которые имеют реальное влияние на качестве наших программ. Более того, множество программ занимаются разбором ввода (как от человека, так и от машины) и работают в зависимости от его содержимого. Чтобы сделать это, вам нужно сделать маленький компилятор. Портить XML для этих целей, просто из-за того, что у вас под рукой есть XML парсер, по меньшей мере, неуместно...


После чего он сетует на то, что хороших книг и ресурсов, которые бы способствовали изучению ремесла построения компиляторов не так уж и много.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: Снова XML: Just Say No to XML
От: Пацак Россия  
Дата: 28.09.06 14:43
Оценка: 58 (3) :))) :))) :))) :))) :)
Здравствуйте, eao197, Вы писали:

E>Представляю себе цепочку причинно-следственных связей:

E>
E>Используем XML чтобы не писать транслятор.
E>`-> Получили нечитабельные скрипты, используем XSTL (XML опять же)
E>    чтобы получить читабельность.
E>    `-> Невозможно преобразовать модифицированные читабельные скрипты
E>        обратно в XML.
E>        `-> Пишем транслятор читабельных скриптов чтобы преобразовать
E>            их в XML. Который нечитабельный.
E>            `-> Вспоминаем, что XML использовалься для того, чтобы не
E>                писать транслятор.
E>


Ну кто так оформляет данные?!! Вот как надо:

<?xml version="1.0" encoding="windows-1251"?>

<ns1:problem subject="не хотим писать транслятор">
    <ns1:solution rule="Используем XML">
    <ns1:problem subject="Получили нечитабельные скрипты">
        <ns1:solution rule="Используем XSLT" why="чтобы получить читабельность">
        <ns1:whatIs what="XSLT">
            <ns1:is-a-kind-of child="XSLT" parent="XML"/>
        </ns1:whatIs>
        <ns1:problem subject="Невозможно преобразовать модифицированные читабельные скрипты обратно в XML">
            <ns1:solution rule="Пишем транслятор читабельных скриптов" why="чтобы преобразовать их в XML"> <!-- XML нечитаемый -->
            <ns1:remember what="XML использовался для того, чтобы не писать транслятор">
            </ns1:solution>
        </ns1:problem>
        </ns1:solution>
    </ns1:problem>
    </ns1:solution>
</ns1:problem>


Видишь, насколько удобнее стало? А понятнее? А проще? Вот! А ты говоришь!
Ку...
Re: Снова XML: Just Say No to XML
От: Cyberax Марс  
Дата: 27.09.06 11:37
Оценка: 2 (2) +12
eao197 wrote:
> Мнение Алана Голуба: Just Say No to XML
> <http://www.sdtimes.com/fullcolumn/column-20060901-05.html&gt;
Досталлллло!

XML — это язык конфигурирования и программирования данных. Я НЕ хочу
разбираться с кучей яызков для описания ДАННЫХ — я хочу один формат,
который я могу разбирать автоматическими средствами и не писать на
каждый чих по парсеру и компилятору. Я хочу иметь автокомплит, подсветку
ошибок на лету, поддерживаемость всеми современными IDE.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[5]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.09.06 12:21
Оценка: :))) :))) :))) :))) :))
Здравствуйте, Andrei N.Sobchuck, Вы писали:

kan>>>Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу.

E>>А обратно?

ANS>Напиши транслятор


Представляю себе цепочку причинно-следственных связей:
Используем XML чтобы не писать транслятор.
`-> Получили нечитабельные скрипты, используем XSTL (XML опять же)
    чтобы получить читабельность.
    `-> Невозможно преобразовать модифицированные читабельные скрипты
        обратно в XML.
        `-> Пишем транслятор читабельных скриптов чтобы преобразовать
            их в XML. Который нечитабельный.
            `-> Вспоминаем, что XML использовалься для того, чтобы не
                писать транслятор.



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Насчет синтаксиса
От: Quintanar Россия  
Дата: 28.09.06 09:30
Оценка: 17 (2) +10
Здравствуйте, kan, Вы писали:

kan>Mamut wrote:


>> Смотрим, например, вот в небольшой список XML Languages

>> <http://xml.coverpages.org/xmlApplications.html&gt;. Их там — 600 штук. И
>> каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого
kan>Бред. Синтаксис всех XML-based языков одинаков и стандартизован.

Это вы бред говорите. Для компьютера он может и стандартизирован, а человеку по любому все время приходится учить новый язык. XML — это лишь оболочка, как другая кодировка, не более того. Для того, чтобы использовать VoiceXML, например, придется выучить новый язык и то, что он оформлен в виде XML НИЧЕМ абсолютно тебе в этом предприятии не поможет. XML помогает только ленивым программистам, которым в падлу написать компилятор/интрепретатор для более удобной для человека формы.
А вот писать потом программы на XML языке — это ад. Я, как однажды имевший несчастье это делать, готов плюнуть в лицо любому, кто станет проталкивать убожество типа VoiceXML и прочий креатив больных на голову разработчиков.
Re: Снова XML: Just Say No to XML
От: dshe  
Дата: 27.09.06 13:36
Оценка: :))) :))) :))) :)))
Здравствуйте, eao197, Вы писали:

E>Мнение Алана Голуба: Just Say No to XML


Вспомнилось. Надеюсь в тему: http://www.charlespetzold.com/etc/CSAML.html

C# Application Markup Language (CSAML): An Evolutionary Leap

...
In fact, CSAML is able to rid itself of every symbol used in old-syntax C#. For example, consider the following old-syntax C# assignment statement:

A = 5 * (B + 27 * C);

This statement translates without much fuss into the following chunk of CSAML:
<ExpressionStatement>
    <Assignment LValue="A">
        <Assignment.Expression>
            <MultiplicationExpression>
                <Multiplication.Multiplier>
                    <Literal Type="{x:Type Int32}"
                             Value="5" />
                </Multiplication.Multiplier>
                <Multiplication.Multiplicand>
                    <AdditionExpression Augend="B">
                        <AdditionExpression.Addend>
                            <Multiplication.Multiplier>
                                <Literal Type="{x:Type Int32}"
                                         Value="27" />
                            </Multiplication.Multiplier>
                            <MultiplicationExpression Multiplicand="C"/>
                      </AdditionExpression.Addend>
                   </AdditionExpression>
              </Multiplication.Multiplicand>
            </MultiplicationExpression>
        </Assignment.Expression>
    </Assignment>
</ExpressionStatement>

The advantages of this notation are obvious. Because no parentheses are required (or allowed), the programmer has composed the CSAML by carefully considering the problem. Errors are much less likely. The compiler can become more efficient as well because the statement has, in effect, been pre-parsed by the programmer.
...


ЗЫ Не воспринимайте слишком серьезно.
--
Дмитро
Re[4]: Насчет синтаксиса
От: Трурль  
Дата: 29.09.06 05:02
Оценка: :))) :))) :))) :))
Здравствуйте, VladD2, Вы писали:

VD>ЗЫ


VD>Не надо бравировать словами панацея и серебрянная пуля. Что за манера наклеивать ярлыки?


Ну, XML явно не серебрянная пуля. Это, как минимум золотая гиря.
Re: my 5c
От: Зверёк Харьковский  
Дата: 28.09.06 08:30
Оценка: 100 (7) +1
Мне всегда казалось, что основная проблема XML — плохое отображение на привычные структуры данных.
Т.е. "в жизни", грубо говоря, "встречаются" основные структуры данных — скаляр, вектор, словарь (и вроде как бы и все, учитывая их вложенность — элемент вектора может быть скаляром-вектором-словарем и т.п.)
А в XML — "именованный данные с аттрибутами". Отсюда вечные проблемы отображения:
[1,2,3] => <array><value>1</value><value>2</value><value>3</value></array>
или
[1,2,3] => <array values='1,2,3'>
или
[1,2,3] => <array><item value='1'><item value='2'><item value='3'></array>

то же самое и со словарями.
Т.е. для сериализации данных удобнее какая-нито хрень типа помянутого JSON или более продвинутого YAML, которые базируются именно на "естественных" для программера структурах данных.

С другой стороны, вокруг XML накоплен интересный опыт: XPath, XSD, XSLT и т.п. — это все крайне полезные идеомы (паттерны, если хотите), которые могут (и должны) быть применены к другим, более удобным языкам описания данных.

Имху, так.
FAQ — це мiй ай-кью!
Re[4]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 27.09.06 12:00
Оценка: +7
ArtDenis wrote:

>> Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу.

> Это не выход
А что выход? Изучать ещё один синтаксис? Если бы каждый писал свой компилятор на каждый случай, ты бы запоминал, что в
hibernate-маппингах в конце строки надо ставить ";", в ant надо ставить ".", в TestNG не надо ничего ставить, а вот в
jsf надо ";", но отделить пробелом. И в итоге ты бы также "Нае...лся с ant-ом по самое нехочу", т.к. там всё не так, как
в привычном тебе hibernate.
Плюс поиметь все радости проблем с кодировками.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.09.06 13:15
Оценка: 24 (2) +4
Здравствуйте, Mamut, Вы писали:

M>Вот вопрос. Чем их ASN.1 не устроил?


a) ASN.1 совершенно не приспособлен к чтению людьми. Бинарная передача данных -- это задача ASN.1, но вот ручками там поправить что-нибудь, или хотя бы без какого-либо инструмента проверить значения в потоке данных, тут текстовые форматы удобнее. Не случайно Эрик Реймонд в своей книги "Искусство программирования под Unix" заостряет внимание на том, что текстовые форматы часто удобнее бинарных.

b) ASN.1, вообще-то говоря, не столь расширяем, как это может показаться. AFAIK, при проектировании протокола нужно специальным образом помечать места, в которых возможны дальнейшие расширения протокола. Что не просто. В XML-е (да и другом формате текстовой разметки), если не фиксировать жестко DTD, то можно при необходимости расширить любой тег (например, добавить в него атрибутов или дочерних элементов).

c) ASN.1 сразу ставит тебя перед высоким порогом вхождения. Во-первых, язык спецификаций. Во-вторых, ASN.1 компиляторы (писать вручную можно разве что ASN.1 BER, да и то не просто, а уж ASN.1 PER...). Их нужно искать, их нужно изучать, за хорошие нужно платить и не мало. В случае же с XML можно вооружиться инструментом, максимально подходящим для твоих нужд. Например, один раз мне потребовалось получить по HTTPS с сервера коротенькую XML-ку из которой мне нужно было значение только одного элемента. Воспользовался просто regex-ом. Генерить, опять же, XML вручную очень просто (если не сложный). Хотя низкий порог входжения в XML, как показал Голуб, как раз затем и приводит к необдуманному применению XML.

d) Насколько мне известно, ASN.1 не специфицирует отображение своей спецификации в язык программирования. Из-за этого каждый ASN.1 предоставляет собственный маппинг спецификации в классы/функции целевого языка. А из-за этого пользователи ASN.1 привязываются к производителю ASN.1 компилятора.

Так что, имхо, далеко не всегда ASN.1 является более выгодной альтернативой, чем XML. И наоборот. Хотя в некоторых случаях действительно задаешься вопросом: какого черта XML использован? Например, есть такая, имхо, маразматическая штука, как подписанный XML. Вот вместо него ASN.1 вполне мог применяться. Тем более, что области, в которых подписанный XML применяется (электронная коммерция), отнюдь не дешевые. И при разработке в них прикладных решений затраты на ASN.1 компиляторы вовсе не такие чувствительные.

Плохо то, что XML раскручен, а ASN.1 нет. Я, например, про него совершено случайно узнал. Поэтому при выборе решений многие разработчики такой альтернативы XML, как ASN.1 или, скажем, скриптовые языки, даже не видят. Из-за элементарного незнания.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Насчет синтаксиса
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.06 16:57
Оценка: 20 (1) +5
Здравствуйте, kan, Вы писали:

kan>Это семантика, не путаем, плз. Редактор обученный xsd-шкой поможет в данном случае.


Это ты путашь. Это как раз синтаксис. Семантика это интерпретация данных.

Ты же говоришь о базовм синтаксисе. Только языки базирующиеся на ХМЛ добавляют к ХМЛ свои ограничения и синтаксические правила.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Gateway
От: kan Великобритания  
Дата: 29.09.06 12:50
Оценка: 44 (2) +1 :)
eao197 wrote:

> Судя по их истории <http://www.authorize.net/company/aboutus/&gt;:

> * November 1996 — Authorize.Net is founded in Provo, UT.
> * March 1997 — Authorize.Net launches the eCheck.Net service.
> * September 1997 — Authorize.Net partners with its first reseller, U.S.
> Merchant Systems, initiating its world class reseller channel.
> * December 1998 — Authorize.Net surpasses 10,000 active merchants.
> основные проектные решения они принимали, когда XML еще не был в таком
> фаворе, как сейчас.
Не то что фаворе, а его вообще не было! Первая релизная версия <br />
спецификации
от 1998-года, когда Authorize.Net уже развернулись на всю катушку.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Ну дык...
От: c-smile Канада http://terrainformatica.com
Дата: 28.09.06 06:53
Оценка: 40 (4)
Здравствуйте, eao197, Вы писали:

... Ну дык json то рулез я всегда говорил...

А xml ... самый лучший xml это html, x который. Там ему самынное и место...

как язык описания структур данных богаче чем xml ибо есть в нем коллекции array и map.
Також возможность сказать [ 1, 2, 3 ] вместо
<array>
  <value type="integer">1</value>
  <value type="integer">2</value>
  <value type="integer">3</value>
</array>


явно экономит много движений руками и глазами.

Если же надо еще прцудуры-функции в поток данных вставлять то естествнным образом переход
на JS никого не должен остановить.

Наличие штук типа JsonT (Transforming Json — аналог XSLT) http://goessner.net/articles/jsont/ тоже
радует.

Имплементация json parser и "json DOM" проще в разы чем полный XML парсер + DOM.
Вот рекомендую C пакет http://oss.metaparadigm.com/json-c/


---
А еще вон народ xaml'ом развлекается... делать им нечего...
Re: Снова XML: Just Say No to XML
От: CrystaX Россия https://crystax.me/
Дата: 27.09.06 16:13
Оценка: 18 (2) +1
Здравствуйте, eao197, Вы писали:

Вот хороший пример того, как делать не надо (VoiceXML) :
<?xml version="1.0" encoding="UTF-8"?>

<vxml version = 2.1 >

<meta name="maintainer" content="YOUR_EMAIL@SOMEWHERE.COM"/>

<form id="CallTransfer">
  <block>
    <prompt>Preparing to dial the number</prompt>
  </block>

<!--
      Make sure you have outbound dialing priveleges, 
      else any call attempts will result in a 'busy' event.
      Contact support@voxeo.com for details
-->

  <transfer name="MyCall" dest="tel:+1234567890" 
          bridge="true" connecttimeout="20s" maxtime="60s">

    <filled>
      <if cond="MyCall == 'busy'">
        <prompt>
          Sorry, our lines are busy. Please try again later.
        </prompt>
        <exit/>

      <elseif cond="MyCall == 'noanswer'"/>
        <prompt>
          Hey, nobody is answering the phone. 
        </prompt>

      <elseif cond="MyCall == 'far_end_disconnect'"/>
        <prompt> 
          Your party must have hung up. how rude.
        </prompt>

      <elseif cond="MyCall == 'near_end_disconnect'"/>
        <submit next ="MyCoolCleanupPage.jsp"/>
    
      <elseif cond="MyCall == 'maxtime.disconnect'"/>
        <prompt> 
          Your call ran over the maxtime of sixty seconds, 
            and your called party has been disconnected.
        </prompt>

      </if>
    </filled>
  </transfer>
</form>
</vxml>


Самое интересное, что даже в этой схеме им не удалось избавиться от скриптового языка — в ветках elseif используется атрибут cond, содержимое которого — JavaScript. Здесь это еще не так заметно, но я видел и более "ветвистые" условия, записанные на JS. Т.е. в результате получили ни то ни се — из XML взяли исключительно недостатки, выбросив достоинства. Результат — налицо.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Re[7]: Снова XML: Just Say No to XML
От: ZevS Россия  
Дата: 29.09.06 09:58
Оценка: 1 (1) +2
Здравствуйте, Turtle.BAZON.Group, Вы писали:

TBG>Здравствуйте, ZevS, Вы писали:


ZS>>Я как раз про то, что удобно должно быть конечному пользователю продукта. Кроме того надеюсь ни кто не будет спорить что XML имеет множество приемуществ.


TBG>Хотелось бы послушать про преимущества ХыМыЛа для конечного пользователя продукта.


Пожалуйста:

Можно продолжить.

К реальным минусам можно отнести:
Re: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 27.09.06 11:37
Оценка: +3
eao197 wrote:

> После чего он сетует на то, что хороших книг и ресурсов, которые бы

> способствовали изучению ремесла построения компиляторов не так уж и много.
xml к это не замена компилятора, а всего лишь лексического и синтаксического анализатора. Компилятор помимо этих двух
должен ещё иметь сематнический анализатор и кодогенератор (который не всегда нужен-то).
Так что рассуждения основаны на ложных посылках. В общем непонятно каким боком компилятор "заменяет" xml или в лушчем
случае похоже на рассуждения "вылить воду из чайника, сведя задачу к предыдущей".
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: Снова XML: Just Say No to XML
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 27.09.06 12:09
Оценка: -1 :))
Здравствуйте, eao197, Вы писали:

kan>>Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу.

E>А обратно?

Напиши транслятор
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[9]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.09.06 14:32
Оценка: +3
Здравствуйте, kan, Вы писали:

>> Прошу перечитать первый абзац из высказываний Голуба (хоть на русском в

>> моем переводе, хоть на английском в оригинале) -- проблемы с XML
>> начинаются тогда, когда на нем начинают писать программы вместо
>> декларативных описаний. Может быть кто-то и может воспринимать что-то
>> подобное за нормальный if:
kan>Ну так рассуждать, в когда вообще декларативное описание будет выгодее?
kan>
kan><html>
kan>  <head>
kan>   <title>Hi!</title>
kan>  </head>
kan>  <body>
kan>   <p>Hello world!</p>
kan>  </body>
kan></html>
kan>


Вполне нормальный вариант. В LaTeX-овой разметке, или в Wiki, или в ReST, конечно, компактнее, но вполне себе хорошо. Это как раз идеальная задача для XML подобной разметки. Для того и создавался.

kan>и что-то вроде

kan>
kan>new html()
kan>  .add(new head()
kan>   .add(new title("Hi!"))
kan>  .add(new body()
kan>   .add(new p("Hello world!")));
kan>

kan>?

А это лучше заменить на:
html {
  head {
    title 'Hi'
  }
  body {
    p {
      'Hello, world!'
    }
  }
}


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 28.09.06 12:16
Оценка: :)))
Andrei N.Sobchuck wrote:

> M>ASN.1 *XER*

> С таким названием, не удивительно, что они в массы не пошли
Есть такая штука XEP (вторая ссылка в русском гугле, не первая ).
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Снова XML: Just Say No to XML
От: c-smile Канада http://terrainformatica.com
Дата: 29.09.06 06:37
Оценка: +1 :))
Здравствуйте, eao197, Вы писали:

E>Здравствуйте, trophim, Вы писали:


T>>Заметьте, кто поставил минус на основной пост... А я что? Так, просто...


E>Видимо, я перевод некачественный сделал


Кстати вот стих придумался:

Перевод без перевед — бисер на ветер.
Re[7]: Снова XML: Just Say No to XML
От: GlebZ Россия  
Дата: 29.09.06 11:03
Оценка: :)))
Здравствуйте, Mamut, Вы писали:

M>Гипотетический код платежной системы:

payment::clientid=2ni3poicy5b8924v;ptype=VISA;ccno=1234567890123456;vcode=12345;amount=23.5;;

Максимально упрощенный ХМЛ:
<payment clientid="2ni3poicy5b8924v" ptype="VISA" ccno="1234567890123456" vcode="12345" amount="23.5" />

Кстати. Двой код показывает главный плюс XML. RSDN знает xml, и знает как его разукрашивать, а вот твой код — нет. Да здраствует XML
Re[9]: Снова XML: Just Say No to XML
От: GlebZ Россия  
Дата: 29.09.06 11:36
Оценка: +3
Здравствуйте, Mamut, Вы писали:

M> Экономить всегда полезно.

Вообще-то нормальные девелоперы, для того чтобы уменьшить трафик включают gzip, который собственно именно для этого и предназначен. А через LZW алгоритмы, xml скукоживается на порядки.
Gateway
От: Mamut Швеция http://dmitriid.com
Дата: 29.09.06 12:20
Оценка: 27 (2)
GZ>>Сложности возникают только когда начинают делать свои велосипеды из-за нереальной мысли что будет лучше. Как нибудь попробуй прочитать спецификацию XML(даже без остальных технологий). Он только кажется простым. И там учтено много подводных камней.

E>Здесь я с тобой согласен. Но меня вообще интересует, чтоже это за платежная система, которая вместо стандартных (хоть и сложных, и дорогих) решений позволяет использовать собственные key=value.



Нашел-таки Зрительная память — это вещь Ввел в гугле Payment Gateway и начал искать сайт, вид которого я отдаленно помнил

Итак, Authorize.net, а именно Advanced Integration Method (AIM) Implementation Guide (PDF), 490 КБ:

Standard Transaction Submission API for AIM

The Standard Transaction Submission API defines the information that can be submitted to the gateway for real-time transaction processing. The API consists of a set of fields that are required for each transaction, and a set of fields that are optional. Under the API, the gateway accepts a NAME/ VALUE pair. The NAME is the field name and indicates to the gateway what information is being submitted. VALUE contains the content of the field.


Дальше идут таблицы с необходимыми названиями полей.

Ну и так далее вся секция integration такая

И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву.
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[7]: Снова XML: Just Say No to XML
От: Cyberax Марс  
Дата: 27.09.06 13:27
Оценка: 6 (1) :)
Здравствуйте, kan, Вы писали:

kan>Cyberax wrote:

>>> вот в jsf надо ";", но отделить пробелом.
>> Это не jsf, а jam. И я это пофиксил
kan>ты лучше xml прикрути туда
Уже поздно. Я уже Питоновый backend туда прикручиваю.
Sapienti sat!
Re[7]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.09.06 13:29
Оценка: 4 (1) +1
Здравствуйте, kan, Вы писали:

>> Представляю себе цепочку причинно-следственных связей:

kan>Это нужно делать только если ты эстет и проблемы со зрением "из-за обилия тегов и неудобной для восприятия глазом
kan>структуры разметки". Лично мне при нормальном xml-редакторе (да если ещё и специально обученном данной xsd-шкой)
kan>воспринимать структуру никто не мешает.

Прошу перечитать первый абзац из высказываний Голуба (хоть на русском в моем переводе, хоть на английском в оригинале) -- проблемы с XML начинаются тогда, когда на нем начинают писать программы вместо декларативных описаний. Может быть кто-то и может воспринимать что-то подобное за нормальный if:
<if>
  <condition>
    <and>
      <equal>
        <what variable="target"/>
        <to contant="win32"/>
      </equal>
      <equal>
        <what variable="compiler"/>
        <to constant="vc++"/>
      </equal>
    </and>
  </condition>
  <then>
    <action>
      ...bla-bla-bla...
    </action>
  </than>
</if>

но это если не сравнивать с:
if target == "win32" && compiler == "vc++"
  ...bla-bla-bla
end

или с:
(if (and (= target 'win32') (= compiler 'vc++'))
  (...bla-bla-bla...)
)


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Gateway
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.09.06 12:42
Оценка: 2 (1) +1
Здравствуйте, Mamut, Вы писали:

M>И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву.


Судя по их истории:

* November 1996 — Authorize.Net is founded in Provo, UT.
* March 1997 — Authorize.Net launches the eCheck.Net service.
* September 1997 — Authorize.Net partners with its first reseller, U.S. Merchant Systems, initiating its world class reseller channel.
* December 1998 — Authorize.Net surpasses 10,000 active merchants.

основные проектные решения они принимали, когда XML еще не был в таком фаворе, как сейчас.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.09.06 07:58
Оценка: 1 (1) +1
Здравствуйте, ZevS, Вы писали:

E>>Но ведь он и прав: даже если для задачи будет удобно сделать свой транслятор, мало кто будет сразу знать, за что хвататься.


ZS>Это вопрос квалификации, а не XML.


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

ZS>Настораживает формулировка "если для задачи будет удобно сделать свой транслятор". Что заначит удобнее? Кому удобнее? Программисту Пете — фанату трансляторов и "красивых решений", а дальше хоть трава не расти?


Универсального ответа здесь нет, нужно смотреть на конкретные условия. Если речь идет о создании чего-либо, вроде Interface Definition Language или Data Definition Language, который будет предназначен для работы пользователей (как написанию, так и чтению) без наличия специализированных инструментов, то собственный транслятор может оказаться оправданным. Вот, к примеру, есть DocBook. Не знаю как кому, но я за него так и не взялся, поскольку набирать текст в VIM-е в XML не так уж просто. Нужны специализированные XML редакторы, заточенные под удобное редактирование DocBook-а. Между тем, LaTeX, при тех же, в общем-то, возможностях, совершенно спокойно редактируется как в VIM-е, так в Notepade, так и в FAR-е. Просто потому, что LaTeX-овый синтаксис ориентирован на работу человека с текстом. А Wiki-форматирование пошло еще дальше -- очень простой формат текста, но отлично решает поставленные перед ним задачи.

Вот вам бы, например, было бы удобно писать Wiki-странички в формате XML? И как вы думаете, получили бы Wiki-системы такое распространение, если бы в качестве языка разметки они предлагали пользователю XML?

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

ZS>Очень спорная статья, я бы даже сказл — провокационная.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Снова XML: Just Say No to XML
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 29.09.06 13:43
Оценка: 1 (1) +1
Здравствуйте, kan, Вы писали:

kan> <when test="something and (something_else or (first and second and third))">


Это уже не XML
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[6]: Снова XML: Just Say No to XML
От: Cyberax Марс  
Дата: 27.09.06 13:03
Оценка: +1 -1
FR wrote:
>> >> Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу.
>> > Это не выход
> kan>А что выход? Изучать ещё один синтаксис?
> Зачем новый хватит или S-выражений или например чего-то forth образного.
А с кодировками как быть? А с entity (чтобы не ломать пальцы, набирая
какие-нибудь экзотические символы)?

Вот если все это прикрутить — получится ТОТ ЖЕ САМЫЙ XML, только вид с
профиля.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[3]: Насчет синтаксиса
От: kan Великобритания  
Дата: 28.09.06 10:50
Оценка: +2
Mamut wrote:

> *Абсолютно* то же самое происходит и с ХМЛем


> <!-- version 1-->


> Это уже два абсолютно разных синтаксиса, каждый из которых надо учить. И

Это семантика, не путаем, плз. Редактор обученный xsd-шкой поможет в данном случае.

> помнить их различия, и орать матом на разработчиков, если в новой версии

> они перейдут с одного синтаксиса на другой (а такое тоже бывает).
Если не сделают xsl-ки для конвертирования из старой версии — наорать, да самому наваять за пол часа.

>> > надо писать свой, неповторимый компилятор/интерпретатор/парсер.

> kan>Чем обычные DOM/SAX парсеры не устраивают? А всякие хрени, генерящие
> код объектной модели по xsd и прочие xml-object
> kan>мапперы?
> Потому что DOM/SAX парсеры — это хорошо. Но что делать, если verson 1
> будет заменен на version 2? Тогда мне все равно придется переписывать ту
> часть программы, которая пользуется парсером, и перенастраивать маппер.
> Причем мапперы каждый используют свой формат, который опять же придется
> изучать с нуля. Потому что Castor
> <http://www.castor.org/xml-mapping.html#3.-The-Mapping-File&gt;
> несовместим, например, с JAXB
> <http://java.sun.com/webservices/docs/1.4/tutorial/doc/JAXBUsing3.html#wp150676&gt;
БезXMLные альтернативы в студию. Да чтобы с совсместимостью, какую вы тут требуете.

> kan>А компилятор/интерпретатор, если нужен, придётся писать в любом случае.

> kan>Часть этих 600 языков — языки разметки (FOP, DocBook, XBRL,...), для
> них вообще не нужно писать
> kan>компиляторы/интерпретаторы. Достаточно заюзать готовые либы
> трансляции в html/pdf/rtf/etc.
> А если либ нет?
А если компьютера нет? Свой паять?

> В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего

> бы то ни было. Просто еще один формат данных, да еще не совсем удачный
А он и не панацея. Есть места где он неприменим, но те наезды что звучат здесь — мимо тазика.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Снова XML: Just Say No to XML
От: ZevS Россия  
Дата: 28.09.06 15:06
Оценка: +2
Здравствуйте, eao197, Вы писали:

E>Здравствуйте, ZevS, Вы писали:


ZS>>Весь смысл статьи — "Печально я гляжу на не наше поколенье" и "да молодежь нонче не та, вот в наше время.."


E>Есть такое дело.

E>Но ведь он и прав: даже если для задачи будет удобно сделать свой транслятор, мало кто будет сразу знать, за что хвататься.

Это вопрос квалификации, а не XML. Настораживает формулировка "если для задачи будет удобно сделать свой транслятор". Что заначит удобнее? Кому удобнее? Программисту Пете — фанату трансляторов и "красивых решений", а дальше хоть трава не расти?

Рассуждая в сторону, любую программу можно рассматривать как транслятор/интерпритатор/компилятор. Так что же теперь, для всех задачь придумывать свой язык? Кроме того, давно известно: больше кода — больше ошибок. Так что даже не знаю... Очень спорная статья, я бы даже сказл — провокационная.
Re[2]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.09.06 04:23
Оценка: :))
Здравствуйте, trophim, Вы писали:

T>Заметьте, кто поставил минус на основной пост... А я что? Так, просто...


Видимо, я перевод некачественный сделал


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: Снова XML: Just Say No to XML
От: ZevS Россия  
Дата: 29.09.06 13:14
Оценка: +2
Здравствуйте, Turtle.BAZON.Group, Вы писали:

TBG>Здравствуйте, ZevS, Вы писали:


TBG>>>Хотелось бы послушать про преимущества ХыМыЛа для конечного пользователя продукта.


ZS>>Пожалуйста:

ZS>>
Извините, но это демагогия.


TBG>Даже конфигурационный файл оказывается проще что-то в стиле KEY=VALUE.

TBG>Я не за языки вместо ХМЛ — они тоже проблему не решат. Я за то, чтобы конечный пользователь владел все же мышой или чем-нибудь там и особо не напрягался, так как не любит.

Правда? А если конфигурация — это не пара значений, а сложная иерархическая структура?
Re[5]: Снова XML: Just Say No to XML
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 23.11.06 21:58
Оценка: +2
Здравствуйте, eao197, Вы писали:

E>Вот вам бы, например, было бы удобно писать Wiki-странички в формате XML? И как вы думаете, получили бы Wiki-системы такое распространение, если бы в качестве языка разметки они предлагали пользователю XML?


Мне лично удобнее был бы XML. Просто по той причине, что разметочные маркеры предлагаемые многими wiki конфликтуют с тем, как мне нужно что-то записать, причём регулярно.
Например, где-то для подчёркивания пишется __x__. А если мне нужно описать например питоновый __init__? Или в MediaWiki пробел в начале строки создаёт (грубо говоря) таблицу. А если мне надо сделать отступ?
У XML регулярный конфликт только по трём символам "<>&" (ну, может ещё &quot; — но это уже в полях, которые тут не интересуют). Элементарно сделать автоматическую подстановку при импорте текста. А с wiki — у каждой свои правила, все заточены на "интуитивные" подходы типа "вот тут оберните звёздочками" как будто никакой информации кроме плоского английского текста нет. И если делать импорт текста то приходится его чуть ли не целиком заворачивать, например, в две двойные кавычки (для WackoWiki). А если в тексте будут две двойные кавычки (а они будут, например, в сишной константе "строка длины 0")? Разворачивать перед ними, как-то их эскейпить, заворачивать обратно? Последний раз я такие извраты видел, когда передавались строки в команду для /bin/sh...

Видеть вместо всего этого бардака простые и понятные <u>...</u> в разы понятнее и проще. Подход один, единообразен, достаточно удобен как человеку, так и машине. И что важно — общие правила просты и немногочисленны. Думаю, это и есть те причины, по которым вообще продвигается XML: вместо туевой хучи локальных язычков, сляпанных обычно кое-как на коленке и постоянно страдающих от недоработки, он дал один общий метод и инфраструктуру (те же валидаторы и преобразователи). Фактически я видел до того (если не считать SGML) только один более-менее нормальный язык разметки — roff. Но у того всё-таки ориентация на форматирование для печати, а не на представление "вообще".

Вот уже на языки программирования я бы такой подход не распространял — там обычно немного другая... мнэээ... мотивация принятых решений.
The God is real, unless declared integer.
Насчет синтаксиса
От: Mamut Швеция http://dmitriid.com
Дата: 28.09.06 06:54
Оценка: 20 (1)
>>> Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу.
>> Это не выход
kan>А что выход? Изучать ещё один синтаксис? Если бы каждый писал свой компилятор на каждый случай, ты бы запоминал, что в
kan>hibernate-маппингах в конце строки надо ставить ";", в ant надо ставить ".", в TestNG не надо ничего ставить, а вот в
kan>jsf надо ";", но отделить пробелом. И в итоге ты бы также "Нае...лся с ant-ом по самое нехочу", т.к. там всё не так, как
kan>в привычном тебе hibernate.
kan>Плюс поиметь все радости проблем с кодировками.

Как говорится, ню-ню

Смотрим, например, вот в небольшой список XML Languages. Их там — 600 штук. И каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого надо писать свой, неповторимый компилятор/интерпретатор/парсер.

То, что ХМЛ — это одинаковая для всех панацея, — миф, уже неоднократно развенчанный.

См. также ответ к Re[3]: Снова XML: Just Say No to XML
Автор: eao197
Дата: 27.09.06
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[4]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 28.09.06 06:54
Оценка: 17 (1)
M>>Вот вопрос. Чем их ASN.1 не устроил?

E>a) ASN.1 совершенно не приспособлен к чтению людьми. Бинарная передача данных -- это задача ASN.1, но вот ручками там поправить что-нибудь, или хотя бы без какого-либо инструмента проверить значения в потоке данных, тут текстовые форматы удобнее. Не случайно Эрик Реймонд в своей книги "Искусство программирования под Unix" заостряет внимание на том, что текстовые форматы часто удобнее бинарных.


Тут фишка еще в том, что, ИМХО, ASN.1 можно было бы легко передавать и напрямую в тексте, то есть, не компилируя его в бинарный формат. И наоборот, ХМЛ тоже можно было бы копилировать, если бы кто-нить задался бы таким вопросом

Ну, например:
в нотации ASN.1 (до компиляции)
myQuestion FooQuestion ::= { 
    trackingNumber     5, 
    question           "Anybody there?" 
}

ASN.1 XER
<FooQuestion>
    <trackingNumber>5</trackingNumber>
    <question>Anybody there?</question>
</FooQuestion>


А теперь, внимание!
ASN.1 Defintion для этого типа данных:
FooProtocol DEFINITIONS ::= BEGIN

    FooQuestion ::= SEQUENCE {
        trackingNumber INTEGER,
        question       VisibleString
    }

    FooAnswer ::= SEQUENCE {
        questionNumber INTEGER,
        answer         BOOLEAN
    }
END


XML XSD Schema:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
    <xs:element name="FooQuestion">
        <xs:complexType>
            <xs:sequence>
                <xs:element ref="trackingNumber"/>
                <xs:element ref="question"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
    <xs:element name="question" type="xs:string"/>
    <xs:element name="trackingNumber" type="xs:byte"/>
</xs:schema>


Неее... ХМЛ — это зло

E>b) ASN.1, вообще-то говоря, не столь расширяем, как это может показаться. AFAIK, при проектировании протокола нужно специальным образом помечать места, в которых возможны дальнейшие расширения протокола. Что не просто. В XML-е (да и другом формате текстовой разметки), если не фиксировать жестко DTD, то можно при необходимости расширить любой тег (например, добавить в него атрибутов или дочерних элементов).


Согласно здесь:

Unlike many other syntaxes which claim to be extensible, ASN.1 offers extensibility which addresses the problem of, and provides support for, the interworking between previously deployed systems and newer, updated versions designed years apart.


Я, правда, тоже не спец

E>c) ASN.1 сразу ставит тебя перед высоким порогом вхождения. Во-первых, язык спецификаций. Во-вторых, ASN.1 компиляторы (писать вручную можно разве что ASN.1 BER, да и то не просто, а уж ASN.1 PER...). Их нужно искать, их нужно изучать, за хорошие нужно платить и не мало.


Есть такое. Но, имхо, если бы тот же W3C взялся бы за ASN.1, оставил бы его в текстовом формате, да продвинул бы его, стуация была бы иной.

E>Хотя низкий порог входжения в XML, как показал Голуб, как раз затем и приводит к необдуманному применению XML.


См. также Don’t Invent XML Languages

E>d) Насколько мне известно, ASN.1 не специфицирует отображение своей спецификации в язык программирования. Из-за этого каждый ASN.1 предоставляет собственный маппинг спецификации в классы/функции целевого языка. А из-за этого пользователи ASN.1 привязываются к производителю ASN.1 компилятора.


Ну так то же самое можно сказать и о ХМЛ

E>Так что, имхо, далеко не всегда ASN.1 является более выгодной альтернативой, чем XML. И наоборот. Хотя в некоторых случаях действительно задаешься вопросом: какого черта XML использован? Например, есть такая, имхо, маразматическая штука, как подписанный XML. Вот вместо него ASN.1 вполне мог применяться. Тем более, что области, в которых подписанный XML применяется (электронная коммерция), отнюдь не дешевые. И при разработке в них прикладных решений затраты на ASN.1 компиляторы вовсе не такие чувствительные.


Кстати, читал я описание протокола обменна данными с каим-то из payment gateways. Там народ поступил легко и просто Никакого ХМЛ. Пары ключ-значение, разделенные точками с запятыми и переводами строки. Аж глаз отдыхает

E>Плохо то, что XML раскручен, а ASN.1 нет. Я, например, про него совершено случайно узнал. Поэтому при выборе решений многие разработчики такой альтернативы XML, как ASN.1 или, скажем, скриптовые языки, даже не видят. Из-за элементарного незнания.


+1
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re: Gateway
От: ie Россия http://ziez.blogspot.com/
Дата: 29.09.06 17:51
Оценка: 10 (1)
Здравствуйте, Mamut, Вы писали:

M>Ну и так далее вся секция integration такая


M>И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву.


Довелось работать с 3мя платежками: Verisign, YourPay и Authorize.net. Так вот скажу, что Authorize.net как раз таки самая неудобная из этих 3-х.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Превратим окружающую нас среду в воскресенье.
Re[3]: Gateway
От: ie Россия http://ziez.blogspot.com/
Дата: 30.09.06 15:45
Оценка: 10 (1)
Здравствуйте, Mamut, Вы писали:

M>>>И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву.

ie>>Довелось работать с 3мя платежками: Verisign, YourPay и Authorize.net. Так вот скажу, что Authorize.net как раз таки самая неудобная из этих 3-х.
M>А что в Verisign и Yourpay испольщуется? Таки ХМЛ?

Да.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Превратим окружающую нас среду в воскресенье.
Re[5]: Снова XML: Just Say No to XML
От: Andir Россия
Дата: 30.09.06 10:31
Оценка: 9 (1)
Здравствуйте, c-smile, Вы писали:

CS>Это затмение на людей нашло. Не развивается это дело больше никак.


Смотрел уже Javascript 1.7 ?

С Уважением, Andir!
using( RSDN@Home 1.2.0 alpha rev. 652 ) { /* Работаем */ }
Re: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.04.07 12:39
Оценка: 7 (1)
Здравствуйте, eao197, Вы писали:

E>Мнение Алана Голуба: Just Say No to XML


E>

E>XML, вероятно, худший из когда-либо появлявшихся языков программирования. Я не говорю об XML как о языке описания данных, которым он был в своем первоначальном дизайне...


Еще пару капелек масла в огонь священной войны против XML На этот раз в качестве информации к размышлению о производительности. Разработчики распределенной системы контроля версий Bazaar в новой версии 0.15 отказались от использования XML в качестве формата для хранения описаний в рабочей копии. За счет чего получили серьезный прирост производительности на некоторых операциях (по ссылке рассказывается об ускорении операции status на дереве исходников ядра Linux-а от 2.2 до 13.9 раз(!)). До этого разработчики Subversion так же отказались от использования XML в описателях рабочей копии (см. 1.4 release notes, раздел Working copy performance improvements).

Т.е. имеет смысл задумываться о выборе XML в качестве хранилища данных. Далеко не все ладно в Датском-то королевстве


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Ну дык...
От: c-smile Канада http://terrainformatica.com
Дата: 28.09.06 20:09
Оценка: 1 (1)
Здравствуйте, eao197, Вы писали:

E>
E>{ "smpp_smsc" :
E>  [
E>      { "mbox" : "aag_3::smpp_smsc::<censored>" },
E>      { "smsc_map_mbox" : "aag_3::smsc_map::default" },

E>      { "ip" : "<censored>" },

E>      { "reconnect_timeout" : 91 },
E>      { "restore_timeout" : 91 },

E>      { "mode" : "transceiver" },

E>      { "db" :
E>        [ { "name" : "smpp_smsc/<censored>" },
E>          { "template_cfg" : "aag_3/smpp_smsc/oess.db_template.cfg" }
E>        ]
E>      },
...
E>


Как-то у тебя там все неправильно (имхо) закручено — явно лишние массивы например.

Надо примерно так:

{ 
  smpp_smsc: 
  {
      mbox              :"aag_3::smpp_smsc::<censored>",
      smsc_map_mbox     :"aag_3::smsc_map::default",

      ip                :"<censored>",

      reconnect_timeout :91,
      restore_timeout   :91,

      mode              :"transceiver",
      ...
   }
}


(я использую т.н. JSON+ формат)
Re[6]: Снова XML: Just Say No to XML
От: Turtle.BAZON.Group  
Дата: 29.09.06 09:31
Оценка: 1 (1)
Здравствуйте, ZevS, Вы писали:

ZS>Я как раз про то, что удобно должно быть конечному пользователю продукта. Кроме того надеюсь ни кто не будет спорить что XML имеет множество приемуществ.


Хотелось бы послушать про преимущества ХыМыЛа для конечного пользователя продукта.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Снова XML: Just Say No to XML
От: ArtDenis Россия  
Дата: 27.09.06 11:36
Оценка: -1
eao197 wrote:
> Мнение Алана Голуба: Just Say No to XML

Полностью с ним согласен. Нае...лся с ant-ом по самое нехочу
Заставить работать скрипт анта не так уж и сложно. Гораздо сложнее --
через какое-то время понять, что ты там такое понаписал и что твой код
делает. А всё это — из-за обилия тегов и неудобной для восприятия глазом
структуры разметки.
Posted via RSDN NNTP Server 2.0
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[2]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 27.09.06 11:40
Оценка: +1
ArtDenis wrote:

> Полностью с ним согласен. Нае...лся с ant-ом по самое нехочу

> Заставить работать скрипт анта не так уж и сложно. Гораздо сложнее --
> через какое-то время понять, что ты там такое понаписал и что твой код
> делает. А всё это — из-за обилия тегов и неудобной для восприятия глазом
> структуры разметки.
Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 27.09.06 12:25
Оценка: +1
Andrei N.Sobchuck wrote:

> kan>>Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу.

> E>А обратно?
> Напиши транслятор
Точнее следует ответить так:
Напиши то, что советует писать автор статьи каждый раз в обязательном порядке.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 27.09.06 12:28
Оценка: :)
Cyberax wrote:

>> вот в jsf надо ";", но отделить пробелом.

> Это не jsf, а jam. И я это пофиксил
ты лучше xml прикрути туда
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 27.09.06 12:53
Оценка: +1
C>eao197 wrote:
>> Мнение Алана Голуба: Just Say No to XML
>> <http://www.sdtimes.com/fullcolumn/column-20060901-05.html&gt;
C>Досталлллло!

C>XML — это язык конфигурирования и программирования данных. Я НЕ хочу

C>разбираться с кучей яызков для описания ДАННЫХ — я хочу один формат,
C>который я могу разбирать автоматическими средствами и не писать на
C>каждый чих по парсеру и компилятору. Я хочу иметь автокомплит, подсветку
C>ошибок на лету, поддерживаемость всеми современными IDE.

Только сегодня обзался с fddima по поводу ASN.1

Dmitry Azaraev: одно но: шо такое ASN.1?
...
dmitriid: это способ сериализации и передачи данных
dmitriid: еще до ХМЛ

Dmitry Azaraev: ааа

dmitriid: причем, насколько я понял, намного круче, чем ХМЛ

Dmitry Azaraev: понял
Dmitry Azaraev: чем?
Dmitry Azaraev: круче хмл ничо нет и быть ниможыт

dmitriid: ну, он точно стандартизирован, и там точно ясно, что и кдуа передается

Dmitry Azaraev: патамуша круче хтмл тожы ничо не можыт быть
Dmitry Azaraev: хм. ну xml же ж тоже стандартиризирован. просто это не сериализатор

dmitriid: сек..
dmitriid: см. например http://erlang.org/doc/doc-5.5.1/lib/asn1-1.4.4.11/doc/html/asn1_ug.html#1.2

Dmitry Azaraev: не скажу шо очень понятно, но целевая штука другая всё таки
Dmitry Azaraev: xml сам по себе ничо не стоит. а его схемы — это пестец
Dmitry Azaraev: их в нормальном здравом уме ж писать нивазможна
Dmitry Azaraev: а править автосгенерированные это ишо хуже

dmitriid: ну а в асн можно передавать сложные структуры данных, и не бояться, что принимающая сторона их не пройдет
dmitriid:

Dmitry Azaraev: ну пройдёт или не пройдёт — всё равно принимающая сторона должна знать шо за данные и чо с ними делать
Dmitry Azaraev: само ж оно не сделаетсо

dmitriid: ну, это верно
dmitriid: в общем, ХМЛ cpommittee придумали очередной баян и радуются


Вот вопрос. Чем их ASN.1 не устроил?
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[5]: Снова XML: Just Say No to XML
От: FR  
Дата: 27.09.06 13:01
Оценка: +1
Здравствуйте, kan, Вы писали:

kan>ArtDenis wrote:


>>> Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу.

>> Это не выход
kan>А что выход? Изучать ещё один синтаксис?

Зачем новый хватит или S-выражений или например чего-то forth образного.
Re[9]: Снова XML: Just Say No to XML
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 27.09.06 14:52
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

C>В принципе, для меня нет большой разницы использовать ли Ant (который


слишком уж у Anta убогий язык. Это добивает в разы больше чем XML.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re: Насчет синтаксиса
От: kan Великобритания  
Дата: 28.09.06 09:00
Оценка: -1
Mamut wrote:

> Смотрим, например, вот в небольшой список XML Languages

> <http://xml.coverpages.org/xmlApplications.html&gt;. Их там — 600 штук. И
> каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого
Бред. Синтаксис всех XML-based языков одинаков и стандартизован.

> надо писать свой, неповторимый компилятор/интерпретатор/парсер.

Чем обычные DOM/SAX парсеры не устраивают? А всякие хрени, генерящие код объектной модели по xsd и прочие xml-object
мапперы?
А компилятор/интерпретатор, если нужен, придётся писать в любом случае.
Часть этих 600 языков — языки разметки (FOP, DocBook, XBRL,...), для них вообще не нужно писать
компиляторы/интерпретаторы. Достаточно заюзать готовые либы трансляции в html/pdf/rtf/etc.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Насчет синтаксиса
От: Mamut Швеция http://dmitriid.com
Дата: 28.09.06 09:35
Оценка: +1
>> Смотрим, например, вот в небольшой список XML Languages
>> <http://xml.coverpages.org/xmlApplications.html&gt;. Их там — 600 штук. И
>> каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого
kan>Бред. Синтаксис всех XML-based языков одинаков и стандартизован.

Стандартизирован настолько, насколько буквы русского алфавита стандартизированы для русского языка — не более.

Напомню цитату
Автор: kan
Дата: 27.09.06
:

А что выход? Изучать ещё один синтаксис? Если бы каждый писал свой компилятор на каждый случай, ты бы запоминал, что в
hibernate-маппингах в конце строки надо ставить ";", в ant надо ставить ".", в TestNG не надо ничего ставить, а вот в
jsf надо ";", но отделить пробелом. И в итоге ты бы также "Нае...лся с ant-ом по самое нехочу", т.к. там всё не так, как
в привычном тебе hibernate.


Абсолютно то же самое происходит и с ХМЛем

Потому что:
<!-- version 1-->
<dataElement type="MyType">
    <publicfields>
        <field type="subType">value</field>
    </publicfields>
</dataElement>

и
<!-- version 2-->
<dataElement type="MyType">
    <field type="subType" visibility="public">value</field>
</dataElement>

Это уже два абсолютно разных синтаксиса, каждый из которых надо учить. И помнить их различия, и орать матом на разработчиков, если в новой версии они перейдут с одного синтаксиса на другой (а такое тоже бывает).

>> надо писать свой, неповторимый компилятор/интерпретатор/парсер.

kan>Чем обычные DOM/SAX парсеры не устраивают? А всякие хрени, генерящие код объектной модели по xsd и прочие xml-object
kan>мапперы?

Потому что DOM/SAX парсеры — это хорошо. Но что делать, если verson 1 будет заменен на version 2? Тогда мне все равно придется переписывать ту часть программы, которая пользуется парсером, и перенастраивать маппер. Причем мапперы каждый используют свой формат, который опять же придется изучать с нуля. Потому что Castor несовместим, например, с JAXB

kan>А компилятор/интерпретатор, если нужен, придётся писать в любом случае.

kan>Часть этих 600 языков — языки разметки (FOP, DocBook, XBRL,...), для них вообще не нужно писать
kan>компиляторы/интерпретаторы. Достаточно заюзать готовые либы трансляции в html/pdf/rtf/etc.

А если либ нет?

В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего бы то ни было. Просто еще один формат данных, да еще не совсем удачный
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[5]: Снова XML: Just Say No to XML
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 28.09.06 11:47
Оценка: :)
M>ASN.1 XER
С таким названием, не удивительно, что они в массы не пошли
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[4]: Снова XML: Just Say No to XML
От: SergH Россия  
Дата: 28.09.06 15:23
Оценка: +1
Здравствуйте, ZevS, Вы писали:

ZS>Это вопрос квалификации, а не XML. Настораживает формулировка "если для задачи будет удобно сделать свой транслятор". Что заначит удобнее? Кому удобнее? Программисту Пете — фанату трансляторов и "красивых решений", а дальше хоть трава не расти?


Ну всегда удобно кому-то. Ты предлагаешь заменить Петю на Ваню, фаната xml?

ZS>Рассуждая в сторону, любую программу можно рассматривать как транслятор/интерпритатор/компилятор. Так что же теперь, для всех задачь придумывать свой язык? Кроме того, давно известно: больше кода — больше ошибок. Так что даже не знаю... Очень спорная статья, я бы даже сказл — провокационная.


Может оказаться, что кода получится меньше. Использование скриптов — возможность вынести логику из основного кода. В результате сам "основной код" может стать проще и короче. И гибкость повысится — скрипты проще модифицировать. Я думаю, это и значит "удобнее для задачи".
Делай что должно, и будь что будет
Re[3]: Насчет синтаксиса
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.06 16:57
Оценка: +1
Здравствуйте, Quintanar, Вы писали:

Q>Это вы бред говорите. Для компьютера он может и стандартизирован, а человеку по любому все время приходится учить новый язык.


Вы оба правы и не правы. Синтаксис одинаков если за него принимать сам ХМЛ. И разный если оговориваться, что ХМЛ уточняется специаьными конструкциями и ключевыми словами.

Что до чтения, то с одной стороны базирующиеся на ХМЛ языки проще изучать так как часть синтаксиса уже ясна, но конечно их все равно нужно изучать для понимания формата. Потому и говорят "формат основанный на ХМЛ".

Что касается применений, то ХМЛ конечно никуда не годен как основа для ЯП. Но как формат хранения данных он очень неплох. Формат на то и нужен чтобы него не читать в таком виде постянно, а чтобы хранить в нем что-то с возможностью если нужно открыть файл в текстовом редакторе и подправить что нужно. Так что для разного роде конфигов, форматов файлов (например, Word/Excel/MSBuild), форматов передачи данных по сети и т.п. он отлично подходит. А делать из чего-то панаценю и не надо.

ЗЫ

Не надо бравировать словами панацея и серебрянная пуля. Что за манера наклеивать ярлыки?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Снова XML: Just Say No to XML
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.06 16:57
Оценка: :)
Здравствуйте, Mamut, Вы писали:

M>В нем есть XER, кодирующий его в ХМЛ (веяние времени, однако )


А я всегда думал, что наличие XER-а — это признак, а не моде.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Снова XML: Just Say No to XML
От: trophim Россия  
Дата: 28.09.06 21:01
Оценка: :)
Заметьте, кто поставил минус на основной пост... А я что? Так, просто...
[EOF]
Let it be! — Давайте есть пчелу!
Re: Снова XML: Just Say No to XML
От: vdimas Россия  
Дата: 29.09.06 09:50
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Так почему же XML используется таким неподходящим образом? Насколько я могу судить, это потому, что многие так называемые программисты просто не знают, как сделать компилятор...


Именно. Это вечный "наш" аргумент в борьбе с использованием XML направо и налево. Хорошо, что авторитеты начали озвучивать это же мнение.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 29.09.06 10:26
Оценка: :)
eao197 wrote:

> Вот так же и про XML авторитеты могут говорить и даже показывать личным

> примером, как от этого отказаться. Но командовать парадом будет
> засыпанный с головы до ног синтаксическим сахаром мейнстрим. Ведь дело
Мейнстрим становится таковым не просто так.

> дошло даже до того, что, например, в Scala XML может включаться

> непосредственно в текст программы.
Кстати, в Firefox 1.5 уже можно в Javascript (ECMAScript) <br />
включать
.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[9]: Снова XML: Just Say No to XML
От: GlebZ Россия  
Дата: 29.09.06 10:37
Оценка: +1
Здравствуйте, Mamut, Вы писали:

M>Вот интересно, почему все же был выбран SGML за основу

В первую очередь, чтобы построить связку XHTML+CSS. HTML, в котором сразу замешаны и данные, и визуализация не очень удовлетворял. А затем ребят понесло. Но должен сказать, что в том контексте, в котором он описан и применяется в W3C, XML вполне эффективен.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Снова XML: Just Say No to XML
От: GlebZ Россия  
Дата: 29.09.06 11:15
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Вопрос в том, почему в данном случае не был использован какой-либо из стандартных протоколов?

Стандартных? А xml у нас нестандартный получается? А теперь найди хотя бы одно бесплатное разборщик для одного из твоих протоколов(ну кроме Visa-3D, который сам по себе XML). И чтобы там легко можно было получить данные(типа DOM+XPath+XQuery), и чтобы уследить за структурированностью данных(типа XSD).
E>Если это какая-то наколенная система, и сами разработчики устанавливают в ней правила, то они вполне могли обойтись и без XML, чтобы не плодить лишних сложностей.
Сложности возникают только когда начинают делать свои велосипеды из-за нереальной мысли что будет лучше. Как нибудь попробуй прочитать спецификацию XML(даже без остальных технологий). Он только кажется простым. И там учтено много подводных камней.
Re[11]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 29.09.06 13:29
Оценка: +1
eao197 wrote:

> А теперь представь, что у тебя 200-ти строк такого кода, в которых ты

> ищещь баг. Распечатываешь, чтобы прошерстить исходники в спокойной
> обстановке с карандашом в руках. Тебе будет удобно среди <тегов> суть
> выискивать?
Дело привычки и ничего более.
Я не помню, чтобы я когда либо код печатал и с карандашом над ним сидел, мне неудобно бумагу юзать.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Снова XML: Just Say No to XML
От: vvaizh http://izh-test.sourceforge.net/
Дата: 20.11.06 04:52
Оценка: +1
Алану Голубу бы стоило помолчать

именно его поколение программистов не оставило после себя удобоваримого набора инструментов для написания компиляторов!

xml по сравнению с каким нибудь yacc — это как манна небесная по сравнению с кактусом!

переводить код в "удобочитаемый" и "краткий" язык стоит только тогда когда устоялась структура..

для примера, когда начали программировать и когда придумали "краткий C"?

в общем нынешнее засилье XML ИМХО это то что прогресс движется гораздо быстрее чем могут позволить
обычные "компиляторы компиляторов"..
http://izh-test.sourceforge.net/russian/introduction.html
Re[7]: Снова XML: Just Say No to XML
От: Константин Л. Франция  
Дата: 04.04.07 10:03
Оценка: :)
Здравствуйте, Пацак, Вы писали:

[]

П>Ну кто так оформляет данные?!! Вот как надо:


П>
П><?xml version="1.0" encoding="windows-1251"?>

П><ns1:problem subject="не хотим писать транслятор">
П>    <ns1:solution rule="Используем XML">
П>    <ns1:problem subject="Получили нечитабельные скрипты">
П>        <ns1:solution rule="Используем XSLT" why="чтобы получить читабельность">
П>        <ns1:whatIs what="XSLT">
П>            <ns1:is-a-kind-of child="XSLT" parent="XML"/>
П>        </ns1:whatIs>
П>        <ns1:problem subject="Невозможно преобразовать модифицированные читабельные скрипты обратно в XML">
П>            <ns1:solution rule="Пишем транслятор читабельных скриптов" why="чтобы преобразовать их в XML"> <!-- XML нечитаемый -->
П>            <ns1:remember what="XML использовался для того, чтобы не писать транслятор">
П>            </ns1:solution>
П>        </ns1:problem>
П>        </ns1:solution>
П>    </ns1:problem>
П>    </ns1:solution>
П></ns1:problem>
П>


а где namespace для ns1?
Re[2]: Снова XML: Just Say No to XML
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 10.07.08 08:21
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>XML — это язык конфигурирования и программирования данных. Я НЕ хочу

C>разбираться с кучей яызков для описания ДАННЫХ — я хочу один формат,

А прийдётся разбираться Google открыл протокол обмена данными Protocol Buffers:

Google использует множество различных типов данных, которые передаются в виде сообщений между серверами. Большинство из них имеют иерархическую структуру, которую необходимо представлять в определенном виде. Использование XML в этом случае неэффективно, так как когда сеть и узлы работают на полную мощность, обработка XML отнимает слишком много ресурсов. Кроме того, код для работы с деревом DOM иногда может быть очень громоздким.

Protocol Buffers позволяет описывать простые структуры данных используя специальный язык, который затем компилируется в классы, однозначно представляющие эти структуры в любом выбранном языке программирования. Классы обрабатываются хорошо-оптимизированными парсерами и могут быть сохранены в очень компактной форме. Но что более важно, это легкость их использования: у каждого поля структуры есть свои "get" и "set" методы, и в случае надобности сохранения (или чтения) этого поля в виде массива байтов или же I/O потока, оно осуществляется вызовом соответствующего метода. Полная независимость структуры классов от программ-обработчиков позволяет безболезненно обновлять программы, скомпилированные под «старый» формат.

http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[3]: Снова XML: Just Say No to XML
От: ArtDenis Россия  
Дата: 27.09.06 11:41
Оценка:
kan wrote:
> Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу.

Это не выход
Posted via RSDN NNTP Server 2.0
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[3]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.09.06 12:04
Оценка:
Здравствуйте, kan, Вы писали:

kan>Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу.


А обратно?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Снова XML: Just Say No to XML
От: Cyberax Марс  
Дата: 27.09.06 12:12
Оценка:
kan wrote:
> вот в jsf надо ";", но отделить пробелом.
Это не jsf, а jam. И я это пофиксил
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[3]: Снова XML: Just Say No to XML
От: WolfHound  
Дата: 27.09.06 12:57
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Вот вопрос. Чем их ASN.1 не устроил?

Если мне не изменяет скалероз то он насквозь бинарный...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Снова XML: Just Say No to XML
От: Cyberax Марс  
Дата: 27.09.06 13:01
Оценка:
Mamut wrote:
> Вот вопрос. Чем их ASN.1 не устроил?
Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN
для С++, Java, Perl, PHP, C, C#.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re: Снова XML: Just Say No to XML
От: Plague Россия 177230800
Дата: 27.09.06 13:03
Оценка:
Здравствуйте, eao197, Вы писали:

E>Мнение Алана Голуба: Just Say No to XML


а что у них с сайтом было? не мог почитать =( Прокси гворил что сайт не доступен...
ща вроде расклинило... RSDN DDOS TEAM?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 27.09.06 13:10
Оценка:
eao197 wrote:

> Представляю себе цепочку причинно-следственных связей:

Это нужно делать только если ты эстет и проблемы со зрением "из-за обилия тегов и неудобной для восприятия глазом
структуры разметки". Лично мне при нормальном xml-редакторе (да если ещё и специально обученном данной xsd-шкой)
воспринимать структуру никто не мешает.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.09.06 13:17
Оценка:
Здравствуйте, WolfHound, Вы писали:

M>>Вот вопрос. Чем их ASN.1 не устроил?

WH>Если мне не изменяет скалероз то он насквозь бинарный...

Уже давно есть стандарт ASN.1 XML Encoding Rules (ASN.1 XER).
В общем, какая идея, такое и название.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Снова XML: Just Say No to XML
От: Cyberax Марс  
Дата: 27.09.06 13:39
Оценка:
eao197 wrote:
> Прошу перечитать первый абзац из высказываний Голуба (хоть на русском в
> моем переводе, хоть на английском в оригинале) -- проблемы с XML
> начинаются тогда, когда на нем начинают писать программы вместо
> декларативных описаний. Может быть кто-то и может воспринимать что-то
> подобное за нормальный if
Понимаешь, в некоторых случаях на 10Кб декларативного кода приходится
несколько сотен байт подобного императивного. Стоит ли ради небольшого
неудобства лепить отдельный компилятор?

В принципе, для меня нет большой разницы использовать ли Ant (который
XML) или Jam (в котором свой язык) с точки зрения удобства языка. В
Ant'е я получаю подсветку ошибок и автокомплит по XSD, в Jam'е — удобное
квотирование и лаконичность.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[9]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.09.06 13:49
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Понимаешь, в некоторых случаях на 10Кб декларативного кода приходится

C>несколько сотен байт подобного императивного. Стоит ли ради небольшого
C>неудобства лепить отдельный компилятор?

Ради небольшого, естественно, нет.
А вот если на 400 байт декларативного описания приходится еще 4K императивщины, тогда...

C>В принципе, для меня нет большой разницы использовать ли Ant (который

C>XML) или Jam (в котором свой язык) с точки зрения удобства языка. В
C>Ant'е я получаю подсветку ошибок и автокомплит по XSD, в Jam'е — удобное
C>квотирование и лаконичность.

А я недавно от другого примера слегка ошалел. Для одной из утилит требовалось делать набор описаний в конфигах. Описания довольно однообразные и вручную делать их было ну очень муторно, да и черевато глупыми ошибками. Чтобы упростить их создание был сделан Ruby генератор, который на своем DSL позволял задать только часть описаний, а все остальное делал сам. Более того, чуть-чуть с ним поработав, прямо в DSL была определена вспомогательная функция, которая еще больше сокращала количество описаний. В результате DSL из десяти строчек приводил к генерации десятка конфигурационных файлов с сотнями строк в каждом. Да и сам код генератора оказался гораздо меньше по объему, чем генерируемые им файлы.

Вот теперь следующая идея ждет своего воплощения: встраивать Ruby-интерпритатор прямо в приложение, чтобы DSL им парсился и информация из DSL непосредственно в приложение поступала.

НО! Все это хорошо, пока настройки из приложения обратно в DSL сохранять не нужно.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 27.09.06 14:07
Оценка:
Cyberax wrote:

>> >> вот в jsf надо ";", но отделить пробелом.

>> > Это не jsf, а jam. И я это пофиксил
> kan>ты лучше xml прикрути туда
> Уже поздно. Я уже Питоновый backend туда прикручиваю.
Хотя бы. Но не то убожество, ещё один язык... брр...
А на каком этапе находится? Я ведь до сих пор не решился какую билд-систему заюзать... что-то идея cmake меня тоже не
вдохновила.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 27.09.06 14:10
Оценка:
FR wrote:

>> >> Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу.

>> > Это не выход
> kan>А что выход? Изучать ещё один синтаксис?
>
> Зачем новый хватит или S-выражений или например чего-то forth образного.
А как быть с DOM/SAX/XSD/XPath/XSLT? Что из этого можно прикрутить? Особенно интересуют схемы XSD/RelaxNG.
Да и мне честно говоря пофиг что писать "(" или "<", в чём выигрыш?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[8]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 27.09.06 14:19
Оценка:
eao197 wrote:

> Прошу перечитать первый абзац из высказываний Голуба (хоть на русском в

> моем переводе, хоть на английском в оригинале) -- проблемы с XML
> начинаются тогда, когда на нем начинают писать программы вместо
> декларативных описаний. Может быть кто-то и может воспринимать что-то
> подобное за нормальный if:
Ну так рассуждать, в когда вообще декларативное описание будет выгодее?
<html>
  <head>
   <title>Hi!</title>
  </head>
  <body>
   <p>Hello world!</p>
  </body>
</html>

и что-то вроде
new html()
  .add(new head()
   .add(new title("Hi!"))
  .add(new body()
   .add(new p("Hello world!")));

?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[7]: Снова XML: Just Say No to XML
От: FR  
Дата: 27.09.06 14:52
Оценка:
Здравствуйте, kan, Вы писали:

kan>FR wrote:


>>> >> Напиши xsl-ку переводящую неудобный тебе формат в любой по вкусу.

>>> > Это не выход
>> kan>А что выход? Изучать ещё один синтаксис?
>>
>> Зачем новый хватит или S-выражений или например чего-то forth образного.
kan>А как быть с DOM/SAX/XSD/XPath/XSLT? Что из этого можно прикрутить? Особенно интересуют схемы XSD/RelaxNG.
kan>Да и мне честно говоря пофиг что писать "(" или "<", в чём выигрыш?

Уже ни в чем
Просто похоже те кто разрабатывал XML не думали что его будут использовать как скриптовый язык, по моему это дурость.
Re[7]: Снова XML: Just Say No to XML
От: FR  
Дата: 27.09.06 14:52
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>А с кодировками как быть? А с entity (чтобы не ломать пальцы, набирая

C>какие-нибудь экзотические символы)?

это все раешаемо.

C>Вот если все это прикрутить — получится ТОТ ЖЕ САМЫЙ XML, только вид с

C>профиля.

нет просто не надо использовать xml в качестве скрипта, для этого полно более подходящих и удобных кандидатов.
Re[10]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 27.09.06 15:00
Оценка:
eao197 wrote:

> А это лучше заменить на <http://markaby.rubyforge.org/&gt;:

>
> html {
> head {
> title 'Hi'
> }
> body {
> p {
> 'Hello, world!'
> }
> }
> }

Output defaults to XHTML 1.0 Transitional

А как это проверить? И что мне сделать, чтобы оно было, скажем, WML 1.2.1?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[10]: Снова XML: Just Say No to XML
От: Cyberax Марс  
Дата: 27.09.06 18:23
Оценка:
eao197 wrote:
> Ради небольшого, естественно, нет.
> А вот если на 400 байт декларативного описания приходится еще 4K
> императивщины, тогда...
Тогда действительно дело нечисто

Build-системы как раз стоят посередине между императивщиной и
декларативным описанием.

> Вот теперь следующая идея ждет своего воплощения: встраивать

> Ruby-интерпритатор прямо в приложение, чтобы DSL им парсился и
> информация из DSL непосредственно в приложение поступала.
А зачем?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[4]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 28.09.06 06:21
Оценка:
>> Вот вопрос. Чем их ASN.1 не устроил?
C>Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN
C>для С++, Java, Perl, PHP, C, C#.

Ну вот в том-то и дело
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[4]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 28.09.06 06:21
Оценка:
M>>Вот вопрос. Чем их ASN.1 не устроил?
WH>Если мне не изменяет скалероз то он насквозь бинарный...

В нем есть XER, кодирующий его в ХМЛ (веяние времени, однако )
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[5]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 28.09.06 09:01
Оценка:
Mamut wrote:

> M>>Вот вопрос. Чем их ASN.1 не устроил?

> WH>Если мне не изменяет скалероз то он насквозь бинарный...
> В нем есть XER, кодирующий его в ХМЛ (веяние времени, однако )
Подумаешь, бином Ньютона. А наоборот?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 28.09.06 09:02
Оценка:
Mamut wrote:

>> > Вот вопрос. Чем их ASN.1 не устроил?

> C>Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN
> C>для С++, Java, Perl, PHP, C, C#.
> Ну вот в том-то и дело
Кто виноват? Что делать?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 28.09.06 09:19
Оценка:
Mamut wrote:

> Кстати, читал я описание протокола обменна данными с каим-то из payment

> gateways. Там народ поступил легко и просто Никакого ХМЛ. Пары
> ключ-значение, разделенные точками с запятыми и переводами строки. Аж
> глаз отдыхает
А в какой кодировке? А как иерархию сделать? А может ли ключ содержать ";"? А может ли значение содержать перевод
строки? А как массив значений передать (список — имя/телефон, притом телефон опционален)?
Понятно, что в данном конкретном случае ничего этого, наверное, не надо. Но не надо простые случаи обобщать.
В общем уроды, могли бы заюзать url-form-encoded формат или даже csv, нет, придумали свой велосипед.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 28.09.06 09:35
Оценка:
kan>Понятно, что в данном конкретном случае ничего этого, наверное, не надо. Но не надо простые случаи обобщать.

Так бОльшая часть случаев как раз укладывается в простые

kan>В общем уроды, могли бы заюзать url-form-encoded формат или даже csv, нет, придумали свой велосипед.


Ну, так там примерно CSV и получился
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[6]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 28.09.06 09:36
Оценка:
>> M>>Вот вопрос. Чем их ASN.1 не устроил?
>> WH>Если мне не изменяет скалероз то он насквозь бинарный...
>> В нем есть XER, кодирующий его в ХМЛ (веяние времени, однако )
kan>Подумаешь, бином Ньютона. А наоборот?

Наверняка Он же ж все же протокол передачи данных
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[6]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 28.09.06 09:36
Оценка:
>>> > Вот вопрос. Чем их ASN.1 не устроил?
>> C>Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN
>> C>для С++, Java, Perl, PHP, C, C#.
>> Ну вот в том-то и дело
kan>Кто виноват? Что делать?

Маркетинг виноват Подняли бы вокруг него столько же шумихи, сколько вокруг ХМЛ, то же самое было бы
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[3]: Насчет синтаксиса
От: kan Великобритания  
Дата: 28.09.06 10:43
Оценка:
Quintanar wrote:

>> > Смотрим, например, вот в небольшой список XML Languages

>> > <http://xml.coverpages.org/xmlApplications.html&gt;
> <http://xml.coverpages.org/xmlApplications.html&gt;&gt;. Их там — 600 штук. И
>> > каждый — со своим, наверняка неудобочитаемым синтаксисом. И для каждого
> kan>Бред. Синтаксис всех XML-based языков одинаков и стандартизован.
>
> Это вы бред говорите. Для компьютера он может и стандартизирован, а
> человеку по любому все время приходится учить новый язык. XML — это лишь
> оболочка, как другая кодировка, не более того. Для того, чтобы
> использовать VoiceXML, например, придется выучить новый язык и то, что
> он оформлен в виде XML НИЧЕМ абсолютно тебе в этом предприятии не
> поможет. XML помогает только ленивым программистам, которым в падлу
> написать компилятор/интрепретатор для более удобной для человека формы.
> А вот писать потом программы на XML языке — это ад. Я, как однажды
> имевший несчастье это делать, готов плюнуть в лицо любому, кто станет
> проталкивать убожество типа VoiceXML и прочий креатив больных на голову
> разработчиков.
Тот пример voiceXML что тут приводился, действительно бред. Но это не вина xml, а тех, кто этот voicexml придумывали,
ибо люди не удосужились прочитать рекомендации как писать языки, так что ещё неизвестно, что бы они наворотили без
использования xml.
До абсурда можно довести любую идею.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[7]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 28.09.06 10:54
Оценка:
Mamut wrote:

>> >> > Вот вопрос. Чем их ASN.1 не устроил?

>> > C>Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN
>> > C>для С++, Java, Perl, PHP, C, C#.
>> > Ну вот в том-то и дело
> kan>Кто виноват? Что делать?
> Маркетинг виноват Подняли бы вокруг него столько же шумихи, сколько
> вокруг ХМЛ, то же самое было бы
Как ни прискорбно знать, но маркетинг обычно отражает реальные требования (тем более если учесть некоммерческое
происхождение XML с w3c.org), а не "единственно верные" решения.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[7]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 28.09.06 11:00
Оценка:
Mamut wrote:

> kan>Понятно, что в данном конкретном случае ничего этого, наверное, не

> надо. Но не надо простые случаи обобщать.
> Так бОльшая часть случаев как раз укладывается в простые
И чем такая штука была бы хуже? Чем сложнее?
<payment>
  <key1>Value</key1>
  <key2>По-русски</key2>
  <key3>Ё!"№;%:?*()_+Ё!"№;%:?*()~!@#$%^&*()_+{}|<>?[\];',./</key3>
</payment>

Зато ни у кого никаких бы вопросов не возникло бы.

> kan>В общем уроды, могли бы заюзать url-form-encoded формат или даже

> csv, нет, придумали свой велосипед.
> Ну, так там примерно CSV и получился
И какого хера тогда? Вместо того, чтобы взять готовый кусок кода для работы с CSV, программист вынужден писать очередной
велосипед.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: Насчет синтаксиса
От: Quintanar Россия  
Дата: 28.09.06 11:26
Оценка:
Здравствуйте, kan, Вы писали:

kan>Тот пример voiceXML что тут приводился, действительно бред. Но это не вина xml, а тех, кто этот voicexml придумывали,

kan>ибо люди не удосужились прочитать рекомендации как писать языки, так что ещё неизвестно, что бы они наворотили без
kan>использования xml.
kan>До абсурда можно довести любую идею.

Не нефига, я неправильно выразился. VoiceXML сделан очень грамотно, многое в нем неплохо продумано. Был бы очень приятный язык, если бы не xml.
Re[4]: Насчет синтаксиса
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 28.09.06 11:28
Оценка:
Здравствуйте, kan, Вы писали:

>> В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего

>> бы то ни было. Просто еще один формат данных, да еще не совсем удачный
kan>А он и не панацея. Есть места где он неприменим, но те наезды что звучат здесь — мимо тазика.

Изначально речь шла о том, что XML плох в качестве языка программирования. По этому поводу вы что можете сказать?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Насчет синтаксиса
От: Mamut Швеция http://dmitriid.com
Дата: 28.09.06 11:38
Оценка:
>> <!-- version 1-->

>> Это уже два абсолютно разных синтаксиса, каждый из которых надо учить. И

kan>Это семантика, не путаем, плз. Редактор обученный xsd-шкой поможет в данном случае.

Если файл больше одной страницы текста, то ни один редактор не поможет (мне, например, влом разбираться)

>> помнить их различия, и орать матом на разработчиков, если в новой версии

>> они перейдут с одного синтаксиса на другой (а такое тоже бывает).
kan>Если не сделают xsl-ки для конвертирования из старой версии — наорать, да самому наваять за пол часа.

А оно мне надо?

kan>БезXMLные альтернативы в студию. Да чтобы с совсместимостью, какую вы тут требуете.


Таких и нет. Но и пропагандировать ХМЛ, как панацею, которая ручками, в редакторе, за полчаса, и еще неизвестно, заработает ли, тоже пропагандировать не надо

>> kan>А компилятор/интерпретатор, если нужен, придётся писать в любом случае.

>> kan>Часть этих 600 языков — языки разметки (FOP, DocBook, XBRL,...), для
>> них вообще не нужно писать
>> kan>компиляторы/интерпретаторы. Достаточно заюзать готовые либы
>> трансляции в html/pdf/rtf/etc.
>> А если либ нет?
kan>А если компьютера нет? Свой паять?

Легко!

>> В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего

>> бы то ни было. Просто еще один формат данных, да еще не совсем удачный
kan>А он и не панацея. Есть места где он неприменим, но те наезды что звучат здесь — мимо тазика.

Имхо, он вообще нигде не применим Для конфигов легче использовать YAML/JSON/INI, особенно, если их руками надо править, а для всего остального он не предназначен. Имхо, конечно.
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[5]: Насчет синтаксиса
От: kan Великобритания  
Дата: 28.09.06 11:51
Оценка:
eao197 wrote:

>> > В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего

>> > бы то ни было. Просто еще один формат данных, да еще не совсем удачный
> kan>А он и не панацея. Есть места где он неприменим, но те наезды что
> звучат здесь — мимо тазика.

> Изначально речь шла о том, что XML плох в качестве языка

> программирования. По этому поводу вы что можете сказать?
Насчёт языков программирования ещё могу согласится, но "описания тестов", "описания объектно-реляционного отображения",
"описания потоков управления" уже со скрипом, особенно, если в качестве альтернанивы предлагается написать свой
собственный компилятор, да ещё и сетует "ремесла построения компиляторов не так уж и много".
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[8]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 28.09.06 11:53
Оценка:
>> kan>Понятно, что в данном конкретном случае ничего этого, наверное, не
>> надо. Но не надо простые случаи обобщать.
>> Так бОльшая часть случаев как раз укладывается в простые
kan>И чем такая штука была бы хуже? Чем сложнее?
kan>
kan><payment>
kan>  <key1>Value</key1>
kan>  <key2>По-русски</key2>
kan>  <key3>Ё!"№;%:?*()_+Ё!"№;%:?*()~!@#$%^&*()_+{}|<>?[\];',./</key3>
kan></payment>
kan>

kan>Зато ни у кого никаких бы вопросов не возникло бы.

Так как это payment gateway, то им критичны объемы передаваемой информации.
Что-то в стиле:
payment:1;2;34.5;;

всяко меньше, чем в ХМЛ.

>> kan>В общем уроды, могли бы заюзать url-form-encoded формат или даже

>> csv, нет, придумали свой велосипед.
>> Ну, так там примерно CSV и получился
kan>И какого хера тогда? Вместо того, чтобы взять готовый кусок кода для работы с CSV, программист вынужден писать очередной
kan>велосипед.

CSV им не особо подходит, потому что на одних значениях не уедешь, а там довольно разнообразная информация передается (аутентикация, типы карточек, суммы, типы оплат, информация о пользователе...). Жаль, я сейчас просто не вспомню, что это за gateway был Но формат у них был легчайший. А ответы могли разбираться даже простейшим split() по какому-то символу.
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[8]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 28.09.06 12:09
Оценка:
>>> >> > Вот вопрос. Чем их ASN.1 не устроил?
>>> > C>Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN
>>> > C>для С++, Java, Perl, PHP, C, C#.
>>> > Ну вот в том-то и дело
>> kan>Кто виноват? Что делать?
>> Маркетинг виноват Подняли бы вокруг него столько же шумихи, сколько
>> вокруг ХМЛ, то же самое было бы
kan>Как ни прискорбно знать, но маркетинг обычно отражает реальные требования (тем более если учесть некоммерческое
kan>происхождение XML с w3c.org), а не "единственно верные" решения.

Тот же ASN.1 — вполне себе открытый стандарт, уже включающий в себя многое из того, чтов ХМЛ нет и не предвидится, и для чего приходится выдумывать новые стандарты. См. Re[4]: Снова XML: Just Say No to XML
Автор: Mamut
Дата: 28.09.06
в самом начале, где сравнивается ASN.1 и XML.

w3c достаточно было оставить ASN.1 как есть, в текстовом формате, без компиляции, и был бы готовый новый ХМЛ. А там бы и тулзы подтянулись бы. Благо парсить его будет полегче, чем ХМЛ, да и на больших файлах он выгоднее.

Вот интересно, почему все же был выбран SGML за основу
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re: Снова XML: Just Say No to XML
От: ZevS Россия  
Дата: 28.09.06 14:11
Оценка:
Здравствуйте, eao197, Вы писали:
...

Весь смысл статьи — "Печально я гляжу на не наше поколенье" и "да молодежь нонче не та, вот в наше время.."
Re[2]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 28.09.06 14:14
Оценка:
Здравствуйте, ZevS, Вы писали:

ZS>Весь смысл статьи — "Печально я гляжу на не наше поколенье" и "да молодежь нонче не та, вот в наше время.."


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Ну дык...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 28.09.06 15:34
Оценка:
Здравствуйте, c-smile

Заранее прошу прощения за длинное сообщение

CS>... Ну дык json то рулез я всегда говорил...


Ну не всегда. Сейчас попробовал один из своих средних размеров конфигов в JSON представить. Дошел только до половины, затем устал -- слишком много синтаксических заморочек (необходимость использования массивов, числа не имеют шестнадцатиричного представления и пр.). Вот что получилось (извиняюсь за объем, но это всего лишь половина того, что нужно):
{ "smpp_smsc" :
  [
      { "mbox" : "aag_3::smpp_smsc::<censored>" },
      { "smsc_map_mbox" : "aag_3::smsc_map::default" },

      { "ip" : "<censored>" },

      { "reconnect_timeout" : 91 },
      { "restore_timeout" : 91 },

      { "mode" : "transceiver" },

      { "db" :
        [ { "name" : "smpp_smsc/<censored>" },
          { "template_cfg" : "aag_3/smpp_smsc/oess.db_template.cfg" }
        ]
      },

      { "authentification" :
        [ { "system_id" : "<censored>" },
          { "system_type" : "<censored>" },
          { "password" : "<censored>" },

          { "interface_version" : "0x34" },

          { "addr_ton" : 0 },
          { "addr_npi" : 0 },

          { "bind_resp_timeout" : 20 },
          { "unbind_resp_timeout" : 20 }
        ]
      },

      { "channel" :
        [ { "enquire_link_timeout" : 60 },
          { "sms_data_type::smpp2smsg" :
            [ { "import_defaults" : "aag_3/sms_data_type/smpp2smsg.cfg"} ]
          },
          { "sms_data_type::smsg2smpp" :
            [ { "import_defaults" : "aag_3/sms_data_type/smsg2smpp.cfg"},
              { "type" :
                [ { "name" : "e_custom_03" },
                  { "esm_class" : "0x00" },
                  { "protocol_id" : "0x00" },
                  { "data_coding" : "0x19" }
                ]
              },
              { "type" :
                [ { "name" : "e_8bit_with_udh" },
                  { "esm_class" : "0b01000000" },
                  { "protocol_id" : "0b01111111" },
                  { "data_coding" : "0b11110110" }
                ]
              }
            ]
          },
// ...bla-bla-bla...
  ]
}


В исходном варианте было так:
{smpp_smsc
    {mbox    "aag_3::smpp_smsc::<censored>" }
    {smsc_map_mbox    "aag_3::smsc_map::default" }

    {ip "<censored>" }

    {reconnect_timeout    91 }
    {restore_timeout    91 }

    {mode "transceiver" }

    {db    "smpp_smsc/<censored>"
        {template_cfg "aag_3/smpp_smsc/oess.db_template.cfg" } }

    {authentification

        {system_id    "<censored>" }
        {system_type    "<censored>" }
        {password    "<censored>" }

        {interface_version 0x34 }

        {addr_ton    0x00 }
        {addr_npi    0x00 }

        {bind_resp_timeout    20 }
        {unbind_resp_timeout 20 }
    }

    {channel
        {enquire_link_timeout 60 }

        {sms_data_type::smpp2smsg
            {import_defaults "aag_3/sms_data_type/smpp2smsg.cfg"}
        }

        {sms_data_type::smsg2smpp
            {import_defaults "aag_3/sms_data_type/smsg2smpp.cfg"}

            {type    "e_custom_03"
                {esm_class    0x00 }
                {protocol_id    0x00}
                {data_coding    0x19} }

            {type    "e_8bit_with_udh"
                {esm_class   0b01000000 }
                {protocol_id 0b01111111 }
                {data_coding 0b11110110 } }
        }
|| ...bla-bla-bla...
}

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

А вот то же самое, но в YAML. Очень компактно, но, имхо, эта же компактность и вредит читабельности:
smpp_smsc:
  mbox: aag_3::smpp_smsc::<censored>
  smsc_map_mbox: aag_3::smsc_map::default
  ip: <censored>
  reconnect_timeout: 91
  restore_timeout: 91
  mode: transceiver
  db:
    name: smpp_smsc/<censored>
    template_cfg: aag_3/smpp_smsc/oess.db_template.cfg
  authentification:
    system_id: <censored>
    system_type: <censored>
    password: <censored>
    interface_version: 0x34
    addr_ton: 0x00
    addr_npi: 0x00
    bind_resp_timeout: 20
    unbind_resp_timeout: 20
  channel:
    enquire_link_timeout: 60
    sms_data_type--smpp2smsg:
      -
        import_defaults: aag_3/sms_data_type/smpp2smsg.cfg
    sms_data_type--smsg2smpp:
      -
        import_defaults: aag_3/sms_data_type/smsg2smpp.cfg
      -
        type: e_custom_03
        esm_class: 0x00
        protocol_id: 0x00
        data_coding: 0x19
      -
        type: e_8bit_with_udh
        esm_class: 0b01000000
        protocol_id: 0b01111111
        data_coding: 0b11110110


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Снова XML: Just Say No to XML
От: Пацак Россия  
Дата: 28.09.06 15:38
Оценка:
Здравствуйте, SergH, Вы писали:

ZS>>Это вопрос квалификации, а не XML. Настораживает формулировка "если для задачи будет удобно сделать свой транслятор". Что заначит удобнее? Кому удобнее? Программисту Пете — фанату трансляторов и "красивых решений", а дальше хоть трава не расти?

SH>Ну всегда удобно кому-то. Ты предлагаешь заменить Петю на Ваню, фаната xml?

Нет, даже не так, это еще бы было полбеды. На самом деле предлагается заменить программиста и разработчика системы Петю на множество Вась — пользователей этой системы. И еще не факт, что они будут фанатеть от навязанного им XML, особенно если внедряется он не ради их удобства, а просто потому что "зачем ломать голову, если есть SAX/DOM" и "не хватало нам еще тратить ресурсы на собственный парсер".
Ку...
Re[4]: Снова XML: Just Say No to XML
От: Odi$$ey Россия http://malgarr.blogspot.com/
Дата: 28.09.06 15:38
Оценка:
Здравствуйте, ZevS, Вы писали:

ZS>Так что же теперь, для всех задачь придумывать свой язык?


Языково-ориентированное программирование: следующая парадигма
Автор(ы): Сергей Дмитриев
Дата: 02.03.2006
Пришло время следующей технологической революции в разработке софта – и становится все очевиднее, какой она должна быть. Новая парадигма программирования – вот она, перед нами. Она еще не вполне сформировалась – разные части известны под разными именами вроде Intentional Programming, MDA, порождающее программирование и т.д. Я предлагаю объединение этих новаторских подходов под общим именем «языково-ориентированного программирования»; данная статья объясняет основные принципы новой парадигмы.
... << RSDN@Home 1.2.0 alpha rev. 654>>
Re[5]: Снова XML: Just Say No to XML
От: ZevS Россия  
Дата: 29.09.06 06:32
Оценка:
Здравствуйте, SergH, Вы писали:

..

SH>Ну всегда удобно кому-то. Ты предлагаешь заменить Петю на Ваню, фаната xml?


Я как раз про то, что удобно должно быть конечному пользователю продукта. Кроме того надеюсь ни кто не будет спорить что XML имеет множество приемуществ.

ZS>>Рассуждая в сторону, любую программу можно рассматривать как транслятор/интерпритатор/компилятор. Так что же теперь, для всех задачь придумывать свой язык? Кроме того, давно известно: больше кода — больше ошибок. Так что даже не знаю... Очень спорная статья, я бы даже сказл — провокационная.


SH>Может оказаться, что кода получится меньше. Использование скриптов — возможность вынести логику из основного кода. В результате сам "основной код" может стать проще и короче. И гибкость повысится — скрипты проще модифицировать. Я думаю, это и значит "удобнее для задачи".


Вынести логику из основного кода невозможно. Конечно если это — основная логика. Даже если логику забить в таблицу базы данных — основной код будет уже в таблице базы данных.

И не факт что поддерживать основной код на доморощенном языке будет проще, удобнее и гибче.... Хотя конечно все зависит он конкретной задачи, и дальше лозунгов в отрыве от нее не уйти.
Re[5]: Насчет синтаксиса
От: kan Великобритания  
Дата: 29.09.06 08:06
Оценка:
VladD2 wrote:

> kan>Это семантика, не путаем, плз. Редактор обученный xsd-шкой поможет в

> данном случае.
>
> Это ты путашь. Это как раз синтаксис. Семантика это интерпретация данных.
Ээ... Тег это синтаксическая единица. А вот тег "html" это уже семантическая, означающая корневой "оператор программы
браузеру". Как функция в С++ — синтаксическая единица, а вот функция "main" — семантическая, означающая точку входа в
программу. Разве не так?

> Ты же говоришь о базовм синтаксисе. Только языки базирующиеся на ХМЛ

> добавляют к ХМЛ свои ограничения и синтаксические правила.
В случае "языки базирующиеся на С++" можно рассматривать API, библиотеки. Сделали "#include <vector>", можем
использовать семантическую единицу "std::vector", сделали "xmlns='http://www.w3.org/1998/Math/MathML'", можем
использовать "<math><apply><fn/>...".
По-моему полная аналогия. И те же проблемы с версиями, обратной совместимостью — поменяли API — переписывай программу,
поменяли XSD-шку — переписывай маппинг.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 29.09.06 08:38
Оценка:
eao197 wrote:

> ZS>Это вопрос квалификации, а не XML.

>
> Так в том-то и смысл! По мнению Голуба (и не только его), квалификация
> сейчас у многих разработчиков настолько низкая, что они даже не смогут
> сделать оценку трудозатрат/рисков/преимуществ собственного транслятора
> перед XML (или наоборот). Это плохо, но и выхода не видно, т.к.
> нормальной литературы для обучения практики построения компиляторов по
> мнению Голуба не много. Такой-вот замкнутый круг.
Если квалификация не позволяет написать вменяемый xml (тут
Автор: dshe
Дата: 27.09.06
,
тут
Автор: CrystaX
Дата: 27.09.06
), то какой же получится компилятор?
Так что xml тут совершенное не при чём.

> Вот вам бы, например, было бы удобно писать Wiki-странички в формате

> XML? И как вы думаете, получили бы Wiki-системы такое распространение,
> если бы в качестве языка разметки они предлагали пользователю XML?
+
Обычным смертным пользователям действительно страшно видеть xml-теги, хотя тот же MS Word уже пытается решить эту проблему.

> Если же подразумевается передавать данные между приложениями, тогда

> изобретение собственного языка и транслятора действительно вряд ли будет
> оправдано (если только не вмешаются какие-нибудь специфические
> требования по эффективности/компактности, но и здесь есть возможность
> взять ASN.1). Для таких вещей XML предназначался и пусть именно для
> этого используется.
Интерфейс к платёжной системе — имхо тот случай. Однако, и тут начинают экономить <br />
непонятно на чём
Автор: Mamut
Дата: 28.09.06
, вот что самое интересное.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Снова XML: Just Say No to XML
От: ZevS Россия  
Дата: 29.09.06 08:46
Оценка:
Здравствуйте, eao197, Вы писали:

...

ZS>>Это вопрос квалификации, а не XML.


E>Так в том-то и смысл! По мнению Голуба (и не только его), квалификация сейчас у многих разработчиков настолько низкая, что они даже не смогут сделать оценку трудозатрат/рисков/преимуществ собственного транслятора перед XML (или наоборот). Это плохо, но и выхода не видно, т.к. нормальной литературы для обучения практики построения компиляторов по мнению Голуба не много. Такой-вот замкнутый круг.


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

ZS>>Настораживает формулировка "если для задачи будет удобно сделать свой транслятор". Что заначит удобнее? Кому удобнее? Программисту Пете — фанату трансляторов и "красивых решений", а дальше хоть трава не расти?


E>Универсального ответа здесь нет, нужно смотреть на конкретные условия.


+1

E>Если речь идет о создании чего-либо, вроде Interface Definition Language или Data Definition Language, который будет предназначен для работы пользователей (как написанию, так и чтению) без наличия специализированных инструментов, то собственный транслятор может оказаться оправданным. Вот, к примеру, есть DocBook. Не знаю как кому, но я за него так и не взялся, поскольку набирать текст в VIM-е в XML не так уж просто. Нужны специализированные XML редакторы, заточенные под удобное редактирование DocBook-а. Между тем, LaTeX, при тех же, в общем-то, возможностях, совершенно спокойно редактируется как в VIM-е, так в Notepade, так и в FAR-е. Просто потому, что LaTeX-овый синтаксис ориентирован на работу человека с текстом. А Wiki-форматирование пошло еще дальше -- очень простой формат текста, но отлично решает поставленные перед ним задачи.


Пример с форматированием текста на мой взгляд не очень убедительный. Мне лично удобнее набирать текст в том же ворде. ))
Re[6]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 29.09.06 09:04
Оценка:
>> Если же подразумевается передавать данные между приложениями, тогда
>> изобретение собственного языка и транслятора действительно вряд ли будет
>> оправдано (если только не вмешаются какие-нибудь специфические
>> требования по эффективности/компактности, но и здесь есть возможность
>> взять ASN.1). Для таких вещей XML предназначался и пусть именно для
>> этого используется.
kan>Интерфейс к платёжной системе — имхо тот случай. Однако, и тут начинают экономить <br />
<span class='lineQuote level1'>kan&gt;непонятно на чём</span>
Автор: Mamut
Дата: 28.09.06
, вот что самое интересное.


Ну, как сказать "непонятно" Если клиентуры много и надо обрабатывать очень большое количество платежей, то тупой парсинг
key=value;key=value;key=value

будет, во-первых, быстрее парсинга(ну или маппинга на объекты) многословного ХМЛя. А во-вторых, вместо, скажем, гигабайта данных в день удастся передать 700 мегабайтов в день на экономии только тэгов. Цифры взяты с потолка, конечно, но можно и подсчитать:
Например, мы посылаем ИД клиента, тип уплаты, номер кредитки, проверосный код, кол-во денег.

Гипотетический код платежной системы:
payment::clientid=2ni3poicy5b8924v;ptype=VISA;ccno=1234567890123456;vcode=12345;amount=23.5;;

Максимально упрощенный ХМЛ:
<payment clientid="2ni3poicy5b8924v" ptype="VISA" ccno="1234567890123456" vcode="12345" amount="23.5" />

У нас добавляется по 2 символа на значение, что при больших объемах влетает в копеечку
Ну и, во-вторых, парсер ХМЛ уже сложнее. Ненамного, а оно нам нужно?
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[7]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 29.09.06 09:56
Оценка:
Mamut wrote:

> будет, во-первых, быстрее парсинга(ну или маппинга на объекты)

> многословного ХМЛя. А во-вторых, вместо, скажем, гигабайта данных в день
> удастся передать 700 мегабайтов в день на экономии только тэгов. Цифры
> взяты с потолка, конечно, но можно и подсчитать:
> Например, мы посылаем ИД клиента, тип уплаты, номер кредитки,
> проверосный код, кол-во денег.
Если 700 мегабайтов, 1 платёж — 700 байтов (а это много даже для максимально многословного xml), то это миллион
платежей, даже по одному доллару — это миллион долларов в день. Знаешь, те кто имеет такие деньги — может положить
себе крутейшие сети и этот трафик будет пофиг.

Кстати, прикольно поглядеть на jabber протокол — полностью xml-based, никто не жалуется.

> Гипотетический код платежной системы:

>
> payment::clientid=2ni3poicy5b8924v;ptype=VISA;ccno=1234567890123456;vcode=12345;amount=23.5;;
>
>
> Максимально упрощенный ХМЛ:
>
> <payment clientid="2ni3poicy5b8924v" ptype="VISA" ccno="1234567890123456" vcode="12345" amount="23.5" />
> У нас добавляется по 2 символа на значение, что при больших объемах
> влетает в копеечку
Экономия на спичках, назвается.

> Ну и, во-вторых, парсер ХМЛ уже сложнее. Ненамного, а оно нам нужно?

Да, но его не надо писать, кто его пишет — сам себе злобный буратино.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.09.06 10:18
Оценка:
Здравствуйте, vdimas, Вы писали:

E>>Так почему же XML используется таким неподходящим образом? Насколько я могу судить, это потому, что многие так называемые программисты просто не знают, как сделать компилятор...


V>Именно. Это вечный "наш" аргумент в борьбе с использованием XML направо и налево. Хорошо, что авторитеты начали озвучивать это же мнение.


Угу, только знаешь какая аналогия напрашивается? Вот Вирт давно говорит, что язык программирования должен быть минималистическим и простым (показывая это на примерах своих творений). Только правят бал перегруженные монстры, вроде C++ или Java.

Вот так же и про XML авторитеты могут говорить и даже показывать личным примером, как от этого отказаться. Но командовать парадом будет засыпанный с головы до ног синтаксическим сахаром мейнстрим. Ведь дело дошло даже до того, что, например, в Scala XML может включаться непосредственно в текст программы.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.09.06 10:46
Оценка:
Здравствуйте, kan, Вы писали:

kan>Если квалификация не позволяет написать вменяемый xml (тут
Автор: dshe
Дата: 27.09.06
,


Это первоапрельская шутка, в рассмотрение не берем.

kan>тут
Автор: CrystaX
Дата: 27.09.06
), то какой же получится компилятор?


А как вот этот, по-вашему, можно сделать вменяемым?

kan>Так что xml тут совершенное не при чём.


Мне кажется, что весьма причем.

kan>Интерфейс к платёжной системе — имхо тот случай. Однако, и тут начинают экономить <br />
<span class='lineQuote level1'>kan&gt;непонятно на чём</span>
Автор: Mamut
Дата: 28.09.06
, вот что самое интересное.


Я не буду судить о корректности принятого там решения, посколько совершенно не в теме. На первый взгляд кажется, что XML дейсвительно там напрашивается. Но... Платежные системы, насколько я знаю, уже обладают стандартным протоколами (например, двоичный ISO 8583, SET, основанные на HTTP+XML протоколы в системе Visa 3D Secure). Вопрос в том, почему в данном случае не был использован какой-либо из стандартных протоколов? Если это какая-то наколенная система, и сами разработчики устанавливают в ней правила, то они вполне могли обойтись и без XML, чтобы не плодить лишних сложностей.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Снова XML: Just Say No to XML
От: _rasta  
Дата: 29.09.06 10:54
Оценка:
Здравствуйте, kan, Вы писали:

kan>Кстати, прикольно поглядеть на jabber протокол — полностью xml-based, никто не жалуется.


я жалуюсь. при всей моей любви к этой игрушке трафик, при большОй стимости за оный, достаточно велик и точно проигрывает icq-шному.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 29.09.06 11:00
Оценка:
>> будет, во-первых, быстрее парсинга(ну или маппинга на объекты)
>> многословного ХМЛя. А во-вторых, вместо, скажем, гигабайта данных в день
>> удастся передать 700 мегабайтов в день на экономии только тэгов. Цифры
>> взяты с потолка, конечно, но можно и подсчитать:
>> Например, мы посылаем ИД клиента, тип уплаты, номер кредитки,
>> проверосный код, кол-во денег.
kan>Если 700 мегабайтов, 1 платёж — 700 байтов (а это много даже для максимально многословного xml), то это миллион
kan>платежей, даже по одному доллару — это миллион долларов в день. Знаешь, те кто имеет такие деньги — может положить
kan>себе крутейшие сети и этот трафик будет пофиг.

Экономить всегда полезно.
Это кстати, косвенное отражение общей тенденции сегодняшних дней — "пофиг, что много, мы его задавим объемами сетей/компов/памяти". Экономить разучились совсем.

kan>Кстати, прикольно поглядеть на jabber протокол — полностью xml-based, никто не жалуется.


Jabber :: Protocols

Читаю наискосок описание. Гы. Как туториал по общению через сокеты читаю

Пошлите START
Пошлите информацию
Пошлите END



В RFC это описывают Xml Streams and Xml Stanzas.

>> Гипотетический код платежной системы:

>>
>> payment::clientid=2ni3poicy5b8924v;ptype=VISA;ccno=1234567890123456;vcode=12345;amount=23.5;;
>>
>>
>> Максимально упрощенный ХМЛ:
>>
>> <payment clientid="2ni3poicy5b8924v" ptype="VISA" ccno="1234567890123456" vcode="12345" amount="23.5" />
>> У нас добавляется по 2 символа на значение, что при больших объемах
>> влетает в копеечку
kan>Экономия на спичках, назвается.

Спички-спичками, но когда таких спичек много...

>> Ну и, во-вторых, парсер ХМЛ уже сложнее. Ненамного, а оно нам нужно?

kan>Да, но его не надо писать, кто его пишет — сам себе злобный буратино.

Как это не надо писать? Даже если его и написали, то это написал кто-то, доверия к кому может и не быть. И _в любом_ случае работа с ХМЛ никогда не побьет по простоте вот это:
// псевдо код
MessageArray = split(message, "::");
KeyValueArray = split(MessageArray(1), ";");
for(...)
{
    KeyValuePair = split(KeyValueArray[i], '=');
}

// где split может быть невероятно шустрым


В то время, как для ХМЛ придется писать callback функции для SAX, долго разбирать структуру для DOM и т.п. Зачем? Если в нашем случае наш же собственный велосипед будет приспособлен именно для наших нужд и оптимизирован по самое нехочу?
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[8]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.09.06 11:35
Оценка:
Здравствуйте, GlebZ, Вы писали:

E>>Вопрос в том, почему в данном случае не был использован какой-либо из стандартных протоколов?

GZ>Стандартных? А xml у нас нестандартный получается?

XML -- это eXtensible Makeup Language. Он никогда не являлся стандартным протоколом для какого-либо вида электронной коммерции. Поскольку кроме формата данных, в протоколе специфицируются и фазы обмена данными, ответственность сторон, поведение сторон в тех или иных ситуациях и пр.

Глеб, извини, но ты мог бы уже так дословно к словам не цепляться.

GZ>А теперь найди хотя бы одно бесплатное разборщик для одного из твоих протоколов(ну кроме Visa-3D, который сам по себе XML). И чтобы там легко можно было получить данные(типа DOM+XPath+XQuery), и чтобы уследить за структурированностью данных(типа XSD).


Для ISO 8583, например, вот.
Что касается SET, то там ситуация, насколько я помню, не простая. И инструменты для поддержки SET, помниться, подлежат сертификации.
Что касается Visa 3DS, то и там не простой парсинг, а со своими заморочками. Кроме того, XML там должен быть подписанным.

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

GZ>Сложности возникают только когда начинают делать свои велосипеды из-за нереальной мысли что будет лучше. Как нибудь попробуй прочитать спецификацию XML(даже без остальных технологий). Он только кажется простым. И там учтено много подводных камней.

Здесь я с тобой согласен. Но меня вообще интересует, чтоже это за платежная система, которая вместо стандартных (хоть и сложных, и дорогих) решений позволяет использовать собственные key=value.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 29.09.06 11:44
Оценка:
Mamut wrote:

>> > будет, во-первых, быстрее парсинга(ну или маппинга на объекты)

>> > многословного ХМЛя. А во-вторых, вместо, скажем, гигабайта данных в день
>> > удастся передать 700 мегабайтов в день на экономии только тэгов. Цифры
>> > взяты с потолка, конечно, но можно и подсчитать:
>> > Например, мы посылаем ИД клиента, тип уплаты, номер кредитки,
>> > проверосный код, кол-во денег.
> kan>Если 700 мегабайтов, 1 платёж — 700 байтов (а это много даже для
> максимально многословного xml), то это миллион
> kan>платежей, даже по одному доллару — это миллион долларов в день.
> Знаешь, те кто имеет такие деньги — может положить
> kan>себе крутейшие сети и этот трафик будет пофиг.
> Экономить всегда полезно.
Это называется преждевременной оптимизацией.

> Это кстати, косвенное отражение общей тенденции сегодняшних дней —

> "пофиг, что много, мы его задавим объемами сетей/компов/памяти".
> Экономить разучились совсем.
Это дорого.

> Читаю наискосок описание. Гы. Как туториал по общению через сокеты читаю

> Пошлите START
> Пошлите информацию
> Пошлите END
Не знаю, вот лог миранды:

<message to="[censored]@gmail.com/MirandaE94EDA38" type="chat" id="A3E644D00EEBB7A04"
from="[censored]@gmail.com/gmail.F7173C35"><body>тута юникод. тута юникод. тута юникод. тута
юникод.</body><met:google-mail-signature
xmlns:met="google:metadata">2a9ef4121b679969</met:google-mail-signature><cha:active
xmlns:cha="http://jabber.org/protocol/chatstates"/><nos:x value="disabled" xmlns:nos="google:nosave"/><arc:record
otr="false" xmlns:arc="http://jabber.org/protocol/archive"/></message>

Не знаю что всё это означает, честно говоря.

>> > Гипотетический код платежной системы:

>> >
>> >
> payment::clientid=2ni3poicy5b8924v;ptype=VISA;ccno=1234567890123456;vcode=12345;amount=23.5;;
>> >
>> >
>> > Максимально упрощенный ХМЛ:
>> >
>> > <payment clientid="2ni3poicy5b8924v" ptype="VISA"
> ccno="1234567890123456" vcode="12345" amount="23.5" />
>> > У нас добавляется по 2 символа на значение, что при больших объемах
>> > влетает в копеечку
> kan>Экономия на спичках, назвается.
>
> Спички-спичками, но когда таких спичек много...
>
>> > Ну и, во-вторых, парсер ХМЛ уже сложнее. Ненамного, а оно нам нужно?
> kan>Да, но его не надо писать, кто его пишет — сам себе злобный буратино.
>
> Как это не надо писать? Даже если его и написали, то это написал кто-то,
> доверия к кому может и не быть. И _в любом_ случае работа с ХМЛ никогда
> не побьет по простоте вот это:

> // псевдо код
> MessageArray = split(message, "::");
> KeyValueArray = split(MessageArray(1), ";");
> for(...)
> {
>     KeyValuePair = split(KeyValueArray[i], '=');
> }
> 
> // где split может быть невероятно шустрым

А вот тоже самое, но для xml в случае DOM:

payment = message.getRootElement()


Вот дальше самое интересное, что ты не дописал, допиши если всё ещё считаешь, что будет просто.
function makePayment(clientId, amount, cardNo);
function checkCard(cardType, cardNo, cardVCode);
....
if(checkCard(payment.getAttribute("ptype"), payment.getAttribute("ccno"), payment.getAttribute("vcode"))
{
   makePayment(payment.getAttribute("cientid"), payment.getAttribute("amount"), payment.getAttribute("ccno"))
}

А если заюзать какой-нибудь xml-object mapping, то будет вообще красота.

В случае SAX (скажем, что одним потоком можно обработать сколь угодно много запросов, которые не влезут в память) будет
чуть посложнее, конечно, но в случае поточной обработки твой подход будет гораздо сложнее.

> В то время, как для ХМЛ придется писать callback функции для SAX, долго

> разбирать структуру для DOM и т.п. Зачем? Если в нашем случае наш же
> собственный велосипед будет приспособлен именно для наших нужд и
> оптимизирован по самое нехочу?
Ну-ну.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[9]: Снова XML: Just Say No to XML
От: GlebZ Россия  
Дата: 29.09.06 11:57
Оценка:
Здравствуйте, eao197, Вы писали:

E>Глеб, извини, но ты мог бы уже так дословно к словам не цепляться.

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

E>Для ISO 8583, например, вот.

Это уже смешно:
http://jpos.org/products

ISO/Bridge — ISO-8583 Made Easy

But if you are not a Java shop, or even if you are, but you just want to focus on your business logic without having to deal with low level ISO-8583 communications details, then ISO/Bridge is probably an alternative you ought to evaluate.

You can think of ISO/Bridge as a blackbox that sits between your application and the ISO-8583 host(s). It uses an extremely easy to implement XML-based protocol that simplify the burden of dealing with ISO-8583 messages, bitmaps, channels, packagers, headers, multiplexers and the like.


E>Здесь я с тобой согласен. Но меня вообще интересует, чтоже это за платежная система, которая вместо стандартных (хоть и сложных, и дорогих) решений позволяет использовать собственные key=value.

Проблема в том, что стандартных решений очень мало. Пока нет единого, всеми выполняемого решения(неважно, основано оно на xml или нет) каждый делает так как ему хочется. Иногда неплохо получается, но иногда и фигня выходит. Кстати, я не знаток платежных систем, но вроде бы у нас стандартизовали клиент-банк на основе XML.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 29.09.06 12:03
Оценка:
eao197 wrote:

> kan>Если квалификация не позволяет написать вменяемый xml (тут

> <http://rsdn.ru/forum/?mid=2132881&gt;
Автор: dshe
Дата: 27.09.06
,

> Это первоапрельская шутка, в рассмотрение не берем.
В каждой шутке есть доля правды.

> kan>тут <http://rsdn.ru/forum/?mid=2133228&gt;
Автор: CrystaX
Дата: 27.09.06
), то какой же получится

> компилятор?
> А как вот этот, по-вашему, можно сделать вменяемым?
<elseif/> не отражает структуру документа. Можно хотя бы как <xsl:choose> сделать.
Ну и разобраться почему в @cond надо ставить javascript... может можно обойти это дело, что нибудь готовое заюзать,
xpath какой-нибудь.
Только не надо меня убеждать что
if(someting)
{
}

чем-то лучше чем
<if test="something">
</if>

При использовании любого вменяемого xml-редактора — разницы никакой (теги сами закрываются, так что </if> писать не
придётся, обязательные аттрибуты сами печатаются, так что "test=" тоже набирать не придётся).
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[10]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 29.09.06 12:04
Оценка:
>> Экономить всегда полезно.
kan>Это называется преждевременной оптимизацией.

Ну, я думаю, товарищи в payment gateway'e уже непреждевременной занимаются

>> Это кстати, косвенное отражение общей тенденции сегодняшних дней —

>> "пофиг, что много, мы его задавим объемами сетей/компов/памяти".
>> Экономить разучились совсем.
kan>Это дорого.

Это верно

>> Читаю наискосок описание. Гы. Как туториал по общению через сокеты читаю

>> Пошлите START
>> Пошлите информацию
>> Пошлите END
kan>Не знаю, вот лог миранды:
kan>

kan><message to="[censored]@gmail.com/MirandaE94EDA38" type="chat" id="A3E644D00EEBB7A04"
kan>from="[censored]@gmail.com/gmail.F7173C35"><body>тута юникод. тута юникод. тута юникод. тута
kan>юникод.</body> [skip]

kan>Не знаю что всё это означает, честно говоря.

Это как раз описание согласно RFC,

[skip]
>> Как это не надо писать? Даже если его и написали, то это написал кто-то,
>> доверия к кому может и не быть. И _в любом_ случае работа с ХМЛ никогда
>> не побьет по простоте вот это:

kan>
>> // псевдо код
>> MessageArray = split(message, "::");
>> KeyValueArray = split(MessageArray(1), ";");
>> for(...)
>> {
>>     KeyValuePair = split(KeyValueArray[i], '=');
>> }
>> 
>> // где split может быть невероятно шустрым
kan>

kan>А вот тоже самое, но для xml в случае DOM:

kan>
kan>payment = message.getRootElement()
kan>


kan>Вот дальше самое интересное, что ты не дописал, допиши если всё ещё считаешь, что будет просто.

kan>
kan>function makePayment(clientId, amount, cardNo);
kan>function checkCard(cardType, cardNo, cardVCode);
kan>....
kan>if(checkCard(payment.getAttribute("ptype"), payment.getAttribute("ccno"), payment.getAttribute("vcode"))
kan>{
kan>   makePayment(payment.getAttribute("cientid"), payment.getAttribute("amount"), payment.getAttribute("ccno"))
kan>}
kan>

kan>А если заюзать какой-нибудь xml-object mapping, то будет вообще красота.


У нас так же возможны ситуации, когда создание лишних объектов в памяти дорого.


kan>В случае SAX (скажем, что одним потоком можно обработать сколь угодно много запросов, которые не влезут в память) будет

kan>чуть посложнее, конечно, но в случае поточной обработки твой подход будет гораздо сложнее.

Тут надо смотреть на реальных примерах, но кто ж их даст?

>> В то время, как для ХМЛ придется писать callback функции для SAX, долго

>> разбирать структуру для DOM и т.п. Зачем? Если в нашем случае наш же
>> собственный велосипед будет приспособлен именно для наших нужд и
>> оптимизирован по самое нехочу?
kan>Ну-ну.

... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[10]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 29.09.06 12:04
Оценка:
M>> Экономить всегда полезно.
GZ>Вообще-то нормальные девелоперы, для того чтобы уменьшить трафик включают gzip, который собственно именно для этого и предназначен. А через LZW алгоритмы, xml скукоживается на порядки.

Ну, любой текст скукоживается
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[10]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.09.06 12:11
Оценка:
Здравствуйте, GlebZ, Вы писали:

E>>Для ISO 8583, например, вот.

GZ>Это уже смешно:
GZ>http://jpos.org/products
GZ>

GZ>ISO/Bridge — ISO-8583 Made Easy

GZ>But if you are not a Java shop, or even if you are, but you just want to focus on your business logic without having to deal with low level ISO-8583 communications details, then ISO/Bridge is probably an alternative you ought to evaluate.

GZ>You can think of ISO/Bridge as a blackbox that sits between your application and the ISO-8583 host(s). It uses an extremely easy to implement XML-based protocol that simplify the burden of dealing with ISO-8583 messages, bitmaps, channels, packagers, headers, multiplexers and the like.


Вообще-то говоря, вполне разумное решение. Получается возможность реализовывать клиентов на любом языке. Хоть на C#, хоть на Ruby, хоть на Perl. Вся работа с двоичными данными сосредоточена в java-вском коде.

Еще один пример: протоколы работы с MMS-ками реализованы на основе SOAP-а. Что позволяет реализовывать MMS-сервисы на чем хочешь -- хоть на C++, хоть на Java, хоть на Tcl. Хотя казалось бы, там overhead значительный должен выходить, ведь бинарные данные (картинки, звук) передаются в base64. И ничего, все замечаетльно пашет.

Это как раз примеры того, как XML используется по теме.

E>>Здесь я с тобой согласен. Но меня вообще интересует, чтоже это за платежная система, которая вместо стандартных (хоть и сложных, и дорогих) решений позволяет использовать собственные key=value.


GZ>Проблема в том, что стандартных решений очень мало. Пока нет единого, всеми выполняемого решения(неважно, основано оно на xml или нет) каждый делает так как ему хочется. Иногда неплохо получается, но иногда и фигня выходит. Кстати, я не знаток платежных систем, но вроде бы у нас стандартизовали клиент-банк на основе XML.


Так вот и я про то, что в данном случае речь идет о какой-то нестандартной платежной системе. В которой разработчики могут творить, что хотят. Но, опять же, не зная подробностей, не хочется утвержать, что они напрасно от XML отказались. Может они платежи с каких-нибудь аппаратов делают, встроенные системы разрабатывают, где ресурсы не позвляют XML парсинг делать.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.09.06 12:15
Оценка:
Здравствуйте, kan, Вы писали:

kan>Только не надо меня убеждать что

kan>
kan>if(someting)
kan>{
kan>}
kan>

kan>чем-то лучше чем
kan>
kan><if test="something">
kan></if>
kan>

kan>При использовании любого вменяемого xml-редактора — разницы никакой (теги сами закрываются, так что </if> писать не
kan>придётся, обязательные аттрибуты сами печатаются, так что "test=" тоже набирать не придётся).

А какая альтернатива в XML будет, например, у:
if something && ( something_else || ( first && second && third ) )
  ...bla-bla-bla...
elsif another || yet_another || or_yet_another
  ...bla-bla-bla...
else
  ...trundec...
end


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 29.09.06 12:26
Оценка:
Mamut wrote:


>> > Как это не надо писать? Даже если его и написали, то это написал кто-то,

>> > доверия к кому может и не быть. И _в любом_ случае работа с ХМЛ никогда
>> > не побьет по простоте вот это:
Побило как ребёнка.

> У нас так же возможны ситуации, когда создание лишних объектов в памяти

> дорого.
Ну не создавай. Кто ж заставляет?

> kan>В случае SAX (скажем, что одним потоком можно обработать сколь

> угодно много запросов, которые не влезут в память) будет
> kan>чуть посложнее, конечно, но в случае поточной обработки твой подход
> будет гораздо сложнее.
> Тут надо смотреть на реальных примерах, но кто ж их даст?
Ты хотя бы прикинь код на твоих любимых split-ах, который будет парсить поток строк <payment/>, что ты приводил, и,
скажем, вызывать checkCard/makePayment и записывать в выходной поток результат вроде
<result clientid="2ni3poicy5b8924v"/>
<result clientid="vqxernty853ty32q" error="1244">Мятые купюры не принимаем</result>

и сравни это с банальным SAX-фильтром.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[9]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 29.09.06 12:39
Оценка:
eao197 wrote:

> А какая альтернатива в XML будет, например, у:

>
> if something && ( something_else || ( first && second && third ) )
> ...bla-bla-bla...
> elsif another || yet_another || or_yet_another
> ...bla-bla-bla...
> else
> ...trundec...
> end
Если что-то типа подхода xslt (для условий используется xpath):
<choose>
   <when test="something and (something_else or (first and second and third))">
     ...bla-bla-bla...
   </when>
   <when test="another or yet_another or or_yet_another">
     ...bla-bla-bla...
   </when>
   <otherwise>
     ...trundec...
   </otherwise>
</choose>

Хотя в условиях и javascript можно использовать. Испольозование xml не запрещает использовать другие языки. Вон, в
html/svg javascript тоже активно юзается, никто не жалуется.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[12]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 29.09.06 12:47
Оценка:
>>> > Как это не надо писать? Даже если его и написали, то это написал кто-то,
>>> > доверия к кому может и не быть. И _в любом_ случае работа с ХМЛ никогда
>>> > не побьет по простоте вот это:
kan>Побило как ребёнка.

Только при условии создания DOM-объекта

>> У нас так же возможны ситуации, когда создание лишних объектов в памяти

>> дорого.
kan>Ну не создавай. Кто ж заставляет?

Тогда не получится легкости типа payment = message.getRootElement()

>> kan>В случае SAX (скажем, что одним потоком можно обработать сколь

>> угодно много запросов, которые не влезут в память) будет
>> kan>чуть посложнее, конечно, но в случае поточной обработки твой подход
>> будет гораздо сложнее.
>> Тут надо смотреть на реальных примерах, но кто ж их даст?
kan>Ты хотя бы прикинь код на твоих любимых split-ах, который будет парсить поток строк <payment/>, что ты приводил, и,
kan>скажем, вызывать checkCard/makePayment и записывать в выходной поток результат вроде
kan>
kan><result clientid="2ni3poicy5b8924v"/>
kan><result clientid="vqxernty853ty32q" error="1244">Мятые купюры не принимаем</result>
kan>

kan>и сравни это с банальным SAX-фильтром.

Ну, возвращать-то он тоже будет пары key-value, то есть что-то типа response::key=value;;

Правда, оказалось, что я все же был неправ и тот gateway работает по-другому
Автор: Mamut
Дата: 29.09.06
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[10]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.09.06 12:52
Оценка:
Здравствуйте, kan, Вы писали:

kan>Если что-то типа подхода xslt (для условий используется xpath):

kan>
kan><choose>
kan>   <when test="something and (something_else or (first and second and third))">
kan>     ...bla-bla-bla...
kan>   </when>
kan>   <when test="another or yet_another or or_yet_another">
kan>     ...bla-bla-bla...
kan>   </when>
kan>   <otherwise>
kan>     ...trundec...
kan>   </otherwise>
kan></choose>
kan>

kan>Хотя в условиях и javascript можно использовать. Испольозование xml не запрещает использовать другие языки. Вон, в
kan>html/svg javascript тоже активно юзается, никто не жалуется.

А теперь представь, что у тебя 200-ти строк такого кода, в которых ты ищещь баг. Распечатываешь, чтобы прошерстить исходники в спокойной обстановке с карандашом в руках. Тебе будет удобно среди <тегов> суть выискивать?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Снова XML: Just Say No to XML
От: Turtle.BAZON.Group  
Дата: 29.09.06 12:56
Оценка:
Здравствуйте, ZevS, Вы писали:

TBG>>Хотелось бы послушать про преимущества ХыМыЛа для конечного пользователя продукта.


ZS>Пожалуйста:

ZS>
ZS>Можно продолжить.

Не сомневаюсь. Минусы мы опустим. Опять же зависит все от того, кто твой пользователь и что он будет делать. Думаю, при описании шаблона отчета в xml не каждый из пользователей решится это сделать сам. Потому что:


Даже конфигурационный файл оказывается проще что-то в стиле KEY=VALUE.
Я не за языки вместо ХМЛ — они тоже проблему не решат. Я за то, чтобы конечный пользователь владел все же мышой или чем-нибудь там и особо не напрягался, так как не любит.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 29.09.06 13:22
Оценка:
Mamut wrote:

> kan>Побило как ребёнка.

> Только при условии создания DOM-объекта
Ну да, что-то я не подумал, ведь MessageArray, KeyValueArray — в паралльельной вселенной создаются и места не занимают.

>> > У нас так же возможны ситуации, когда создание лишних объектов в памяти

>> > дорого.
> kan>Ну не создавай. Кто ж заставляет?
> Тогда не получится легкости типа payment = message.getRootElement()
Используй SAX.

> kan>и сравни это с банальным SAX-фильтром.

> Ну, возвращать-то он тоже будет пары key-value, то есть что-то типа
> response::key=value;;
Пусть так. Легче не станет.

> Правда, оказалось, что я все же был неправ и тот gateway работает

> по-другому <http://rsdn.ru/Forum/Message.aspx?mid=2137550&amp;only=1&gt;
Автор: Mamut
Дата: 29.09.06

Вот во что эта "простота" вылилась в итоге:
x_line_item=item1<|>golf balls<|><|>2<|>18.95<|>Y
x_line_item=item2<|>golf bag<|>Wilson golf carry bag, red<|>1<|>39.99<|>Y
x_line_item=item3<|>book<|>Golf for Dummies<|>1<|>21.99<|>Y

Ещё интересно узнать как оно дружит с русским.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[11]: Снова XML: Just Say No to XML
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.09.06 13:25
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Вот теперь следующая идея ждет своего воплощения: встраивать

>> Ruby-интерпритатор прямо в приложение, чтобы DSL им парсился и
>> информация из DSL непосредственно в приложение поступала.
C>А зачем?

Ну у меня в коде используется следующий подход: есть набор классов, объекты которых хранят конфигурационную информацию. Именно эти объекты используются в программе.
Есть так же процедуры, которые занимаются парсингом конфигурационных файлов и созданием вышеуказанных объектов. Как правило эти процедуры используют какую-либо библиотеку классов (для XML или моего формата). В случае использования моего формата, получается еще параллельная система классов-парсеров (в случае XML вместо них набор процедур, обрабатывающих DOM).
К этому еще добавляется набор Ruby-скриптов, которые из компактного DSL-я генерят пространные конфигурационные файлы.

Идея состоит в том, чтобы процедуры парсинга конфигов использовали сразу Ruby интерпритатор. А реализация DSL на Ruby могла формировать мои конфигурационные объекты в программе напрямую. Т.е., убрать промежуточные слои.

Но все это хорошо для случаев, когда приложение не должно сохранять конфигурацию обратно. Хотя, сейчас развитие проекта ParseTree обещает сделать возможным восстановление Ruby-кода.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 29.09.06 13:49
Оценка:
>> kan>Побило как ребёнка.
>> Только при условии создания DOM-объекта
kan>Ну да, что-то я не подумал, ведь MessageArray, KeyValueArray — в паралльельной вселенной создаются и места не занимают.

Нууу... Этааа...

Тут, правда, опять надо смотреть, что дешевле создать — объект или массив. Но это уже флуд на тему "а вот у нас в Forth под Берлином в сорок пятом..."

>>> > У нас так же возможны ситуации, когда создание лишних объектов в памяти

>>> > дорого.
>> kan>Ну не создавай. Кто ж заставляет?
>> Тогда не получится легкости типа payment = message.getRootElement()
kan>Используй SAX.

Не хочу Я просто callback функции не люблю Но тоже вариант

>> kan>и сравни это с банальным SAX-фильтром.

>> Ну, возвращать-то он тоже будет пары key-value, то есть что-то типа
>> response::key=value;;
kan>Пусть так. Легче не станет.

>> Правда, оказалось, что я все же был неправ и тот gateway работает

>> по-другому <http://rsdn.ru/Forum/Message.aspx?mid=2137550&amp;only=1&gt;
Автор: Mamut
Дата: 29.09.06

kan>Вот во что эта "простота" вылилась в итоге:
kan>
kan>x_line_item=item1<|>golf balls<|><|>2<|>18.95<|>Y
kan>x_line_item=item2<|>golf bag<|>Wilson golf carry bag, red<|>1<|>39.99<|>Y
kan>x_line_item=item3<|>book<|>Golf for Dummies<|>1<|>21.99<|>Y
kan>

kan>Ещё интересно узнать как оно дружит с русским.

Вот это я уже сказать не могу Бо до работы с ними (пока?) не дошло.
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[10]: Снова XML: Just Say No to XML
От: Turtle.BAZON.Group  
Дата: 29.09.06 14:31
Оценка:
Здравствуйте, ZevS, Вы писали:

TBG>>Для дотошного пользователя, может быть.

ZS>>>[/list]
ZS>Извините, но это демагогия.
Да тут вся ветка демагогия, так что не обращайте внимания.

TBG>>Даже конфигурационный файл оказывается проще что-то в стиле KEY=VALUE.

TBG>>Я не за языки вместо ХМЛ — они тоже проблему не решат. Я за то, чтобы конечный пользователь владел все же мышой или чем-нибудь там и особо не напрягался, так как не любит.
ZS>Правда? А если конфигурация — это не пара значений, а сложная иерархическая структура?

Если, если... Вот если, тогда и KEYPARENT.KEYCHILD=VALUE тоже сойдет. Но это смотреть надо будет что проще. А вот для пары значений ХыМыЛ точно ни к чему? Или вы со мной не согласитесь?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: Снова XML: Just Say No to XML
От: Cyberax Марс  
Дата: 29.09.06 14:46
Оценка:
eao197 wrote:
> Ну у меня в коде используется следующий подход: есть набор классов,
> объекты которых хранят конфигурационную информацию. Именно эти объекты
> используются в программе.
В Java я для этого использую XMLBeans. По XSD-схеме создается дерево
классов, которые можно загружать и сохранять в XML.

Причем этот XML можно обрабатывать хоть чем, подписывать его и т.п.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[11]: Снова XML: Just Say No to XML
От: kan Великобритания  
Дата: 29.09.06 15:26
Оценка:
Turtle.BAZON.Group wrote:

> ZS>Правда? А если конфигурация — это не пара значений, а сложная

> иерархическая структура?
>
> Если, если... Вот если, тогда и KEYPARENT.KEYCHILD=VALUE тоже сойдет. Но
> это смотреть надо будет что проще. А вот для пары значений ХыМыЛ точно
> ни к чему? Или вы со мной не согласитесь?
Может быть, в каких-нибудь ситуациях... Но обычно в итоге получается сложнее, чем <br />
XML
Автор: kan
Дата: 29.09.06
.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[11]: Снова XML: Just Say No to XML
От: fmiracle  
Дата: 29.09.06 15:35
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>> Экономить всегда полезно.

GZ>>Вообще-то нормальные девелоперы, для того чтобы уменьшить трафик включают gzip, который собственно именно для этого и предназначен. А через LZW алгоритмы, xml скукоживается на порядки.

M>Ну, любой текст скукоживается


"Все люди равны, но некоторые равнее." (с)

Просто архивация как раз эффективно решеает проблему избыточности xml — много повторений, которые хорошо запакуются.
Таким образом если некие развернутые xml и csv соотносятся размером как 2/1, то в сжатом виде они будут уже гораздо-гораздо ближе друг к другу.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Насчет синтаксиса
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.09.06 17:44
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>Ну, XML явно не серебрянная пуля. Это, как минимум золотая гиря.


Дайте две! Нет, три!!!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Насчет синтаксиса
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.09.06 17:44
Оценка:
Здравствуйте, kan, Вы писали:

kan>Ээ... Тег это синтаксическая единица. А вот тег "html" это уже семантическая,


Учи матчасть. html это и синтаксическое, и семантическое расширение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Снова XML: Just Say No to XML
От: c-smile Канада http://terrainformatica.com
Дата: 29.09.06 20:57
Оценка:
Здравствуйте, kan, Вы писали:
>> дошло даже до того, что, например, в Scala XML может включаться
>> непосредственно в текст программы.
kan>Кстати, в Firefox 1.5 уже можно в Javascript (ECMAScript) <br />
<span class='lineQuote level1'>kan&gt;включать</span>
.


Это затмение на людей нашло. Не развивается это дело больше никак.
Re[2]: Gateway
От: Mamut Швеция http://dmitriid.com
Дата: 30.09.06 07:22
Оценка:
M>>И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву.

ie>Довелось работать с 3мя платежками: Verisign, YourPay и Authorize.net. Так вот скажу, что Authorize.net как раз таки самая неудобная из этих 3-х.


А что в Verisign и Yourpay испольщуется? Таки ХМЛ?
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re: Снова XML: Just Say No to XML
От: Курилка Россия http://kirya.narod.ru/
Дата: 30.09.06 08:38
Оценка:
Здравствуйте, eao197, Вы писали:

E>Мнение Алана Голуба: Just Say No to XML


Замечание несколько очень в сторону, но вот ещё одна альтернатива — CurlyML, очень похожая на JSON, но тоже лишь язык разметки
Re[4]: Ну дык...
От: Andir Россия
Дата: 30.09.06 09:01
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>(я использую т.н. JSON+ формат)


Это в нём получается отказались от кавычек для имён полей? Дай ссылочку на описание, пожалуйста?

C Уважением, Andir!
using( RSDN@Home 1.2.0 alpha rev. 652 ) { /* Работаем */ }
Re[8]: Снова XML: Just Say No to XML
От: Andir Россия
Дата: 30.09.06 10:24
Оценка:
Здравствуйте, kan, Вы писали:

kan>При использовании любого вменяемого xml-редактора — разницы никакой (теги сами закрываются, так что </if> писать не

kan>придётся, обязательные аттрибуты сами печатаются, так что "test=" тоже набирать не придётся).

[offtop]
А не подскажешь пару-тройку таких вменяемых редакторов? Чем легче, тем лучше.
[/offtop]

С Уважением, Andir!
using( RSDN@Home 1.2.0 alpha rev. 652 ) { /* Работаем */ }
Re[9]: Снова XML: Just Say No to XML
От: Mamut Швеция http://dmitriid.com
Дата: 30.09.06 10:40
Оценка:
kan>>При использовании любого вменяемого xml-редактора — разницы никакой (теги сами закрываются, так что </if> писать не
kan>>придётся, обязательные аттрибуты сами печатаются, так что "test=" тоже набирать не придётся).

A>[offtop]

A>А не подскажешь пару-тройку таких вменяемых редакторов? Чем легче, тем лучше.
A>[/offtop]

A>С Уважением, Andir!


XML Spy Suite один из, если не наиболее вменяемый
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
Re[10]: Снова XML: Just Say No to XML
От: Andir Россия
Дата: 30.09.06 10:46
Оценка:
Здравствуйте, Mamut, Вы писали:

M>XML Spy Suite один из, если не наиболее вменяемый


Тяжёлый он больно, как и впрочем Stylus XML Studio.
Мне бы что-нить лёгкое с посветкой и поддержкой XSD ака валидация, автодополнение, автогенерация. Остальные навороты практически не нужны (хотя от некого подобия рефакторинга не отказался бы).

C Уважением, Andir!
using( RSDN@Home 1.2.0 alpha rev. 652 ) { /* Работаем */ }
Re[5]: Ну дык...
От: c-smile Канада http://terrainformatica.com
Дата: 30.09.06 18:36
Оценка:
Здравствуйте, Andir, Вы писали:

A>Здравствуйте, c-smile, Вы писали:


CS>>(я использую т.н. JSON+ формат)


A>Это в нём получается отказались от кавычек для имён полей? Дай ссылочку на описание, пожалуйста?


Это обычная нотация полного JavaScript.

Абсолютно ничего не мешает доточить парсер чтобы он принимал не только string здесь:

но и еще NMTOKEN (или nchars — кто как называет).

Там делов но минут 30.

Мы используем имя JSON+ у себя внутри т.к. пользуем полный парсер tiscript'а.
Re[6]: Снова XML: Just Say No to XML
От: c-smile Канада http://terrainformatica.com
Дата: 01.10.06 00:32
Оценка:
Здравствуйте, Andir, Вы писали:

A>Здравствуйте, c-smile, Вы писали:


CS>>Это затмение на людей нашло. Не развивается это дело больше никак.


A>Смотрел уже Javascript 1.7 ?


(Интересно а куда делась версия 1.6?)

С JavaScript вообще ситуация странная. JavaScript v.2.0 имплементриован только в .NET.
И похоже больше никто на его имплементацию за пять лет не сподобился. Неуловимый Джо?

А 1.7...

Ну в общем синтаксический сахар от Ruby (yield, generators/continuations) давно напрашивался.
Но все эти фичи и сейчас доступны в JS. (В любом языке имеющем closures можно исполнить continuation "руками".)
Поэтому в общем-то сильно оно не зажигает (лично меня во всяком случае). Будут востребованы эти фичи народом — сделаю их в tiscript.

Добавлять же в ту паукообразную обезьяну (SpiderMonkey) еще чего либо вообще смысла нет. И так не блещет скоростью то.
Re[2]: Снова XML: Just Say No to XML
От: c-smile Канада http://terrainformatica.com
Дата: 01.10.06 00:40
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, eao197, Вы писали:


E>>Мнение Алана Голуба: Just Say No to XML


К>Замечание несколько очень в сторону, но вот ещё одна альтернатива — CurlyML, очень похожая на JSON, но тоже лишь язык разметки


Тоже вот несколько в сторону:
Это вот фрагмент разметки и ЯП curl ( www.curl.com )

{curl 5.0 applet}
{applet manifest = "manifest.mcurl"}

{import * from COM.CURL.CSK.EXTRAS.CHINESE-CHECKERS}

{let graphic:Graphic = 
    {VBox
        background="#FFFFCC",
        halign="center",
        spacing=15pt,
        border-width=10pt,
        {center
            {title color="purple", Chinese Checkers}
        },
        {value display-box}
    }
}

{value graphic}
Re[7]: Снова XML: Just Say No to XML
От: Andir Россия
Дата: 01.10.06 03:58
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>(Интересно а куда делась версия 1.6?)


Да там же, Javascript 1.6 — это реализовано в Firefox 1.5, и это там реализована поддержка E4X ака EcmaScript for XML о котором упомянули ранее.

CS>С JavaScript вообще ситуация странная. JavaScript v.2.0 имплементриован только в .NET.

CS>И похоже больше никто на его имплементацию за пять лет не сподобился. Неуловимый Джо?

Вроде в репозитории мозиллы лежит какая-то реализация, но я никак не сподоблюсь глянуть на что она похожа

С Уважением, Andir!
using( RSDN@Home 1.2.0 alpha rev. 652 ) { /* Работаем */ }
Re[4]: Снова XML: Just Say No to XML
От: GlebZ Россия  
Дата: 01.10.06 12:21
Оценка:
Здравствуйте, kan, Вы писали:

kan>Кстати, в Firefox 1.5 уже можно в Javascript (ECMAScript) <br />
<span class='lineQuote level1'>kan&gt;включать</span>
.

А еще это можно делать в следующем языке:
[code]
define function factorial($num as xs:integer) as xs:integer
{
if ($num = 1) return 1
else
return $num * factorial($num — 1)
}
return <factorial>{factorial(10)}</factorial>
[code]
не уверен полностью в синтаксисе, но примерно так. И угадай кто придумал и развивает этот язык?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[12]: Снова XML: Just Say No to XML
От: Turtle.BAZON.Group  
Дата: 02.10.06 04:45
Оценка:
Здравствуйте, kan, Вы писали:

>> Если, если... Вот если, тогда и KEYPARENT.KEYCHILD=VALUE тоже сойдет. Но

>> это смотреть надо будет что проще. А вот для пары значений ХыМыЛ точно
>> ни к чему? Или вы со мной не согласитесь?
kan>Может быть, в каких-нибудь ситуациях... Но обычно в итоге получается сложнее, чем <br />
<span class='lineQuote level1'>kan&gt;XML</span>
Автор: kan
Дата: 29.09.06
.


Главное ведь все таки уметь разглядеть ситуацию.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Снова XML: Just Say No to XML
От: Turtle.BAZON.Group  
Дата: 02.10.06 04:45
Оценка:
Здравствуйте, Andir, Вы писали:

A>Тяжёлый он больно, как и впрочем Stylus XML Studio.

A>Мне бы что-нить лёгкое с посветкой и поддержкой XSD ака валидация, автодополнение, автогенерация. Остальные навороты практически не нужны (хотя от некого подобия рефакторинга не отказался бы).

Oxyegen. Или тоже тяжелый окажется?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Снова XML: Just Say No to XML
От: ArhAngelVezel Россия  
Дата: 02.10.06 12:38
Оценка:
Здравствуйте, Odi$$ey, Вы писали:

ZS>>Так что же теперь, для всех задачь придумывать свой язык?


OE>Языково-ориентированное программирование: следующая парадигма
Автор(ы): Сергей Дмитриев
Дата: 02.03.2006
Пришло время следующей технологической революции в разработке софта – и становится все очевиднее, какой она должна быть. Новая парадигма программирования – вот она, перед нами. Она еще не вполне сформировалась – разные части известны под разными именами вроде Intentional Programming, MDA, порождающее программирование и т.д. Я предлагаю объединение этих новаторских подходов под общим именем «языково-ориентированного программирования»; данная статья объясняет основные принципы новой парадигмы.


Один из основных пунктов парадигмы: узкоспециализированный редактор. Притом DSL может вообще не быть plain-text (посмотри хотя-бы microsoft реализацию), главное чтобы его редактировать можно было удобно при помощи редактора.
Пользователю (прикладному программисту) глубоко наплевать в каком формате сохраняется его работа. Главное что бы было удобно и легко без редактора:
1) Хранить
2) Проводить тесты на валидность
3) Проводить batch-компиляцию
4) Была модульность системы
5) Смотреть историю модуля
6+) и в таком духе
Как видно все эти пункты просто решаются с использованием текстовых форматов. А какой формат выберет системный программист — дело вкуса и возможности "системного" языка хранить в нем объекты.
Т.ч. в данном случае XML не упускает своего шанса (C#, Java итд).
Re[10]: Снова XML: Just Say No to XML
От: rasmus_aagensson  
Дата: 19.11.06 15:07
Оценка:
E>А это лучше заменить на:
E>
E>html {
E>  head {
E>    title 'Hi'
E>  }
E>  body {
E>    p {
E>      'Hello, world!'
E>    }
E>  }
E>}
E>


Выкиньте этот велик, всё придумано ещё в 60-х годах.

(html
  (head
    (title "Hi")
    (body
      (p "Hello, World"))))
Re[2]: Снова XML: Just Say No to XML
От: МихаилС Россия  
Дата: 21.11.06 07:42
Оценка:
Здравствуйте, vvaizh, Вы писали:

V>Алану Голубу бы стоило помолчать


+1

V> переводить код в "удобочитаемый" и "краткий" язык стоит только

V> тогда когда устоялась структура..

и тем самым "зацементировать" эту его структуру "навечно",
а потом лепить к ней заплатки и разные приблуды с умными
названиями с тем, чтобы добавить что-то новое.
Re[2]: Снова XML: Just Say No to XML
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 23.11.06 22:07
Оценка:
Здравствуйте, vvaizh, Вы писали:

V>Алану Голубу бы стоило помолчать

V>именно его поколение программистов не оставило после себя удобоваримого набора инструментов для написания компиляторов!
V>xml по сравнению с каким нибудь yacc — это как манна небесная по сравнению с кактусом!

Особенно интересно смотреть на такие "сравнения" понимая что сравниваются совершенно разнородные сущности.

А какой инструмент для написания _компиляторов_ Вы хотели видеть вместо... мнэээ... yacc? И как он заменит, например, кодогенерацию?:)))
The God is real, unless declared integer.
Re[3]: Снова XML: Just Say No to XML
От: vvaizh http://izh-test.sourceforge.net/
Дата: 24.11.06 04:09
Оценка:
Здравствуйте, netch80, Вы писали:

V>>Алану Голубу бы стоило помолчать

V>>именно его поколение программистов не оставило после себя удобоваримого набора инструментов для написания компиляторов!
V>>xml по сравнению с каким нибудь yacc — это как манна небесная по сравнению с кактусом!

N>Особенно интересно смотреть на такие "сравнения" понимая что сравниваются совершенно разнородные сущности.


N>А какой инструмент для написания _компиляторов_ Вы хотели видеть вместо... мнэээ... yacc?


например pccts (http://www.cs.rhul.ac.uk/research/languages/links.html)
избавлен от многих детских болезней yacc-а

N>И как он заменит, например, кодогенерацию?


ну вообще то пользователи XML как то обходят это место..
большинство используют DOM-модель..
так и тут могли бы использовать доведённые до ума AST (abstract syntax tree)

речь ведь не об оптимальности кода.. а о краткости и наглядности синтаксиса..
http://izh-test.sourceforge.net/russian/introduction.html
Re[4]: Снова XML: Just Say No to XML
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 24.11.06 06:50
Оценка:
Здравствуйте, vvaizh, Вы писали:

V>Здравствуйте, netch80, Вы писали:


V>>>Алану Голубу бы стоило помолчать

V>>>именно его поколение программистов не оставило после себя удобоваримого набора инструментов для написания компиляторов!
V>>>xml по сравнению с каким нибудь yacc — это как манна небесная по сравнению с кактусом!
N>>Особенно интересно смотреть на такие "сравнения" понимая что сравниваются совершенно разнородные сущности.
N>>А какой инструмент для написания _компиляторов_ Вы хотели видеть вместо... мнэээ... yacc?
V>например pccts (http://www.cs.rhul.ac.uk/research/languages/links.html)
V>избавлен от многих детских болезней yacc-а

И каким образом это объясняет Ваши тезисы? Да, pccts появился позднее. Но:
— не так страшен yacc, как его малюют:) GCC, например, сидит на yacc (в виде bison). Perl — на yacc. Видимо, он их удовлетворяет?
— чтобы понять, как делать лучше, надо было наработать опыт использования. Как этот опыт можно было получить без такого средства как yacc?
— и снова: при чём тут XML? Его средства заменят полноценный синтаксический разбор? Причём уровня как минимум pccts (иначе бы не нужно было это писать)? Просто потребовать баланса тегов разных уровней и соответствия заранее заданной иерархии — это даже не уровень yacc, это ниже. yacc хоть даёт возможность иногда пробиваться через нарушенный синтаксис.

N>>И как он заменит, например, кодогенерацию?:)))

V>ну вообще то пользователи XML как то обходят это место..
V>большинство используют DOM-модель..
V>так и тут могли бы использовать доведённые до ума AST (abstract syntax tree)
V>речь ведь не об оптимальности кода.. а о краткости и наглядности синтаксиса..

Я не думаю, что <expr><sum><item>1</item><item>2</item></sum></expr> нагляднее, чем 1+2. Попробуйте переубедить:)
The God is real, unless declared integer.
Re[5]: Снова XML: Just Say No to XML
От: vvaizh http://izh-test.sourceforge.net/
Дата: 24.11.06 07:00
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, vvaizh, Вы писали:


V>>>>Алану Голубу бы стоило помолчать

V>>>>именно его поколение программистов не оставило после себя удобоваримого набора инструментов для написания компиляторов!
V>>>>xml по сравнению с каким нибудь yacc — это как манна небесная по сравнению с кактусом!
N>>>Особенно интересно смотреть на такие "сравнения" понимая что сравниваются совершенно разнородные сущности.
N>>>А какой инструмент для написания _компиляторов_ Вы хотели видеть вместо... мнэээ... yacc?
V>>например pccts (http://www.cs.rhul.ac.uk/research/languages/links.html)
V>>избавлен от многих детских болезней yacc-а

N>И каким образом это объясняет Ваши тезисы? Да, pccts появился позднее. Но:

N>- не так страшен yacc, как его малюют GCC, например, сидит на yacc (в виде bison). Perl — на yacc. Видимо, он их удовлетворяет?

не удовлетворяет
я говорю то что знаю
работал в разработке продукта, также на yacc..
знаю этот гемор изнутри и то что о нём думают разработчики

N>- чтобы понять, как делать лучше, надо было наработать опыт использования. Как этот опыт можно было получить без такого средства как yacc?


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

N>- и снова: при чём тут XML? Его средства заменят полноценный синтаксический разбор? Причём уровня как минимум pccts (иначе бы не нужно было это писать)? Просто потребовать баланса тегов разных уровней и соответствия заранее заданной иерархии — это даже не уровень yacc, это ниже. yacc хоть даёт возможность иногда пробиваться через нарушенный синтаксис.


средства XML позволяют гибко, просто и без геморроя менять язык
этого оказалось достаточно

N>>>И как он заменит, например, кодогенерацию?

V>>ну вообще то пользователи XML как то обходят это место..
V>>большинство используют DOM-модель..
V>>так и тут могли бы использовать доведённые до ума AST (abstract syntax tree)
V>>речь ведь не об оптимальности кода.. а о краткости и наглядности синтаксиса..

N>Я не думаю, что <expr><sum><item>1</item><item>2</item></sum></expr> нагляднее, чем 1+2. Попробуйте переубедить


видите ли, в большинстве критикуемых применений XML (nant, wix и т.п.)
такие выражения практически не используются, а там где используются используется обычный синтаксис, не XML

так что мимо кассы

с вашим примером вам нужно критиковать какой нибудь MathML да и то попробуйте в ваш синтаксис (1+2) ввести интегралы кванторы и прочую мат-обыденность и вам сразу поплохеет и захочется полноценного XML-я
http://izh-test.sourceforge.net/russian/introduction.html
Re[6]: Снова XML: Just Say No to XML
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 24.11.06 07:18
Оценка:
Здравствуйте, vvaizh, Вы писали:

N>>И каким образом это объясняет Ваши тезисы? Да, pccts появился позднее. Но:

N>>- не так страшен yacc, как его малюют:) GCC, например, сидит на yacc (в виде bison). Perl — на yacc. Видимо, он их удовлетворяет?
V>не удовлетворяет
V>я говорю то что знаю

Ага — значит, Вы знаете что думает народ пишущий GCC и Perl? Тогда почему они используют yacc?

V>работал в разработке продукта, также на yacc..

V>знаю этот гемор изнутри и то что о нём думают разработчики

Разработчики бывают разные. Думать они могут о разном. Например, о бабах:) Вы хотите сказать, что yacc прост и прямолинеен настолько, что примитивен? Я согласен. Что он "гемор"? Не вижу оснований. У него есть своя ниша — разбор конфигов и простых языков — и он её отлично закрывает. Причём в отличие от многих XML'евых парсеров (контекст не потеряли?) у него валидатор синтаксиса встроенный, а не стоящий где-то сбоку припёка отдельным средством.

Или в чём ещё проблема yacc?

N>>- чтобы понять, как делать лучше, надо было наработать опыт использования. Как этот опыт можно было получить без такого средства как yacc?

V>мне не интересно как этот опыт можно было получить
V>мне более интересно что ко времени массовой потребности хорошего механизма не появилось.

Ну так сформулируйте конкретно и детально (а то я тут из Вас каждое слово клещами тяну) что именно Вы вкладываете в понятие "хорошего" механизма, тогда можно будет рассмотреть, почему такого не было (уточняя: в публичном доступе).

N>>- и снова: при чём тут XML? Его средства заменят полноценный синтаксический разбор? Причём уровня как минимум pccts (иначе бы не нужно было это писать)? Просто потребовать баланса тегов разных уровней и соответствия заранее заданной иерархии — это даже не уровень yacc, это ниже. yacc хоть даёт возможность иногда пробиваться через нарушенный синтаксис.

V>средства XML позволяют гибко, просто и без геморроя менять язык
V>этого оказалось достаточно

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

N>>Я не думаю, что <expr><sum><item>1</item><item>2</item></sum></expr> нагляднее, чем 1+2. Попробуйте переубедить:)

V>видите ли, в большинстве критикуемых применений XML (nant, wix и т.п.)
V>такие выражения практически не используются, а там где используются используется обычный синтаксис, не XML
V>так что мимо кассы

Не "мимо кассы", а Вы хотите и крестик оставить, и трусы снять:) Вы ж наехали на "поколение Голуба" за недостаток средств, а взамен в качестве альтернативы предложили XML. Их (того поколения) средства справляются с синтаксисом вида 1+2 беспроблемно и не требуется XML'ное обрамление. А у Вас будет двуслойность — и одни средства, и другие? И что это даст тем применениям, где обычно используется тот же yacc?

V>с вашим примером вам нужно критиковать какой нибудь MathML да и то попробуйте в ваш синтаксис (1+2) ввести интегралы кванторы и прочую мат-обыденность и вам сразу поплохеет и захочется полноценного XML-я


Я там лучше TeX'овский стиль синтаксиса применю.
The God is real, unless declared integer.
Re[7]: Снова XML: Just Say No to XML
От: vvaizh http://izh-test.sourceforge.net/
Дата: 24.11.06 07:33
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, vvaizh, Вы писали:


N>>>И каким образом это объясняет Ваши тезисы? Да, pccts появился позднее. Но:

N>>>- не так страшен yacc, как его малюют GCC, например, сидит на yacc (в виде bison). Perl — на yacc. Видимо, он их удовлетворяет?
V>>не удовлетворяет
V>>я говорю то что знаю

N>Ага — значит, Вы знаете что думает народ пишущий GCC и Perl? Тогда почему они используют yacc?


они думают "ну и угрёбище", но переписывать кучу существующего кода тяжело.. хотя и пытаются
тот же pccts — я не зря упомянул, именно он рассматривался как замена

V>>работал в разработке продукта, также на yacc..

V>>знаю этот гемор изнутри и то что о нём думают разработчики

N>Разработчики бывают разные.


это была мысль CTO и более того на работу по переходу на pccts было затрачено при мне не менее человеко/месяца

N>Думать они могут о разном. Например, о бабах Вы хотите сказать, что yacc прост и прямолинеен настолько, что примитивен? Я согласен. Что он "гемор"? Не вижу оснований. У него есть своя ниша — разбор конфигов и простых языков — и он её отлично закрывает. Причём в отличие от многих XML'евых парсеров (контекст не потеряли?) у него валидатор синтаксиса встроенный, а не стоящий где-то сбоку припёка отдельным средством.


в отличие от того же XML, ошибку в синтаксисе которого показывает банально любой броузер а новые языковые конструкции не вводят предыдущие версии в ступор (не нужен никакой препроцессор чтобы пропускать новые конструкции)

yacc не позволяет выдавать нормальные сообщения об ошибках
и на больших грамматиках добавлять чего то и отслеживать
непротиворечивость (а там постоянон растёт количество варнингов)
очень тяжело

N>Или в чём ещё проблема yacc?


отсутствие модульности, объектности, нормальных сообщений об ошибках, да куча всего, почитайте про pccts, там многое перечислено

N>>>- чтобы понять, как делать лучше, надо было наработать опыт использования. Как этот опыт можно было получить без такого средства как yacc?

V>>мне не интересно как этот опыт можно было получить
V>>мне более интересно что ко времени массовой потребности хорошего механизма не появилось.

N>Ну так сформулируйте конкретно и детально (а то я тут из Вас каждое слово клещами тяну) что именно Вы вкладываете в понятие "хорошего" механизма, тогда можно будет рассмотреть, почему такого не было (уточняя: в публичном доступе).


а зачем?
разработчики уже сделали свой выбор
обосновывать его не вижу смысла
таково сложившееся положение вещей

N>>>- и снова: при чём тут XML? Его средства заменят полноценный синтаксический разбор? Причём уровня как минимум pccts (иначе бы не нужно было это писать)? Просто потребовать баланса тегов разных уровней и соответствия заранее заданной иерархии — это даже не уровень yacc, это ниже. yacc хоть даёт возможность иногда пробиваться через нарушенный синтаксис.

V>>средства XML позволяют гибко, просто и без геморроя менять язык
V>>этого оказалось достаточно

N>Средство "последовательность байт" позволяют гибко, просто и без геморроя менять язык. При этом их возможности значительно шире чем у XML — можно применять и бинарные форматы, и другие варианты форматов с самотерминацией лексем (что резко упрощает парсеры), и при этом оно в разы экономнее XML. Давайте его использовать, зачем нам эти костыли?


угу..
вот только при этом изменении языка старые данные читаться не будут

N>>>Я не думаю, что <expr><sum><item>1</item><item>2</item></sum></expr> нагляднее, чем 1+2. Попробуйте переубедить

V>>видите ли, в большинстве критикуемых применений XML (nant, wix и т.п.)
V>>такие выражения практически не используются, а там где используются используется обычный синтаксис, не XML
V>>так что мимо кассы

N>Не "мимо кассы", а Вы хотите и крестик оставить, и трусы снять Вы ж наехали на "поколение Голуба" за недостаток средств, а взамен в качестве альтернативы предложили XML. Их (того поколения) средства справляются с синтаксисом вида 1+2 беспроблемно и не требуется XML'ное обрамление. А у Вас будет двуслойность — и одни средства, и другие? И что это даст тем применениям, где обычно используется тот же yacc?


простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc
если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить

V>>с вашим примером вам нужно критиковать какой нибудь MathML да и то попробуйте в ваш синтаксис (1+2) ввести интегралы кванторы и прочую мат-обыденность и вам сразу поплохеет и захочется полноценного XML-я


N>Я там лучше TeX'овский стиль синтаксиса применю.


который никто кроме теха не поймёт
так что даже чтобы примитивный конвертор написать придётся попотеть
http://izh-test.sourceforge.net/russian/introduction.html
Re[8]: Снова XML: Just Say No to XML
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 24.11.06 08:11
Оценка:
Здравствуйте, vvaizh, Вы писали:

N>>Ага — значит, Вы знаете что думает народ пишущий GCC и Perl? Тогда почему они используют yacc?

V>они думают "ну и угрёбище", но переписывать кучу существующего кода тяжело.. хотя и пытаются
Интересный вывод:)

V>в отличие от того же XML, ошибку в синтаксисе которого показывает банально любой броузер а новые языковые конструкции не вводят предыдущие версии в ступор (не нужен никакой препроцессор чтобы пропускать новые конструкции)


Так называемый "синтаксис" XML, который способен показывать браузер, для других средств (не-XML'ных) аналогичен уровню деления битового потока на байты. И даже баланс тегов — это не синтаксис. Синтаксис — это то, что не может быть например быть while внутри выражения (expression). Это Вам покажет "любой браузер"? Это уже весьма высокий уровень полёта, и далеко не любой браузер способен на такое.

V>yacc не позволяет выдавать нормальные сообщения об ошибках


Нормальные чему?

V>и на больших грамматиках добавлять чего то и отслеживать

V>непротиворечивость (а там постоянон растёт количество варнингов)

shift/reduce? Несерьёзно, они по жизни конфликтуют:)

V>очень тяжело


Очень конкретно:))

N>>Ну так сформулируйте конкретно и детально (а то я тут из Вас каждое слово клещами тяну) что именно Вы вкладываете в понятие "хорошего" механизма, тогда можно будет рассмотреть, почему такого не было (уточняя: в публичном доступе).

V>а зачем?
V>разработчики уже сделали свой выбор
V>обосновывать его не вижу смысла
V>таково сложившееся положение вещей

Другим объясните, чтобы по тем же граблям не ходить.

N>>Средство "последовательность байт" позволяют гибко, просто и без геморроя менять язык. При этом их возможности значительно шире чем у XML — можно применять и бинарные форматы, и другие варианты форматов с самотерминацией лексем (что резко упрощает парсеры), и при этом оно в разы экономнее XML. Давайте его использовать, зачем нам эти костыли?

V>угу..
V>вот только при этом изменении языка старые данные читаться не будут

Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут.

А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам?

N>>Не "мимо кассы", а Вы хотите и крестик оставить, и трусы снять:) Вы ж наехали на "поколение Голуба" за недостаток средств, а взамен в качестве альтернативы предложили XML. Их (того поколения) средства справляются с синтаксисом вида 1+2 беспроблемно и не требуется XML'ное обрамление. А у Вас будет двуслойность — и одни средства, и другие? И что это даст тем применениям, где обычно используется тот же yacc?

V>простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc
V>если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить

Это Ваши домыслы. Я бы на Вас посмотрел что бы Вы сделали на машине слабее PC XT и стоимостью как "Мерседес" и отдали бы при этом в open source (которое тогда только-только начиналось).

N>>Я там лучше TeX'овский стиль синтаксиса применю.

V>который никто кроме теха не поймёт
V>так что даже чтобы примитивный конвертор написать придётся попотеть

да ну.
The God is real, unless declared integer.
Re[9]: Снова XML: Just Say No to XML
От: vvaizh http://izh-test.sourceforge.net/
Дата: 24.11.06 08:24
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, vvaizh, Вы писали:


N>>>Ага — значит, Вы знаете что думает народ пишущий GCC и Perl? Тогда почему они используют yacc?

V>>они думают "ну и угрёбище", но переписывать кучу существующего кода тяжело.. хотя и пытаются
N>Интересный вывод

какой есть
и главное из жизни очень успешной и известной компании

V>>в отличие от того же XML, ошибку в синтаксисе которого показывает банально любой броузер а новые языковые конструкции не вводят предыдущие версии в ступор (не нужен никакой препроцессор чтобы пропускать новые конструкции)


N>Так называемый "синтаксис" XML, который способен показывать браузер, для других средств (не-XML'ных) аналогичен уровню деления битового потока на байты. И даже баланс тегов — это не синтаксис. Синтаксис — это то, что не может быть например быть while внутри выражения (expression). Это Вам покажет "любой браузер"? Это уже весьма высокий уровень полёта, и далеко не любой браузер способен на такое.


да главное что парсеры не сломаются об такие ошибки

V>>yacc не позволяет выдавать нормальные сообщения об ошибках

N>Нормальные чему?

нормальные не чему а что ошибки нормальные
которые указывали бы не только место где произошла ошибка но и конкретно что это за ошибка
большинство программ использующих yacc выдают сообщения типа
"нарушение синтаксиса в строке такой то, позиции такой то"

V>>и на больших грамматиках добавлять чего то и отслеживать

V>>непротиворечивость (а там постоянон растёт количество варнингов)
N>shift/reduce? Несерьёзно, они по жизни конфликтуют

серъёзно, нет нормальных средств борьбы с ними

V>>очень тяжело

N>Очень конкретно

а я конкретники и не обещал, я обещал практический опыт

N>>>Ну так сформулируйте конкретно и детально (а то я тут из Вас каждое слово клещами тяну) что именно Вы вкладываете в понятие "хорошего" механизма, тогда можно будет рассмотреть, почему такого не было (уточняя: в публичном доступе).

V>>а зачем?
V>>разработчики уже сделали свой выбор
V>>обосновывать его не вижу смысла
V>>таково сложившееся положение вещей
N>Другим объясните, чтобы по тем же граблям не ходить.

дык уже и не ходят, юзают XML где только можно

N>>>Средство "последовательность байт" позволяют гибко, просто и без геморроя менять язык. При этом их возможности значительно шире чем у XML — можно применять и бинарные форматы, и другие варианты форматов с самотерминацией лексем (что резко упрощает парсеры), и при этом оно в разы экономнее XML. Давайте его использовать, зачем нам эти костыли?

V>>угу..
V>>вот только при этом изменении языка старые данные читаться не будут
N>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут.

угу.. годами.. и лучшее средство которое придемули — XML
где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это?

N>А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам?


в случае XML у меня есть путь который обеспечивает способ работы со старыми форматами без переписывания или усложнения парсера

N>>>Не "мимо кассы", а Вы хотите и крестик оставить, и трусы снять Вы ж наехали на "поколение Голуба" за недостаток средств, а взамен в качестве альтернативы предложили XML. Их (того поколения) средства справляются с синтаксисом вида 1+2 беспроблемно и не требуется XML'ное обрамление. А у Вас будет двуслойность — и одни средства, и другие? И что это даст тем применениям, где обычно используется тот же yacc?

V>>простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc
V>>если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить
N>Это Ваши домыслы. Я бы на Вас посмотрел что бы Вы сделали на машине слабее PC XT и стоимостью как "Мерседес" и отдали бы при этом в open source (которое тогда только-только начиналось).

простите, но XML/HTML/SGML именно тогда и зародился
так что это не домыслы. это — жизнь

кстати эту лабораторную (парсер арифметических выражений со скобками и функциями)
я именно па XT-шках и писал..
http://izh-test.sourceforge.net/russian/introduction.html
Re[10]: Снова XML: Just Say No to XML
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 24.11.06 10:25
Оценка:
Здравствуйте, vvaizh, Вы писали:

N>>Интересный вывод:)

V>какой есть
V>и главное из жизни очень успешной и известной компании

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

N>>Так называемый "синтаксис" XML, который способен показывать браузер, для других средств (не-XML'ных) аналогичен уровню деления битового потока на байты. И даже баланс тегов — это не синтаксис. Синтаксис — это то, что не может быть например быть while внутри выражения (expression). Это Вам покажет "любой браузер"? Это уже весьма высокий уровень полёта, и далеко не любой браузер способен на такое.

V>да главное что парсеры не сломаются об такие ошибки

А лучше бы сломались, раз это ошибки.

V>>>yacc не позволяет выдавать нормальные сообщения об ошибках

N>>Нормальные чему?
V>нормальные не чему а что ошибки нормальные
:)
V>>>очень тяжело
N>>Очень конкретно:))
V>а я конкретники и не обещал, я обещал практический опыт

Это не объяснение опыта разработки. Это объяснение уровня "мы тут вкурили и меня плющило". Опыт разработки должен быть выражен детально, иначе это не опыт.

N>>Другим объясните, чтобы по тем же граблям не ходить.

V>дык уже и не ходят, юзают XML где только можно

Что-то я не вижу переписки синтаксиса Си на XML.:)))

N>>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут.

V>угу.. годами.. и лучшее средство которое придемули — XML
V>где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это?

Что именно обеспечивало бы? Определить в начале потока какой-то признак формата и дальше выполнить "условный switch"? ЛЮБОЕ средство такое может. Тот же yacc, только надо в грамматику это вставить.

N>>А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам?

V>в случае XML у меня есть путь который обеспечивает способ работы со старыми форматами без переписывания или усложнения парсера

А его нету без XML? М-да... Ваши заявления всё интереснее и интереснее.

V>>>простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc

V>>>если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить
N>>Это Ваши домыслы. Я бы на Вас посмотрел что бы Вы сделали на машине слабее PC XT и стоимостью как "Мерседес" и отдали бы при этом в open source (которое тогда только-только начиналось).
V>простите, но XML/HTML/SGML именно тогда и зародился
V>так что это не домыслы. это — жизнь

Когда это они зародились? В конце 70-х? М-да... смените траву:) В конце 70-х был roff. Кстати — отличный язык разметки, не хуже SGML. И не такой многословный.
The God is real, unless declared integer.
Re[11]: Снова XML: Just Say No to XML
От: vvaizh http://izh-test.sourceforge.net/
Дата: 24.11.06 10:55
Оценка:
Здравствуйте, netch80, Вы писали:

N>>>Интересный вывод

V>>какой есть
V>>и главное из жизни очень успешной и известной компании
N>При этом сказано 0 целых фиг десятых про то, что этой компании было нужно и что она требовала.

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

N>>>Так называемый "синтаксис" XML, который способен показывать браузер, для других средств (не-XML'ных) аналогичен уровню деления битового потока на байты. И даже баланс тегов — это не синтаксис. Синтаксис — это то, что не может быть например быть while внутри выражения (expression). Это Вам покажет "любой браузер"? Это уже весьма высокий уровень полёта, и далеко не любой браузер способен на такое.

V>>да главное что парсеры не сломаются об такие ошибки
N>А лучше бы сломались, раз это ошибки.

это не просто ошибки, это "такие" ошибки..
о которых ломаться не должно

V>>>>очень тяжело

N>>>Очень конкретно
V>>а я конкретники и не обещал, я обещал практический опыт
N>Это не объяснение опыта разработки. Это объяснение уровня "мы тут вкурили и меня плющило". Опыт разработки должен быть выражен детально, иначе это не опыт.


опыт вообще не обязан выражаться или объясняться, он либо есть либо нет, как данность!
его можно либо игнорировать и учиться на своих ошибках либо САМОМУ слушателю пытаться вкурить для себя

N>>>Другим объясните, чтобы по тем же граблям не ходить.

V>>дык уже и не ходят, юзают XML где только можно
N>Что-то я не вижу переписки синтаксиса Си на XML.

что то я не вижу там больших изменений в синтаксисе за последние кавырнадцать лет для того чтобы его переводить на XML
кроме того C-подобные языки которые в качестве синтаксиса используют XML я уже видел

N>>>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут.

V>>угу.. годами.. и лучшее средство которое придемули — XML
V>>где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это?
N>Что именно обеспечивало бы? Определить в начале потока какой-то признак формата и дальше выполнить "условный switch"? ЛЮБОЕ средство такое может. Тот же yacc, только надо в грамматику это вставить.

а зачем я должен поддерживать несколько веток для switch-а?
это bad smell вообще то!
а зачем я должен заставлять пользователя прописывать версию и следить за её актуальностью?

N>>>А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам?

V>>в случае XML у меня есть путь который обеспечивает способ работы со старыми форматами без переписывания или усложнения парсера
N>А его нету без XML? М-да... Ваши заявления всё интереснее и интереснее.

его нету в виде промышленного решения и парадигмы
это не мои заявления повторяю, это опыт всей отрасли

а автор статьи (Голуб) вместе с вами маргинально пытается отрасли умозрительно чего то объяснить
даже не собираюсь вступать в дебаты

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

не только что "вся отрасль — дураки"
но и "наверно классические средства для создания парсеров имеют какие то изъяны"

V>>>>простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc

V>>>>если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить
N>>>Это Ваши домыслы. Я бы на Вас посмотрел что бы Вы сделали на машине слабее PC XT и стоимостью как "Мерседес" и отдали бы при этом в open source (которое тогда только-только начиналось).
V>>простите, но XML/HTML/SGML именно тогда и зародился
V>>так что это не домыслы. это — жизнь

N>Когда это они зародились? В конце 70-х? М-да... смените траву В конце 70-х был roff. Кстати — отличный язык разметки, не хуже SGML. И не такой многословный.


я не знаю кто тут курит траву, но википедия показывает (http://ru.wikipedia.org/wiki/SGML):

Standard Generalized Markup Language (SGML) это некий метаязык, на котором можно определять язык разметки для документов. SGML — наследник разработанного в 1960 году в IBM языка GML (Generalized Markup Language)


и далее:

SGML это стандарт ISO «ISO 8879:1986 Information processing—Text and office systems—Standard Generalized Markup Language (SGML)»


итого зарождение — между 60м и 86м, как раз ваши 70-е
http://izh-test.sourceforge.net/russian/introduction.html
Re[12]: Снова XML: Just Say No to XML
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 24.11.06 11:14
Оценка:
Здравствуйте, vvaizh, Вы писали:

N>>>>Интересный вывод:)

V>>>какой есть
V>>>и главное из жизни очень успешной и известной компании
N>>При этом сказано 0 целых фиг десятых про то, что этой компании было нужно и что она требовала.
V>сказано было больше другое дело что ничего из сказанного не было услышано, а вернее было прослушано, высокомерно заявлено что это не проблемы и стёрто из слуховой памяти

А, так это и было то что "успешная и известная компания" накопала? OK, принято.

V>>>да главное что парсеры не сломаются об такие ошибки

N>>А лучше бы сломались, раз это ошибки.
V>это не просто ошибки, это "такие" ошибки..
V>о которых ломаться не должно

Так это ошибки или нет?

V>>>а я конкретники и не обещал, я обещал практический опыт

N>>Это не объяснение опыта разработки. Это объяснение уровня "мы тут вкурили и меня плющило". Опыт разработки должен быть выражен детально, иначе это не опыт.
V>:)
V>опыт вообще не обязан выражаться или объясняться, он либо есть либо нет, как данность!
V>его можно либо игнорировать и учиться на своих ошибках либо САМОМУ слушателю пытаться вкурить для себя

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

N>>>>Другим объясните, чтобы по тем же граблям не ходить.

V>>>дык уже и не ходят, юзают XML где только можно
N>>Что-то я не вижу переписки синтаксиса Си на XML.:)))
V>что то я не вижу там больших изменений в синтаксисе за последние кавырнадцать лет для того чтобы его переводить на XML

О.

N>>>>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут.

V>>>угу.. годами.. и лучшее средство которое придемули — XML
V>>>где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это?
N>>Что именно обеспечивало бы? Определить в начале потока какой-то признак формата и дальше выполнить "условный switch"? ЛЮБОЕ средство такое может. Тот же yacc, только надо в грамматику это вставить.
V>а зачем я должен поддерживать несколько веток для switch-а?
V>это bad smell вообще то!
V>а зачем я должен заставлять пользователя прописывать версию и следить за её актуальностью?

Пользователь как раз ничего не прописывает. Вы о чём?

N>>>>А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам?

V>>>в случае XML у меня есть путь который обеспечивает способ работы со старыми форматами без переписывания или усложнения парсера
N>>А его нету без XML? М-да... Ваши заявления всё интереснее и интереснее.
V>его нету в виде промышленного решения и парадигмы
V>это не мои заявления повторяю, это опыт всей отрасли
V>а автор статьи (Голуб) вместе с вами маргинально пытается отрасли умозрительно чего то объяснить
V>даже не собираюсь вступать в дебаты
V>просто подумайте о том, что раз отрасль отказывается от классических синтаксисов на средствах типа yacc
V>то этому могут быть разные объяснения

Опять — я про то, зачем XML, а Вы — про yacc. Это и есть передовой опыт отрасли — перевод разговора на иное?
(Это я уж не вспоминаю в каких случаях вводился XML. А вводился он, как правило, вместо того, что в разы кривее,
и для описания данных, а не для программирования)

V>не только что "вся отрасль — дураки"


Этот вывод откуда? Это не мой вывод.

V>>>простите, но XML/HTML/SGML именно тогда и зародился

V>>>так что это не домыслы. это — жизнь
N>>Когда это они зародились? В конце 70-х? М-да... смените траву:) В конце 70-х был roff. Кстати — отличный язык разметки, не хуже SGML. И не такой многословный.
V>я не знаю кто тут курит траву, но википедия показывает (http://ru.wikipedia.org/wiki/SGML):
V>

V>Standard Generalized Markup Language (SGML) это некий метаязык, на котором можно определять язык разметки для документов. SGML — наследник разработанного в 1960 году в IBM языка GML (Generalized Markup Language)

V>и далее:
V>

V>SGML это стандарт ISO «ISO 8879:1986 Information processing—Text and office systems—Standard Generalized Markup Language (SGML)»

V>итого зарождение — между 60м и 86м, как раз ваши 70-е

Думаете, он 13 лет зарождался?
The God is real, unless declared integer.
Re[13]: Снова XML: Just Say No to XML
От: vvaizh http://izh-test.sourceforge.net/
Дата: 24.11.06 13:15
Оценка:
Здравствуйте, netch80, Вы писали:

V>>>>да главное что парсеры не сломаются об такие ошибки

N>>>А лучше бы сломались, раз это ошибки.
V>>это не просто ошибки, это "такие" ошибки..
V>>о которых ломаться не должно
N>Так это ошибки или нет?

в традиционных парсерах — это ошибки времени парсинга
в xml — это в худшем случае семантические ошибки, а в лучшем программа даже не заметит ничего и отработает "как надо", пропустив непонятные опции/данные

N>Вот именно что "вкурить". Это уже дзэн какой-то получается, а не опыт.


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

N>>>>>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут.

V>>>>угу.. годами.. и лучшее средство которое придемули — XML
V>>>>где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это?
N>>>Что именно обеспечивало бы? Определить в начале потока какой-то признак формата и дальше выполнить "условный switch"? ЛЮБОЕ средство такое может. Тот же yacc, только надо в грамматику это вставить.
V>>а зачем я должен поддерживать несколько веток для switch-а?
V>>это bad smell вообще то!
V>>а зачем я должен заставлять пользователя прописывать версию и следить за её актуальностью?
N>Пользователь как раз ничего не прописывает. Вы о чём?

разве? а как же "в начале потока какой-то признак формата"?
а ведь ещё хуже бывают варианты..
когда даже не в начале потока а почти в каждой строке приходится формат писать..
типа такого:

#ifdef MSVC
...
#endif


или такого:

CREATE /*!32302 TEMPORARY */ TABLE t (a INT);


N>Опять — я про то, зачем XML, а Вы — про yacc. Это и есть передовой опыт отрасли — перевод разговора на иное?

N>(Это я уж не вспоминаю в каких случаях вводился XML. А вводился он, как правило, вместо того, что в разы кривее,
N>и для описания данных, а не для программирования)

скажите а вы оригинальную статью Голуба читали? в начале топика?
он именно жалуется на то что XML используется не только для данных

N>Думаете, он 13 лет зарождался?


а вы думаете он приснился во сне как таблица Менделеева?
http://izh-test.sourceforge.net/russian/introduction.html
Re[14]: Снова XML: Just Say No to XML
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 24.11.06 17:53
Оценка:
Здравствуйте, vvaizh, Вы писали:

V>вы описываете — сон своего разума


Спасибо, вопросов больше нет. Только совет напоследок: выясните, не спите ли сами:)
The God is real, unless declared integer.
Re[10]: Снова XML: Just Say No to XML
От: _Winnie Россия C++.freerun
Дата: 10.12.06 19:06
Оценка:
Здравствуйте, kan, Вы писали:

kan>eao197 wrote:


>> А какая альтернатива в XML будет, например, у:

>>
>> if something && ( something_else || ( first && second && third ) )
>> ...bla-bla-bla...
>> elsif another || yet_another || or_yet_another
>> ...bla-bla-bla...
>> else
>> ...trundec...
>> end

kan>Если что-то типа подхода xslt (для условий используется xpath):


kan>
kan><choose>
kan>   <when test="something and (something_else or (first and second and third))">
kan>     ...bla-bla-bla...
kan>   </when>
kan>   <when test="another or yet_another or or_yet_another">
kan>     ...bla-bla-bla...
kan>   </when>
kan>   <otherwise>
kan>     ...trundec...
kan>   </otherwise>
kan></choose>
kan>

kan>Хотя в условиях и javascript можно использовать. Испольозование xml не запрещает использовать другие языки. Вон, в
kan>html/svg javascript тоже активно юзается, никто не жалуется.
Хм. А почему совершен переход в условиях на свой синтаксис? Потому что так удобней? Значит, ещё чуть-чуть добавить к нашему парсеру, и получится без лишнего синтаксического оверхеда.
А если мы не хотим писать свой парсер, то тогда придётся писать, при условии простой вложенности конструкций что-то вроде
<?xml version="1.0" encoding="utf-8"?>
<choose>
    <when>
        <test>
            <and>
                <var>someting</var>
                <and>
                    <or>
                        <var>something_else</var>
                        <and>
                            <var>first</var>
                            <var>second</var>
                            <var>third</var>                            
                        </and>
                    </or>
                </and>
            </and>
        </test>
        <code>
            ...bla-bla-bla...
        </code>
    </when>
    <when>
        <test>
            <or>
                <var>another</var>
                <var>yet_another</var>
                <var>or_yet_another</var>                
            </or>
        </test>
        <code>
            ...bla-bla-bla...
        </code>
    </when>
    <otherwise>
        <code>
            ...trundec...
        </code>
    </otherwise>
</choose>


А оригинальный пример —
if(someting)
{
}


<when>
   <test>
      <var>someting</var>
   </test>
   <code>
   </code>
</when>
Правильно работающая программа — просто частный случай Undefined Behavior
Re[11]: Снова XML: Just Say No to XML
От: Аноним Великобритания  
Дата: 11.12.06 14:36
Оценка:
_Winnie wrote:

> kan>Хотя в условиях и javascript можно использовать. Испольозование xml

> не запрещает использовать другие языки. Вон, в
> kan>html/svg javascript тоже активно юзается, никто не жалуется.
> Хм. А почему совершен переход в условиях на свой синтаксис? Потому что
> так удобней? Значит, ещё чуть-чуть добавить к нашему парсеру, и
Потому что требование удобства написания программ превышает сложность написания своего парсера.

> получится без лишнего синтаксического оверхеда.

> А если мы не хотим писать свой парсер, то тогда придётся писать, при
> условии простой вложенности конструкций что-то вроде
В каких-то условиях и такие вещи могут оказаться лучше.

Что-то ты некрофилией увлёкся.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Снова XML: Just Say No to XML
От: Курилка Россия http://kirya.narod.ru/
Дата: 03.04.07 12:42
Оценка:
Здравствуйте, eao197, Вы писали:

E>Еще пару капелек масла в огонь священной войны против XML На этот раз в качестве информации к размышлению о производительности. Разработчики распределенной системы контроля версий Bazaar в новой версии 0.15 отказались от использования XML в качестве формата для хранения описаний в рабочей копии. За счет чего получили серьезный прирост производительности на некоторых операциях (по ссылке рассказывается об ускорении операции status на дереве исходников ядра Linux-а от 2.2 до 13.9 раз(!)). До этого разработчики Subversion так же отказались от использования XML в описателях рабочей копии (см. 1.4 release notes, раздел Working copy performance improvements).


E>Т.е. имеет смысл задумываться о выборе XML в качестве хранилища данных. Далеко не все ладно в Датском-то королевстве


В свете этого я не совсем понимаю смысл XML DB
Re[3]: Снова XML: Just Say No to XML
От: anton_t Россия  
Дата: 03.04.07 14:10
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, eao197, Вы писали:


E>>Еще пару капелек масла в огонь священной войны против XML На этот раз в качестве информации к размышлению о производительности. Разработчики распределенной системы контроля версий Bazaar в новой версии 0.15 отказались от использования XML в качестве формата для хранения описаний в рабочей копии. За счет чего получили серьезный прирост производительности на некоторых операциях (по ссылке рассказывается об ускорении операции status на дереве исходников ядра Linux-а от 2.2 до 13.9 раз(!)). До этого разработчики Subversion так же отказались от использования XML в описателях рабочей копии (см. 1.4 release notes, раздел Working copy performance improvements).


E>>Т.е. имеет смысл задумываться о выборе XML в качестве хранилища данных. Далеко не все ладно в Датском-то королевстве


К>В свете этого я не совсем понимаю смысл XML DB


Маркетинг
Re[3]: Снова XML: Just Say No to XML
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.04.07 00:44
Оценка:
Здравствуйте, Курилка, Вы писали:

К>В свете этого я не совсем понимаю смысл XML DB


Это банально удобно. Сервер берет на себя проблемы производительности, а ты получаешь удобно стркутурирвоаные данные.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Снова XML: Just Say No to XML
От: Lloyd Россия  
Дата: 04.04.07 04:40
Оценка:
Здравствуйте, Курилка, Вы писали:

К>В свете этого я не совсем понимаю смысл XML DB


А XML DB не использует XML в качестве формата для хранения.
Re[4]: Снова XML: Just Say No to XML
От: Курилка Россия http://kirya.narod.ru/
Дата: 04.04.07 04:45
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Курилка, Вы писали:


К>>В свете этого я не совсем понимаю смысл XML DB


L>А XML DB не использует XML в качестве формата для хранения.


Ну вот я написал, потом об этом же и подумал
Re[5]: Снова XML: Just Say No to XML
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 09.05.07 00:39
Оценка:
OE>Языково-ориентированное программирование: следующая парадигма
Автор(ы): Сергей Дмитриев
Дата: 02.03.2006
Пришло время следующей технологической революции в разработке софта – и становится все очевиднее, какой она должна быть. Новая парадигма программирования – вот она, перед нами. Она еще не вполне сформировалась – разные части известны под разными именами вроде Intentional Programming, MDA, порождающее программирование и т.д. Я предлагаю объединение этих новаторских подходов под общим именем «языково-ориентированного программирования»; данная статья объясняет основные принципы новой парадигмы.


Имхо — это только гиперболизация проблем xml.
Давайте вместо уровня абстракции введём ещё один уровень сложности.
Придумаем думателя.
Для шаблонных задач — это решение.
Для остальных — дополнительный геморрой.
... << RSDN@Home 1.2.0 alpha rev. 677>>
XML -- extensible MARKUP language
От: no4  
Дата: 10.05.07 06:10
Оценка:
Здравствуйте, eao197, Вы писали:

E>XML, вероятно, худший из когда-либо появлявшихся языков программирования. Я не говорю об XML как о языке описания данных, которым он был в своем первоначальном дизайне.


XML — это язык разметки (markup), то есть берется текст и его смысловые части размечаются:
Мама мыла раму, причем голубую

-->
<washing><who>Мама</who> мыла <what>раму</what>, причем голубую</washing>



Для описания данных предназначен, например, yaml (он так расшифровывается YAML Ain't Markup Language). Yf
washing:
    who:Мама
        what:Раму


Просто XML получил широкую поддержку и многие считают что проще использовать его, чем городить что-то свое или использовать что-то нераспространенное, хотя и заплатим некоторую цену читабельности.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: Снова XML: Just Say No to XML
От: Arioch  
Дата: 10.05.07 09:59
Оценка:
_>я жалуюсь. при всей моей любви к этой игрушке трафик, при большОй стимости за оный, достаточно велик и точно проигрывает icq-шному.

Особенно на мобильнике J2ME+GPRS
Вот тут бы что-то типа EBML было бы сильно лучше.
Впрочем там и протокол надо пересматривать — например не грузить ростер целиком при запуске, а только изменения от последней загрузки.
Re[10]: Снова XML: Just Say No to XML
От: Arioch  
Дата: 10.05.07 10:56
Оценка:
GZ>Вообще-то нормальные девелоперы, для того чтобы уменьшить трафик включают gzip, который собственно именно для этого и предназначен. А через LZW алгоритмы, xml скукоживается на порядки.

jabber/gzip уменьшает трафик до 20-33%

При это zlib на J2ME работает не очень и память кушает дай боже — не каждый телефон справляется.

На вскидку, если из XMPP убрать повторения и избыточность и вместо XML сделать двоичный формат — сожмётся сильнее и при этом гораздо легче будет и для клиента-мобильника и для сервера, которому не придется для каждого соединения отдельный словарь LZW хранить
Re[10]: Снова XML: Just Say No to XML
От: igna Россия  
Дата: 18.05.07 10:04
Оценка:
Здравствуйте, eao197, Вы писали:

E>А это лучше заменить на:


E>html {
E>  head {
E>    title 'Hi'
E>  }
E>  body {
E>    p {
E>      'Hello, world!'
E>    }
E>  }
E>}


А еще лучше на:

html
  head
    title 'Hi'
  body
    p
      'Hello, world!'
Re[3]: Снова XML: Just Say No to XML
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 11.07.08 08:04
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>А прийдётся разбираться Google открыл протокол обмена данными Protocol Buffers:


Ну, и, свежий пост от Joe Armstrong слегка цепляет XML vs. UBF.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[3]: Снова XML: Just Say No to XML
От: Cyberax Марс  
Дата: 16.07.08 01:48
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

C>>XML — это язык конфигурирования и программирования данных. Я НЕ хочу

C>>разбираться с кучей яызков для описания ДАННЫХ — я хочу один формат,
ANS>А прийдётся разбираться Google открыл протокол обмена данными Protocol Buffers:
Собственно, я о нём аннонс в форум по C++ писал

Protobuf — это как раз ПРАВИЛЬНОЕ применение для кастомного языка. Так как он используется для не-human-readable данных, для которых критична скорость и занимаемый объём.

Там место для XML — это разве что описание самих протоколов. Но формат а-ля-idl для них уже просто стал стандартом.
Sapienti sat!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.