LINUX.ORG.RU
Новости — Open Source  

Пятая редакция стандарта XML 1.0 несовместима с XML Namespaces 1.0

 ,


0

0

Попытка сделать XML более интернациональным привела к несовместимости с текущей редакцией стандарта XML Namespaces 1.0.

Один из изобретателей XML, Тим Брей, написал возражение по поводу готовящегося принятия пятой редакции XML 1.0:

http://lists.w3.org/Archives/Public/x...

Суть проблемы заключается в следующем. До пятой редакции стандарт XML 1.0 позволял использовать символы Unicode, принятого в 1998 году. Это означает, что символы, добавленные в более поздней версии Unicode, не могут быть использованы в названиях тагов и атрибутов XML 1.0 до пятой редакции. К таким символам относятся, например, буквы Амхарского языка и языка индейского племени Чероки. Пятая редакция XML 1.0 позволяет пользоваться любыми символами Unicode, добавленными после 1998 года. Однако текущий стандарт на XML Namespaces 1.0 всё ещё не позволяет этого.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
← Веб-браузер Chrome от Google подвержен опасности подмены адреса
Интервью с Шатллвортом →
  1 2 3 4 5 6 7 8
Ответ на: комментарий от anonymous

>Теперь представим что посылаешь свой ХМЛь. Да тебе надо пропускную способность в 2 раза минимум апгрейдить

Да ты что, серьезно?

Берем типичный JSON согласно спеке - собственно из нее же и берем:

{
"Image": {
"Width": 800,
"Height": 600,
"Title": "View from 15th Floor",
"Thumbnail": {
"Url": "http://www.example.com/image/481989943";,
"Height": 125,
"Width": "100"
},
"IDs": [116, 943, 234, 38793]
}
}

Переписываем:

<image width="800" height="600" title="View from 15th Floor">
<thumbnail url="http://www.example.com/image/481989943"; width="100" height="125"/>
<id>116</id>
<id>943</id>
<id>234</id>
<id>38793</id>
</image>

229 байт XML против 273 байт JSON.

Ты быйтики то посчитай.

К стати берем одну строчку из твоего примера:

{"result":
{"records":[
{"c0":"0.9720159953189302","s0":"","ca0":"aCategory","c1":"0.6619113675453985", "s1":"","ca1":"aCategory","c2":"0.5176177263094673","s2":"","ca2":"aCategory","c 3":"0.6373270196930729","s3":"","ca3":"aCategory","c4":"0.13960286951519962","s4 ":"","ca4":"aCategory","c5":"0.6198919906501471","s5":"","ca5":"aCategory","c6": "0.6320201229293811","s6":"","ca6":"aCategory","c7":"0.044809738958035195","s7": "","ca7":"aCategory","c8":"0.059864894016882775","s8":"","ca8":"aCategory","c9": "0.33609915482718156","s9":"","ca9":"aCategory","c10":"0.5375455220230821","s10" :"","ca10":"aCategory","c11":"0.7046823042255761","s11":"","ca11":"aCategory","c 12":"0.6151405200638205","s12":"","ca12":"aCategory","c13":"0.1782943314573321", "s13":"","ca13":"aCategory","c14":"0.6895890380021066","s14":"","ca14":"aCategor y","c15":"0.04705287901358879","s15":"","ca15":"aCategory","c16":"0.866886845888 3906","s16":"","ca16":"aCategory","c17":"0.7075236661718358","s17":"","ca17":"aC ategory","c18":"0.035790902837217975","s18":"","ca18":"aCategory","c19":"0.14592 060063537282","s19":"","ca19":"aCategory","c20":"0.9533494909259274","s20":"","c a20":"aCategory","c21":"0.4053758008537425","s21":"","ca21":"aCategory"},
]}};

и трансформируем в XML

<result>
<r c0="0.9720159953189302" s0="" ca0="aCategory" c1="0.6619113675453985" s1="" ca1="aCategory" c2="0.5176177263094673" s2="" ca2="aCategory" c3="0.6373270196930729" s3="" ca3="aCategory" c4="0.13960286951519962" s4="" ca4="aCategory" c5="0.6198919906501471" s5="" ca5="aCategory" c6="0.6320201229293811" s6="" ca6="aCategory" c7="0.044809738958035195" s7="" ca7="aCategory" c8="0.059864894016882775" s8="" ca8="aCategory" c9="0.33609915482718156" s9="" ca9="aCategory" c10="0.5375455220230821" s10="" ca10="aCategory" c11="0.70468230422
55761" s11="" ca11="aCategory" c12="0.6151405200638205" s12="" ca12="aCategory" c13="0.1782943314573321" s13="" ca13="aCategory" c14="0.6895890380021066" s14="" ca14="aCategory" c15="0.04705287901358879" s15="" ca15="aCategory" c16="0.8668868458883906" s16":"" ca16":"aCategory" c17":"0.7075236661718358" s17":"" ca17":"aCategory" c18":"0.035790902837217975" s18" ca18="aCategory" c19="0.14592060063537282" s19="" ca19="aCategory" c20="0.9533494909259274" s20="" ca20="aCategory" c21="0.4053758008537425" s21="" ca21="aCategory"/>
</result>

Считаем: 1086 байт XML против 1222 байта JSON.

То есть для твоего случая оверхед с JSON - 12% по сравнению с XML.

Так что перед тем как расказывать сказки про трафик - байтики то посчитай.

>Это просто хак, чтобы сделать хеш

Этот просто хак как ты его называешь тормозит очень сильно потому что лукап по обекту это нефига не тоже самое что лукап по хэшу - почитай маны по оптимизации жабаскриптов. И этот хак делает невозможным написание обобщенных сериализаторов в JSON, потому что десериализатор не может различить где объект, а где хеш. А если этот хэш не дай бог здоровый обращение к нему вообще трындец производительности в слуае объектов.

r ★★★★★
()
Ответ на: комментарий от anonymous

>Императивные языки действуют методом "divide and conquer"

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

Для начала хочу увидеть аналог вот этого

<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>

для упомянутых деревьев.

>Так понятнее?

Я понял одно - люди которые не умеют этого делать - этого делать не умеют, и рассказывают всем сказки что они все перепишут форами.

r ★★★★★
()
Ответ на: комментарий от r

К стати переписанный мой XML на mime и json я дождусь или все сказки о том что будет короче и понятнее воспринимать как испорченную атмосферу?

r ★★★★★
()
Ответ на: комментарий от r

> 229 байт XML против 273 байт JSON.

Немного нечестно конечно (это ты смотря на мой пример - написал так-же эффективно на ХМЛе ;) Обычно я переписываю написанное ХМЛщиками в 2 раза короче, потому-что они не кладут _всё_, как ты - в аттрибуты.
Я бы сказал так: на JSON нельзя написать с оверхедом (потому что это - реальные обьекты и их аттрибуты, и нет маркапа), а на ХМЛ - легко написать с большим оверхедом (понаписать много ненужного маркапа).
В нашем примере нет большой разницы в обьёме потому что запись эквивалентная. Тогда зачем маркап (эти долбанные скобки) вообще?

> лукап по обекту это нефига не тоже самое что лукап по хэшу

а откуда ты знаешь как лукап реализован в разных браузерах? родных хешей ведь в жабаскрипте нет. Это же как раз тот случай - где нам не хватает контроля, но мы ничего не можем поделать. А кто сказал что браузеровская имплементация DOMa (а если используешь XSLT - то уж точно не строишь сам state-machine мачине на базе SAXа) - кладёт все аттрибуты в хеши, а не итерирует через список?
Я никогда не пользуюсь DOMом потому что считаю что закачивание/создание кучи дополнительных обьектов - непозволительная роскошь (когда данных много). И делаю state-machine (парся SAXом), имея очень ограниченную память. А XSLT подразумеваыет хранение 2 огромных деревьев в памяти. Вообще мы смешали здесь несколько использований ХМЛ (Не охота разбирать все случаи: конфиги, создание стилей, работа в браузере и пр. - просто лень). Но во всех - бьюсь об заклад - всё равно есть более оптимальный вариант.

Kак сказал Хеймс Кларк (Hames Clark):
"Any damn fool could produce a better data format than XML"

anonymous
()
Ответ на: комментарий от r

> 229 байт XML против 273 байт JSON.

Немного нечестно конечно (это ты смотря на мой пример - написал так-же эффективно на ХМЛе ;) Обычно я переписываю написанное ХМЛщиками в 2 раза короче, потому-что они не кладут _всё_, как ты - в аттрибуты.
Я бы сказал так: на JSON нельзя написать с оверхедом (потому что это - реальные обьекты и их аттрибуты, и нет маркапа), а на ХМЛ - легко написать с большим оверхедом (понаписать много ненужного маркапа).
В нашем примере нет большой разницы в обьёме потому что запись эквивалентная. Тогда зачем маркап (эти долбанные скобки) вообще?

> лукап по обекту это нефига не тоже самое что лукап по хэшу

а откуда ты знаешь как лукап реализован в разных браузерах? родных хешей ведь в жабаскрипте нет. Это же как раз тот случай - где нам не хватает контроля, но мы ничего не можем поделать. А кто сказал что браузеровская имплементация DOMa (а если используешь XSLT - то уж точно не строишь сам state-machine на базе SAXа) - кладёт все аттрибуты в хеши, а не итерирует через список?
Я никогда не пользуюсь DOMом потому что считаю что закачивание/создание кучи дополнительных обьектов - непозволительная роскошь (когда данных много). И делаю state-machine (парся SAXом), имея очень ограниченную память. А XSLT подразумеваыет хранение 2 огромных деревьев в памяти. Вообще мы смешали здесь несколько использований ХМЛ (Не охота разбирать все случаи: конфиги, создание стилей, работа в браузере и пр. - просто лень). Но во всех - бьюсь об заклад - всё равно есть более оптимальный вариант.

Kак сказал Хеймс Кларк (Hames Clark):
"Any damn fool could produce a better data format than XML"

anonymous
()
Ответ на: комментарий от r

> Я посмотрю как ты будешь обрабатывать гетерогенные деревья любого (неизвестного) уровня вложенности без рекурсии и паттерн матчинга.

кто сказал - без рекурсии и без паттернов???

YAHOO.lang.JSON.stringify(testResults, null, 3)
рекурсивно проходит дерево до 3 уровня вложенности
а регулярные выражения мы очень уважаем.

И опять JSON. Давай на нём не циклиться.
Много раз говорилось что зачастую есть ещё более экономичные способы (выплеснуть данные). Сразу в виде параллельных массивов и прочее. На сервере очень эффективно можно всё приготовить и просто подставить на клиенте (вместо того чтобы забивать браузер большим количеством дополнительных обьектов.
А с конфигами? Разве они не в хэше в конечном итоге? Зачем промежуточный маркап, если сразу можно этот хэш организовать? Почему ты не отвечаешь на мои вопросы? Какая выгода от дополнительной сложности ХМЛя в конфигах (по сравнению с тем что я показывал неоднократно)?

anonymous
()
Ответ на: комментарий от anonymous

>Немного нечестно конечно (это ты смотря на мой пример - написал так-же эффективно на ХМЛе ;)

Да ты почти Танненбаум.

>Я бы сказал так: на JSON нельзя написать с оверхедом

А примеры говорят что структурально эквивалентный XML на 12 процентов меньше чем JSON. Я верю примерам которые подтверждены цифрами а не голословным фразам.

>Тогда зачем маркап (эти долбанные скобки) вообще?

Это вообще смешно. Служебных символов в JSON по спецификации больше чем в XML. При эквивалентных тегах и данных откуда по твоему выросли эти 12 %? Да вот из кавычек с запятыми и выросли.

> а откуда ты знаешь как лукап реализован в разных браузерах?

От верблюда:

<script>
var a = {a: "bbb", k:1, x:"xxx"};
var d1 = new Date();
for (i=0; i<100000; i++) a.k = a.k + 1;
var d2 = new Date();
document.write("object lookup:" + (d2 - d1) + "<br>");

var r = [];
r["a"] = "bbb";
r["k"] = 1;
r["x"] = "xxx";
d1 = new Date();
for (i=0; i<100000; i++) r["k"] = r["k"] + 1;
d2 = new Date();
document.write("array lookup:" + (d2 - d1));

</script>

gecko:

object lookup:1063
array lookup:146

Разница на порядок.

>родных хешей ведь в жабаскрипте нет.

Есть различие в реализации ассоциативных массивов и атрибутов обектов.

>А XSLT подразумеваыет хранение 2 огромных деревьев в памяти.

Хто тебе сказал такую чушь? ИСточником для трансформации может быть что угодно любая бойда которая умеет генерировать SAX события. Вон в инете есть пример написания трансформации текстовых файлов парсимых ANTLR парсером который генерирует SAX события.

>"Any damn fool could produce a better data format than XML"

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

r ★★★★★
()
Ответ на: комментарий от anonymous

>рекурсивно проходит дерево до 3 уровня вложенности

Между словом обходить и словом трансформировать ты семантическую разицу видишь?

> Много раз говорилось что зачастую есть ещё более экономичные способы (выплеснуть данные)

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

>Разве они не в хэше в конечном итоге?

Нет.

>Зачем промежуточный маркап, если сразу можно этот хэш организовать?

Ну организуй мне хэш для компилируемого языка.

>Какая выгода от дополнительной сложности ХМЛя в конфигах (по сравнению с тем что я показывал неоднократно)?

Когда ты научишься поддерживать там списки мапы и структурированные обекты - тогда поговорим. Пока у тебя все конфиги сводятся к "ключ -> примитивное значение". ТАк вот: не все конфиги к этому сводятся.

r ★★★★★
()
Ответ на: комментарий от r

> К стати переписанный мой XML на mime и json я дождусь или все сказки о том что будет короче и понятнее воспринимать как испорченную атмосферу?

подавись.

Я в 5 раз повторяю - что я не сторонник JSON.

---mime body---
encoding=UTF-8
job.description=PlayBoy#2-2008/Cover
job.id=1
job.state=move1
job.sender.name=r
job.sender.email=x.mad.scientist@gmail.com
job.resource.main.1=/tmp/test/EngineTestCase/files/1.txt
job.resource.main.2=/tmp/test/EngineTestCase/files/2.txt
job.resource.preflight.1=/tmp/test/EngineTestCase/files/1.checkresult.xml
job.resource.preflight.2=/tmp/test/EngineTestCase/files/2.checkresult.xml
wfd.workflow.name=3move
wfd.workflow.state.move1.action=fs:move
wfd.workflow.state.move1.type=START
wfd.workflow.state.move1.destination=/tml/test/EngineTestCase/dest1
wfd.workflow.state.transition.on=success
wfd.workflow.state.transition.to=move2
wfd.workflow.state.move2.action=fs:move
wfd.workflow.state.move2.destination=/tml/test/EngineTestCase/dest2
wfd.workflow.state.transition.on=success
wfd.workflow.state.transition.to=move3
wfd.workflow.state.move3.action=fs:move
wfd.workflow.state.move1.type=FINAL
wfd.workflow.state.move3.destination=/tml/test/EngineTestCase/dest3
---mime body---

твой файл - b.txt, мой - a.txt.
$wc a.txt b.txt
29 57 1649 a.txt
22 23 1001 b.txt

единственное что я опустил - это 2 твоих пропертей - namespaces.
В моём случае они не нужны, потому что у меня одни namespaces (associative array)
Даже если их добавишь - будет в 2 раза


anonymous
()
Ответ на: комментарий от anonymous

а теперь сравни читаемость моего хеша и твоего грёбаного ХМЛя (и оверхед 100%).
И я уверен, что мой парсинг будет на порядок быстрее. Могу послать Ц функцию, которая вообще не копирует ничего, память занимаыемая - точно то что ты видишь на экране. А процессинг парсинга - несколько проверок (2 делимитеров).
Сравни с тем, что творит твой ХМЛ парсер.

anonymous
()
Ответ на: комментарий от anonymous

сорри, конечно-же
твой файл - a.txt, мой - b.txt.
:)))

anonymous
()
Ответ на: комментарий от r

> Пока у тебя все конфиги сводятся к "ключ -> примитивное значение". ТАк вот: не все конфиги к этому сводятся.

"примитивное значение" - это стринг. И тип ты можешь послать под другим ключом, а интерпретация зависит от логики, которая может быть _любой_. Я не случайно много раз упоминал фреймы. Да прочитай в конце концов что это такое! А твоя программа что - не примитивный стринг что-ли??

короче, надоело.
Ты зациклился на ХМЛе.
Бай.

anonymous
()
Ответ на: комментарий от anonymous

>подавись

Первое: хэш твой хреновый имеет повторяющиеся ключи. До этого формат был order independent теперь стал order dependent, а следовательно уже завязан на последовательный парсинг и аналогичную работу - чтобы им воспользоваться нужно оперировать понятиями строк. Поработай над ошибками.

Второе: ты смешал структуру и данные которые были разделены. Перед этим название стейта было данными и легко строились очвидные запросы вида //state[name = 'move1'] - в твоем случае это невозможно. Чтобы получить описание стейта надо иметь дело с последовательным построчным обходом и составлением ключей руководствуясь непонятно чем.

Короче ты из нормального сделал геморой перемешав структуру и данные. Это как минимум. Далее воркфлов это часть джоба. Я могу их добавить N.

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





r ★★★★★
()
Ответ на: комментарий от anonymous

>я ещё не коснулся интересной темы SAX vs DOM и XSLT, и используемая память

Можешь коснуться еще более интересной темы - решений аналогичных XSLT и используемую память. А то ты как этот клоун написавший презентацию - не привел не одного альтернативного решения. Вас в ВУЗе обоих не учили как нажно делать подобные анализы? Не научили что слово "гавно" или "ляля" в научных и инженерных кругах всегда стоит рядом с "по сравнению с" ?

r ★★★★★
()
Ответ на: комментарий от r

P.S. >>А XSLT подразумеваыет хранение 2 огромных деревьев в памяти. >Хто тебе сказал такую чушь? потому-что инкрементальный парсинг - чрезвычайно сложная задача. И XSLT - работает с целым деревом. > Вон в инете есть пример написания трансформации текстовых файлов парсимых ANTLR парсером который генерирует SAX события ты хоть сам понял что сказал? Я с ANTLR работал. Это генератор парсеров по заданной грамматике, как он может генерировать SAX события?? Ты с SAXом то работал? Ладно, без обид. Реально - пока. Успехов.

anonymous
()
Ответ на: комментарий от anonymous

>И тип ты можешь послать под другим ключом, а интерпретация зависит от логики, которая может быть _любой_.

То есть вместо того чтобы по запросу вида config.get("key") получить instanceof Map или List я должет изгаляться и смотреть а что там сосбственно лежит? Новое слово в велосипедостроении - чем больше долбонутого кода тем лучше!

r ★★★★★
()
Ответ на: комментарий от lester_dev

>Сейчас набежит куча анонимусов с непременным желанием написать >запросы на амхарском языке и криками "XML - говно!"

я хочу написать на запрос (запрос? хм, ну ладно, запрос) на языке чероки!!! XML - говно!

anonymous
()
Ответ на: комментарий от anonymous

>Это генератор парсеров по заданной грамматике, как он может генерировать SAX события??

Да ты шо! Сурьезно? А тебе не приходит в голову что триволкер антэлра в семантик акшенах может генерировать события соответствующие саксу?

>Ты с SAXом то работал?

Значительно больше чем ты, если ты не в курсе того что SAX работает в две стороны - можно писать обработчик реализуя интерфейсы SAX чтобы _реагировать_ на события, а можно _генерировать_ эти события, чтобы по протоколу SAX передавать что-либо, например, трансформеру. Это именно для этого используется SAXSource в качестве источника трансформации.

r ★★★★★
()
Ответ на: комментарий от r

> Никакой бинарный протокол такого не сделает

А как протокол вообще может делать то, что делает язык разметки? Вы что с чем сравниваете?

zenith ★★★
()
Ответ на: комментарий от r

Ну колись, колись, r - что формат, который тут Вася всюду пихает - куда более православен чем ксымель. По-большому счёту ;)

anonymous
()
Ответ на: комментарий от r

>В нутри SOAP передаются документы без всякой необходимости понимания самим транспортом их содержимого.

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

XML, как таковой - это неизбежное зло, но пока что лучше ничего не придумали.

stellar ★
()
Ответ на: комментарий от r

>Ты быйтики то посчитай.

Это все хорошо, конечно... Но только до тех пор, пока не надо заниматься валидацией переданных данных. Вот тогда и возникает вопрос, как валидировать JSON. А для XML есть DTD.

С другой стороны, у XML явная нелюбовь к символам, передаваемым в неправильной encoding, что в сумме с криворукими программерами (а их 90%) дает своим проблемы.

В общем, проблемы есть везде; ни XML ни JSON универсальными инструментами не являются.

stellar ★
()
Ответ на: комментарий от stellar

> XML, как таковой - это неизбежное зло, но пока что лучше ничего не придумали.

А MIME - как envelope?
Вы что, мылом не обмениваетесь никогда? Или MIME не поддерживает гетерогенную информацию или, не дай бог, - бинарную не поддерживает?

anonymous
()
Ответ на: комментарий от stellar

> Но только до тех пор, пока не надо заниматься валидацией переданных данных

DTD экстремально дорого.
И очень маленькая толика валидации которую всё равно надо делать в коде, который вне DTD. DTD - чрезвычайно-примитивная валидация (однако очень ресурсо-жрущая).
Мы в продакшене должны были срочно отключить DTD, так как он был узким местом.

anonymous
()
Ответ на: комментарий от r

>к стати где там майм.

------8<------
content-transfer-encoding: quoted-printable
content-type: text/plain; charset="UTF-8"

job.namespace=ns/markii/workflow/job/1.0/
job.description=PlayBoy#2-2008/Cover
job.id=1
job.state=move1
job.sender.name=r
job.sender.email=x.mad.scientist@gmail.com
job.resource.main.1=/tmp/test/EngineTestCase/files/1.txt
...
wfd.workflow.state.move3.destination=/tml/test/EngineTestCase/dest3
------8<------

А теперь ты добавь SOAP-конверт - кульминацию ХМЛ-гения.

anonymous
()
Ответ на: комментарий от r

> То есть вместо того чтобы по запросу вида config.get("key") получить instanceof Map или List я должет изгаляться и смотреть а что там сосбственно лежит?

всё наоборот, ты перепутал.
сравним - сколько строк кода надо чтобы выпарсить твой Map и вышеприведённый - проперти-подобный?
В какой-нибудь жаве - так вообще 1-2 строки (и потом - сразу config.get("key"))
А у вас с ХМЛ сколько строк это займёт? ;)))

anonymous
()
Ответ на: комментарий от stellar

> XML, как таковой - это неизбежное зло, но пока что лучше ничего не придумали.

В какой конкретно области лучше ничего не придумали? Какие вообще задачи решает XML?

zenith ★★★
()
Ответ на: комментарий от anonymous

ну так доказано или нет - что хмл для пропертей - полный маразм?

anonymous
()
Ответ на: комментарий от anonymous

в яве:

Properties config=new Properties();
config.load(new java.io.BufferedInputStream(new ava.io.FileInputStream ("/path/to/properties")));
...
System.out.println(config.getProperty("key"));


в C:

if((exit_code=params_init())){
return exit_code;
}
...
printf("%s", params_get("key"));

(используя как пример простую хэш:
http://sourceforge.net/project/showfiles.php?group_id=124759&package_id=1...


Теперь ждём чтения конфига с ХМЛ (что надо сделать девелоперу чтобы получить простой Map).

anonymous
()
Ответ на: комментарий от zenith

>В какой конкретно области лучше ничего не придумали?

В области передачи структурированных данных в гетерогенных системах.

>Какие вообще задачи решает XML?

Задачу передачи структурированных данных в гетерогенных системах.

stellar ★
()
Ответ на: комментарий от anonymous

>DTD экстремально дорого. И очень маленькая толика валидации которую всё равно надо делать в коде, который вне DTD. DTD - чрезвычайно-примитивная валидация (однако очень ресурсо-жрущая). Мы в продакшене должны были срочно отключить DTD, так как он был узким местом.

Никто не говорит, что DTD - это верх инженерной мысли. Но в JSON нет и этого. Проще говоря, XML хотя и плохо, но можно валидировать, а JSON - нет.

stellar ★
()
Ответ на: комментарий от anonymous

И я требую второй, более коварный пример.
Допустим, мы имеем 2 набора пропертей: одни общий, а второй - конкретного юзера (и только то что есть у юзера - оверридит дефолты). Как в мплеере итп.
В жабе - это будет на строку больше, в Ц - аналогично.

Теперь, внимание - тарааааамммм - ХМЛ код (я знаю что будет, однако приведите, пожалуйста, ХМЛщики ваш код для сравнения ;)

(кстати у тебя, r, Config - синглетон. Для второго примера придётся изменить;)

...

так как результат мы знаем (как ХМЛщики будут наполнять простой map) - прошу дискуссию о непригодности ХМЛя для конфигов считать на ЛОРе закрытой (ввиду очевидной разницы)

==============END OF DISCUSSION: XML is bad for configs===============

anonymous
()
Ответ на: комментарий от SI 

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

Гы. Из реального кода :)

: следующая_точка  ( -- )
	точка 1+
	зона list# mod 				\ "Заворачиваем" территорию по кольцу
	to точка
;

: предыдущая_точка  ( -- позиция )
	точка
	dup 0 <= if
		зона list# +
	then
	1-
;

: показать_точку  ( -- )
	указатели точка list@ ?dup if false unspawn then
	зона точка list@ 
	list-rev> drop z>geo \ получили x y z очередной точки
	0 тип_моба 0 false
	spawn
	dup c.paralyze
	dup указатели точка list!
	указатели предыдущая_точка list@
	?dup unless
		drop exit
	then
	тип_скилла 1 500 500 new-MagicSkillUser
	player@ p.broadcast
;

: начальная_точка  ( -- )  0 to точка ;

: показать_точки  ( -- )
	указатели unless
		new-list
		зона list# 0 ?do
			0 over list+
		loop
		to указатели
	then
	
	начальная_точка
	зона list# 0 ?do
		показать_точку
		10 sleep
		следующая_точка
	loop
;

: убрать_точку  ( -- )
	указатели точка list@
	false unspawn
	10 sleep
	следующая_точка
;

: убрать_точки  ( -- )
	указатели unless exit then

	начальная_точка
	
	зона list# 0 ?do
		убрать_точку
	loop
;

true value цикл?


: цикл  ( -- )
	цикл? unless exit then
	показать_точки   
	цикл? if "admin: tools: territory: цикл" задержка do-timer drop then 
;

: start  ( -- )  
	true to цикл?
	цикл
;

: stop  ( -- )
	false to цикл?
	убрать_точки 
;

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

> А у вас с ХМЛ сколько строк это займёт?

ну писали-же тебе //nodename[attribute::attrname="value"]

Ощущение, что слепой

demmsnt ★
()
Ответ на: комментарий от anonymous 

>А MIME - как envelope? 

Окей. Давай сравним передачу данных в виде MIME и посредством XML.

<?xml version="1.0" ?>
<data>
   <foo>
      <bar>1</bar>
      <bar>2</bar>
      <bar>3</bar>
   </foo>
   <baz>boo</baz>
</data>

95 байт, если убрать незначащие пробелы и переводы строк.

Тоже самое, но с JSON:
{ "data" : {
    "foo": [
       { "bar" : 1 },
       { "bar" : 2 },
       { "bar" : 3 }
    ],
    "baz" : "boo"
  }
}
60 байт.

Очевидно, что при большом количестве передаваемых параметров
процент оверхеда у XML будет снижаться.

Теперь давай передадим тоже самое в виде MIME и посчитаем
накладные расходы.

stellar ★
()
Ответ на: комментарий от anonymous

теперь - messaging.

MIME даже не самый простой вариант. HTTP POST.
имеем ключи-значения (вышеприведённые) в теле (urlencoded или base64-encoded).
CGI _уже_ даёт вам всё что надо (ассоц.массивы - фреймы - приходят к получателю за-так. Не надо дополнительного кода. со стороны посылающего - несколько строк, которые вы и SOAP-ом будете иметь)
Теперь - на ХМЛе, пожалуйста...


Здесь ввиду большого количства строк инициализации и построения соап-конвертов - обьявляем:


===============ЕND OF DISCUSSION: XML is bad for messaging==============

продолжать?
(я разрабатывал аналог XSLT в 99 - для построения проприетарного аналога SVG и PDF;) - используется крупнейшим финансовым порталом и сейчас - до 1млн юзеров, можно поспорить и об етом)

anonymous
()
Ответ на: комментарий от anonymous 

>прошу дискуссию о непригодности ХМЛя для конфигов считать на ЛОРе
>закрытой (ввиду очевидной разницы)

Вот тебе решение задачи с двумя наборами пропертей:

<?xml version="1.0" ?>
<config>
    <defaults>
        <address>Moscow</address>
        <sex>male</sex>
        <login>anonymous</login>
    </defaults>
    <users>
        <user>
           <name>Patrick</name>
           <login>st.patr</login>
        </user>
        <user>
           <name>Sabrina</name>
           <login>ss1234</login>
           <sex>female</sex>
        </user>
        <user>
           <name>Anonymous</name>
        </user>
    </users>
</config>

anonymous
()
Ответ на: комментарий от anonymous

>(я разрабатывал аналог XSLT в 99 - для построения проприетарного аналога SVG и PDF;) - используется крупнейшим финансовым порталом и сейчас - до 1млн юзеров, можно поспорить и об етом)

Для начала - представьтесь.

anonymous
()
Ответ на: комментарий от stellar

>Задачу передачи структурированных данных в гетерогенных системах.

А HTTP POST - это разве передача в гомогенной среде?
А ассоциативные массивы-фреймы (+списки) - это не структуры?

anonymous
()
Ответ на: комментарий от anonymous

> Для начала - представьтесь.

Василий Гаврилов. Но системы - проприетарные. А Вас как величать?

anonymous
()
Ответ на: комментарий от anonymous

>MIME даже не самый простой вариант. HTTP POST. >имеем ключи-значения (вышеприведённые) в теле (urlencoded или base64-encoded).

Отлично. Продемонстрируйте *структурированную* передачу XML из поста выше без использования MIME. Что будет ключем, а что - значением?

anonymous
()
Ответ на: комментарий от stellar

>Очевидно, что при большом количестве передаваемых параметров
процент оверхеда у XML будет снижаться.

не очевидно.
а зачем столько пробелов?
потом мой формат - не JSON (это Крокфорда формат), a мой (который в тоже время - стар как мир) - я демонстрировал.

Давайте уж POST, который SOAPовцы используют - чтобы не отдаляться.
(MIMEом вообще-то лучше тыкать в любителей message queue, но это - отдельный разговор, есть что сказать также ;)

anonymous
()
Ответ на: комментарий от anonymous

>Это из Питерского Фаэтона? Вопросов более не имею. ;)

нет

Дык Вы не представились...

anonymous
()
Ответ на: комментарий от anonymous

>А HTTP POST - это разве передача в гомогенной среде?

Видишь ли... В *любой* среде можно передать блок данных. Самый простой способ - write(int socket, const void *buf, size_t nbytes).

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

>А ассоциативные массивы-фреймы (+списки) - это не структуры?

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

anonymous
()
Ответ на: комментарий от anonymous

>не очевидно.

Ну так проведите самостоятельное сравнение.

>а зачем столько пробелов?

Для читабельности. Уберите пробелы, суть не изменится.

>потом мой формат - не JSON (это Крокфорда формат), a мой (который в тоже время - стар как мир) - я демонстрировал.

RFC уже написали?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 4 5 6 7 8
← Веб-браузер Chrome от Google подвержен опасности подмены адреса
Open Source
Интервью с Шатллвортом →