xmlhack.ru XML-форумы
Обсуждение XML и связанных с ним технологий

Элементы или атрибуты?

На страницу Пред.  1, 2

Автор Сообщение
andy taler
Гость




[5603] Ср Мар 24, 2004 21:02

>> какой валидатор подскажет мне, что в выражении o:margin-left="0.25inсh" в слове "inсh" русская буква "с", а не латинская.

А то же самое в содержимом элемента - по-другому?

>> выражения вида "12px + -.7 pt" обрабатываются плохо
"Чем" плохо? в элементах лучше обрабатываются?

>> Это, конечно же, плохо спроектированный XML">
Следовательно, любые (национальные) литеральные константы в XML-атрибутах ВСЕГДА И ВЕЗДЕ недопустимы (с)Olpa. true?

Да кто мешает хоть так: <outline en:text="songList" ru:text="ПесТни" ../> (море других альтернатив - и интересно, чем вас элементы-то спасают? - на мое имхо, все абсолютно симметрично)

Из 6 примеров нашел 1 (и для меня подозрительный IDREF:
итого применимость правила Olpa = максимум 17%). остальные реальные языки = аaaa.. раз к моему правилу не подходят - скажем, что они bad и брэд!

- но не хотите ли, Olpa, я еще море примеров вывалю?
Мне интересен, в конце концов, реальный процент применимости ваших правил..
olpa
Любитель

Зарегистрирован: 23.04.2002
Сообщения: 981
Откуда: Санкт-Петербург
Посетить сайт автора
[5604] Ср Мар 24, 2004 21:34

Цитата:

>> какой валидатор подскажет мне, что в выражении o:margin-left="0.25inсh" в слове "inсh" русская буква "с", а не латинская.

А то же самое в содержимом элемента - по-другому?


margin-left как элемент выглядит так:

Код:

<margin-left units="inch">0.25</margin-left>


Значения "units" перечислены в DTD, так что валидатор может отловить ошибки.

Цитата:

>> выражения вида "12px + -.7 pt" обрабатываются плохо
"Чем" плохо? в элементах лучше обрабатываются?


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

Цитата:

>> Это, конечно же, плохо спроектированный XML">
Следовательно, любые (национальные) литеральные константы в XML-атрибутах ВСЕГДА И ВЕЗДЕ недопустимы (с)Olpa. true?


В большинстве случаев -- true.

Цитата:

Да кто мешает хоть так: <outline en:text="songList" ru:text="ПесТни" ../>


И при появлении немецкого языка добавить "de:text" и обновить скрипты, обрабатывающие XML?

Цитата:

и интересно, чем вас элементы-то спасают


Хотя бы возможностью прицепить атрибут "xml:lang" или "locale".

Цитата:

Из 6 примеров нашел 1 ... максимум 17%


Из того, что из n специально выбранных элементов множества неким свойством обладает k элементов, не следует, что во всём множестве этим свойством обладает k/n% элементов.

Цитата:

Мне интересен, в конце концов, реальный процент применимости ваших правил.


Моё дело предложить эффективный критерий. Дотошно считать проценты -- это не ко мне.
andy taler
Гость




[5605] Чт Мар 25, 2004 11:02

>> margin-left как элемент выглядит так [skip]:

Этот пример стоило бы поделить на несколько "отдельных вопросов":

1) элементы vs атрибуты (тема треда). Тогда конструкцию

Код:

<margin-left units="inch">0.25</margin-left>

вам следовало бы сравнивать исключительно с нечто вроде

<margin-left units="inch" value="0.25"/> . Не так?


Иначе это называется "нечестная подмена понятий". В чем именно bad последняя (конструкция "атрибуто-конечников")? Чем >0.25< лучше? Гм, где наконец (отдельно от пп. 2-3-4 ниже), ваша центральная лемма вида "ID-IDREF etc"???

2) вопрос валидации: вопрос валидации - это отдельный от темы треда вопрос (почему - see пункт 1 выше: да, она "обязательна" вам, но почему считать, что вообще всем?). Плюс пример выше к "ID-IDREF etc" вообще не имеет отношения, следовательно, вашими словами, этот пример точно в такой же мере off-topic, как и Linguistics. Не согласны?

3) Пополнение ваших правил по ср. с "начальной базой".

Цитата:

>> Вместо того, чтобы пихать всё в атрибуты, я рекомендую использовать следующий подход:
Если же вы уверены, что объект данных будет оставаться уникальным, придерживайтесь атрибутов


Первое сообщение в треде всегда принято считать "постановкой вопроса". Там, в т. н. "вашем подходе" про валидацию (локализацию), etc не было сказано ни слова. Во-первых, так никогда не поступают - не меняют правил в процессе. Какому собеседнику/читателю это может понравиться? В ЛЮБОМ случае вы _ДОЛЖНЫ_ были (понятны ли два выделенных слова?) сначала предложить "связную, но платформу" (пусть без деталей), а не выставлять вперед "какие-то голые IDREF" (и сейчас - ГРОШ цена этому вашему тезису "уникальности") - куда он растворился? А во вторых.. Вот когда ваша "полная база правил" дорастет хотя бы до числа 384 (а потом скатится обратно, но перейдя в некие другие координаты) может быть, вот тогда и поговорим, но с других позиций, а? (можете считать as a joke, но тем не менее.. ну вы, наверно, понимаете?)

4) Аспект ваших взаимоотношениях с _реальным_ языком (равно как с почти с всеми другими ЖИВЫМИ языками). Итак, в своих ответах вы _соглашаетесь_, что

Код:

 1) мир реальных XML-языков "сделан атрибуто-конечниками"

(2) что мир реальных XML-языков вашему треду/постановке/теории/практике(добавить/изменить) в большинстве случаев явно _НЕ_ соответствует (либо ваши формулировки ему). НЕ так?


>> Когда подобное выражение представлено...
повторение пункта 1 выше. на позиции симметрии "элементы vs атрибуты" или на тезис типа "уникальности" АБСОЛЮТНО не влияет.

Цитата:

>> Следовательно, любые (национальные) литеральные константы в XML-атрибутах ВСЕГДА И ВЕЗДЕ недопустимы (с)Olpa. true?

В большинстве случаев -- true.


О! Здесь за честность спасибо.
Следовательно, вы должны признать, что с этой точки зрения почти все "стандарты" W3 являются -bad-xml-designed- (с т.з. Olpa!) или, по кр. мере, явно противоречат его best-practice как "xml-Разработчика".

примеры: (OWL, w3"стандарт", принятый десятками тысяч xml-разработчиков (как и вообще все-все-все языки, основанные на rdf, являются, согласно 'теории уникальности' Olpa, "УЖ-Ж-АС")

Код:

<owl:Class rdf:ID="Журнал">
  <owl:equivalentClass rdf:resource="Публикация"/>
</owl:Class>


Язык XSLT:

Код:

<xsl:template match="Журнал">  := УЖ-Ж-АС! (с)Olpa, выше


Тезисы Olpa сейчас явно олицетворяют дилемму: Olpa vs 'остальной xml-мир'?

Не так? С другой стороны, если OWL или RDF или XSLT not-bad для 'стандартов' W3, почему это вдруг OPML 'bad'?? Далее, если все это допустимо для W3 или OPML, с какой стати это недопустимо для Васи Пупкина?

Вообще, в чем смысл данного треда? Если ID и IDREF меняются то на "это стандарт и не наше дело", то на локализацию, то на валидацию, теперь что вместо тезиса ID/IDREF или элементов/атрибутов мы еще рассмотрим?

Цитата:

>> Моё дело предложить эффективный критерий.


критерий ЧЕГО?..
если почти весь XML на земле (ну, кроме конкретно ваших систем) автоматически является "BAD", и менять эту ситуацию или обсуждать ее С-ВАШИХ-ПОЗИЦИЙ никто, кроме Вас, кажется, не собирается?
olpa
Любитель

Зарегистрирован: 23.04.2002
Сообщения: 981
Откуда: Санкт-Петербург
Посетить сайт автора
[5606] Чт Мар 25, 2004 11:44

Рене Декарт писал(а):

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


А про бездумное применение методов:

народ писал(а):

Научи дурака богу молиться, он себе лоб расшибёт.


Кто занимается практикой, а не только теоретизированием, тот оценит применимость (или неприменимость) подходов. Кто хочет заниматься абсолютизацией высказываний, пусть занимается высказываниями.
andy taler
Гость




[5607] Чт Мар 25, 2004 11:47

Ткаченко очень кстати подкинул цитату:

http://lists.xml.org/archives/xml-dev/200006/msg00285.html

Цитата:

do most of you out there use element-based or
> attribute-based xml? why?

Beginners always ask this question. Those with a little experience express their opinions passionately. Experts tell you there is no right answer. Mike Kay (Jun 2000)

- для того, кто не читает по ихнему --

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

Майкл Кей


taler: возможно, в дискуссии выше я тоже не всегда "остаюсь прохладен". Но я защищаю права обоих подходов, никак не доминанту любого из них или "обвинения в конечности": об симметричности и "вводных" на эти темы все произнесено мной давно, равно как и то, что это - сложная комплексная "теория XML-дизайна", а не каких-то ID.
Гость





[5638] Пт Апр 02, 2004 19:46

ну развели спор..
атрибуты сдецл нарушают ортогональность модели хмл, но отказацца от их использования означает придти к некому подобию реляционных таблиц, следовательно аттрибуты следует использовать в качестве например идентификатороф и т.д.(что и говорилось выше).. но когда не важно чёткое следование и важна производителось(например обрабатывать терабайты хмл дата Smile)) можно попробовать стать атрибутчиком)
И потом, "насыщенный аттрибутами хмл" всегда можно привести к менее "насыщенному", собственно в чём проблема?
Гость





[5640] Пт Апр 02, 2004 21:24

нельзя поподробнее про сдецл-ортогональность и порчу?

>> в чём проблема?

Проблема простая: оставлять дурацкий rdf:about в своих разработках для совместимости с rdf или не надо? каковы советы?
flax
Аспирант

Зарегистрирован: 31.01.2003
Сообщения: 100
Откуда: Minsk
[5679] Чт Апр 15, 2004 14:11
не нравится.....
не нравится мне все это. Словно, тем не менее, что-то остается недосказанным, и я не могу ухватить, что же именно, такое важное так и не входит из тени.

Итак, приведу просто свои некоторые отрывочные мысли:


    Olpa писал(а):


    Лингвисты пусть занимаются естественными языками, а не протоколами обмена информацией.


    Здесь довольно тонкий момент.
    Вопрос:Кто занимается определением объектного дизайна всего проекта?
    Ответ: Обычно проектировщик + с сотрудничестве с системным аналитом ( или по некоторым требованиям, которые аналитик смог выяснить у клиента).

    Вопрос: Проектировщик это программист?
    Ответ: Скорее нет, чем да...При проектировании достаточно больших систем, естественно, нужно знать возможности технологий ( до некоторой степени), и безусловно нужно иметь опыт во всякого рода DesignPatterns, Refactoring, UML, (DataBase/OO Mapping), и необходимо "чувство" понимания гармоничности программного дизайна, но отнюдь не обязательно знать API каких-ть GUI библиотек и серверных продуктов.

    Вопрос: Системный аналитик это проектировщик?
    Ответ: Вряд ли, хотя он должен знать основные принципы (от IDEF\UML, классификации корп. систем). Для аналитика важно уметь производить декомпозицию системы, видеть ее составляющие ( и здесь не все голословно : начиная от "морфоящиков" характеристик, и заканчивая, возможно, "этапами развития систем" (like ТРИЗ) и более глубокими). Плюс большая степень коммуникации для работы с заказчиком и составлении грамотной и законченной модели (view). (про математику и всякие nonstandard methods уж не будем )

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

    Конечно, в достаточно малых коллективах, один единственный программист может пытаться играть несколько ролей. Но в больших проектах вряд ли можно все делать одновременно ( В частности, я не против eXtremeProgramming, но у меня присутствует определенный скептицизм к тем организациям, у которых нет отдельных тестировщиков. Иногда ([skiped]) программисты не смогут провести полноценное(полный цикл) тестирование ([skiped]) или это будет стоить очень дорого.

    Итак,
    Вопрос: кто из перечисленных людей должен заниматься форматами протоколов обмена ( обмена с __внешней__ средой)
    Ответ: Ключевое слово "внешняя", и поэтому, в этой классификации первоначально разрабатывать формат обмена должны 1) проектировщик (чтобы этот формат был расширяемый и удобный) и 2) системный/бизнес аналитик ( так как мы имеем взаимодействие с чужой стороной)

    ТАким образом, форматом взаимодействия программист ( понимая его в узком смысле, а не в том, который, наверное, имел ввиду Olpa) непосредственно НЕ занмается. Он может принять участие в рефакторинге, но он не определяет первоначальый образ. (случай и швец и жнец -- мы не рассматриваем)


    Едем дальше:
    в расшифровке XML упорно мелькает слово language. Действительно, вы естественно встречались с "в серьезных проектах не следует полагаться на автоматическую генерацию WSDL". Приведу несколько умозрительный пример, подтверждающий, в некотором смысле, эту точку зрения:

    Почему же не всегда стоит полагаться на автоматическую генерацию WSDL. Ведь с одной стороны, сервис генериться по уже построенной ( а значит и продуманной) иерархии классов. Оформление(публикация) ваших функций с параметрами (soap in , soap out + bind with tcp) вряд ли может быть сделана руками лучше, чем автоматически. Здесь нет зазора для импровизаций. Однако в WSDL, кроме описание собственно сервисов, присутствуют куски (схемы) описания ДАННЫХ, которыми будут обмениваться программы. Весь вопрос в них.
    #start IMHO section

    У нас сейчас возникала похожая ситуация, возможно проблема в знаниях сервисов , но...
    Для того, чтобы (при автоматической генерации) опубликовать схемы и определения данных, пришлось (как самый легкий путь) определить соответствующие объекты на сервисе. После Reflection их на схемы в WSDL и дальше при отображении их в пользовательские заглушки на клиенте, оказалось, что cхемы объектов (между которыми были смысловые связи [skipped]) в WSDL оказались описанными совершенно отдельно. Т.е в нашем случае вернее -- описать смысловую модель данных, и возможно сделать их обвязку кодом по доступу и изменению параметров, но не наоборот.

    Хотя здесь может весь вопрос в кривости рук....
    #end IMHO section

    Более того, есть небольшое подозрение, что ХОРОШИЙ XML ДИЗАЙН не может быть получен путем отображения ХОРОШЕГО ОО ДИЗАЙНА на схемы.

    Хотя .net Reflection утверждает обратное, но если вообще говоря не иметь "канонического" отображения, то (по крайней мере при проектировании), похоже, что это разные миры.
    [skipped]


    Итак, я хочу высказать идею, что по крайней мере с позиции проектирования, XML design != OO design, т.е МЕТОДЫ для первого пока не сформулированы нормально ( но мне кажется, что ! придет день)

    Следовательно, XML дизайн может делать человек, которому эти вещи более знакомы. "Лингвист" звучит грозно, но я согласен на 100% что в идеале это должен делать(принимать сильное участие) лингвист.

    Надеюсь, я смогу привести доводы, почему это так...

flax
Аспирант

Зарегистрирован: 31.01.2003
Сообщения: 100
Откуда: Minsk
[5683] Пт Апр 16, 2004 10:24
не нравится....
Уперлись в эту уникальность...


    Мне кажется, что вопрос вовсе не в уникальности, точнее, уникальность влечет, но сама по себе не является общей причиной использования\неиспользования атрибутов.

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

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

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

    Пример:

    Код:


    This Term Class is not so stupid that <definition href="KnowledgeBase/Term Class/class[@name={.}]">Hannover Term Class</definition>


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

    Более того, если вы сможете на некотором синтаксисе $^#***))))) ---* выражать те отношения, которые предоставляет XML (<?>интересно какие отношения выражает вложенность элементов, порядок итд</?> ) , то вы так же сможете работать и с атрибутами. Единственная проблема в том, что существующие методы контроля (например схемы) заточены под элементы, и в случае, если вы выражаете нетривиальную семантику в атрибутах, то вам самим придется писать соответствующий софт для проверок

    #Offtop
    Так например как в проигнорированном всеми вопросе про контроль XPAth
    #/Offtop

    Taler писал(а):


    1) WordML: ... w:left="720".. w:pos="2880".../>
    это id или idref ? или это опять перечислимые типы?

    2) Ok, не нравится Микрософт, берем ОpenОffice:
    <style:properties fo:font-family="Courier" fo:margin-left="0.25inch" fo:font-size="11pt"/>

    3) XBRL: <xbrli:numericContext precision="12" cwa="false">
    допустим, cwa-перечислимый, precision="12" тоже??

    4) OPML: <outline text="songList"> <outline text="It's XML, of course">
    это id или перечислимый?

    5) XFORMS: <xforms:setvalue ref="/stockData/account/stock/value" ...
    это id или перечислимый?


    и особенно

    Цитата:


    6) SVG: <rect x="450" y="150" width="100" height="100">



    Если не планируется расширения (или некоторых косвенных расширений, как с lang ) , то такая ситуация вполне возможна.


    // но вопрос не в ID, он только влечет нечто большее

    Хотя вместимость семантики - это только и одна из причин и граней...



и мне опять таки продолжает чего-то в этом всем не хватать. Sad
andy taler
Гость




[5684] Пт Апр 16, 2004 12:04

(ps1): если вы насчет моих мнений, то на сложные (ды уж и любые) темы мне было бы куда удобнее беседовать на raleigh, дабы не чувствовать дискомфорта скованности, наездов off/не-off-topic, а намного важнее (имо) - совершенного непонимания и ужасно душной атмосферы, которую всей кожей чувствую в трактовке "зачем вообще нужен xml" со стороны хозяев форума. Здесь же, на hmlhack - no, даже не хотел бы лишний раз нарушать (и так часто нарушал) право хозяев проповедовать миру что-и-как хочется..

(ps2): ваши текущие формулировки на самом деле выходят далеко за рамки обусловленной названием темы - и в данном случае какой-угодно администратор всегда будет прав

2. потому исключ. про то место, где был задан (единственный) вопрос:

Цитата:

>> интересно какие отношения выражает вложенность элементов, порядок итд</?> )


имховая формулировка как ответ: В стандартном XML-смысле = ничего другого не может, не выражает и не несет _абсолютно_, за исключением "вложенности элементов; порядка; итд"(!)

Но нужно понимать, что любая знаковая система вообще не выражает ничего сама по себе, до той поры, пока ее кто-то/что-то не начинает 'интерпретировать'. А при интерпретации, извините, даже классическое "мама мыла раму" может выражать/означать вовсе не труд некого лица в статусе матери над неким деревянным объектом, а, скажем, явно-узнаваемое реципиентом намерение отправителя соотнести субъект сообщения с шаблоном грамматики 1-го класса нач. школы и т.п. А вот если это ХОРОШО понимать, то вложенность элементов может выражать не только и столько вложенность, сколько (и уже многие делают), к примеру 1) метафору/модель деревянных (отличать от "строгих иерархий") структур (в разных разрезах) 2) вложенность в контейнерных смыслах ; 3) отношения "has-a" или part-of - это тоже другое и все еще не иерархии; 4) метафору/модель иерархических классификаций (типы/классы) 5) все дальнейшие трактовки - там есть, куда расти...
olpa
Любитель

Зарегистрирован: 23.04.2002
Сообщения: 981
Откуда: Санкт-Петербург
Посетить сайт автора
[5686] Сб Апр 17, 2004 21:57

Цитата:

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

...

Если не планируется расширения (или некоторых косвенных расширений, как с lang) , то такая ситуация вполне возможна.



Верно подмечено, что атрибуты и элементы несимметричны: к атрибуту не прицепить дерево (или приходится вводить дополнительную не-XML разметку).

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

Теперь про загадочных "лингвистах". Ален Голуб пишет:

Цитата:

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

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

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

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



Так вот. Если человек называет себя лингвистом, отсюда не следует, что он обладает организационными способностями и языковой подготовкой (точно так же, как многие не являются программистами, дизайнерами и т.д.), а уж тем более неочевидно, что он имеет представление об особенностях разработки языков для ПО. Гораздо проще найти толковых программистов, имеющих светлый разум и способность донести мысли. Они и есть Архитекторы ПО.

Вторая часть этого письма не имеет никакого отношения к теме (elements vs attributes).
andy taler
Гость




[5688] Вс Апр 18, 2004 11:09

разве кто просил здесь писать об "организации процесса программирования",
если этот форум посвящен XML?

Бизнес профессии программиста - частный случай бизнеса - с какой стати его путать с XML, и совершенно НАГЛО (*сорри, это не оскорбление, но просто не вижу другого способа обратить внимание на корень разногласий) и злоупотребляя правами администратора форума, всегда ставить "view" программиста во главу угла? На эту тему taler писал на xml.hack океан - и разумеется, оберегая честь мундира, только "истинный programmer" может продолжать делать вид, что не заметил, не видел и ничего из этого не читал.

Прекрасная иллюстрация предвзятости: цитаты:

Цитата:

1) >> первый шаг в написании любой ПРОГРАММЫ...
2) >> мат. подготовка почти не нужна в компьютерном ПРОГРАММИРОВАНИИ...
3) >> Здесь я делаю различие между информатикой (computer science) - математическим анализом компьютерных ПРОГРАММ - и программированием или РАЗРАБОТКОЙ ПО...
4) *программирование* требует...

5) И пишет сам Olpa: >> Так вот. Если человек называет {skipped}.. тем более неочевидно, что он имеет представление об особенностях разработки языков для ПО.


Кто бы спорил? и нужно, и важно все (кому-то..) .. вот только с какой стати подменять всем этим понятие "XML"? Кому не заметно, насколько в сообщении Olpa часто (зло)употребляет[*] словом "Программирование"?

особенности разработки языков для ПО? - гм... - но только Olpa хочет так думать, что XML - вспомогательная вещь для {при} *производстве программ*, а не наоборот)... Какие-такие "архитекторы ПО" ? Причем тут "языки для ПО"?

taler (для уровня второго класса):

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

Язык программирования можно представить как то, что берет определенную информацию на входе, производит над ней некоторые действия, затем выводит полезный результат. Говоря о языках программирования, в основном, их *исполняют*.

По сравнению с языками программирования, разметка совсем-совсем другое. Она служит для идентификации частей документов, предназначенных для *передачи* информации. То, что записано на языке разметки, не способно _исполняться_, и можно лишь надеяться, что ее тем или иным образом "применит" некое (и в первую очередь *чужое*) ПО. Разметка предоставляет лишь удобные и унифицированные форматы ОБМЕНА (отличать от обработки) информации.

[*]:(за приставки сорри, но у меня нет других слов, и нужно понимать, что это еще мягко)
andy taler
Гость




[5689] Вс Апр 18, 2004 11:24

Шен Мак-Грет:

Цитата:

".. Общеизвестно, что современная Интернет (электронная) коммерция базируется на концепции кодирования* заказов/счетов и других жизненно-важных бизнес-документов на языке XML. Но не так хорошо известно, однако об этом говорят исследования, что базовые концепции разметки счетов были известны еще в запредельной античности. Мы пока не можем сказать точно, когда эти концепции зародились, но хорошо известно, что они были в использовании во многих местах по крайней мере 15-17 тыс. лет до н. э... Мы знаем это, например, из экстенсивного изучения наскальных рисунков в пещере Альтамира в Испании или в пещере Ляско во Франции, ясно указывающих на факты взаиморасчетов, размеченных в XML** и с ясно идентифицируемой семантикой "кто покупатель, и кто продавец"..


(*) encoding в оригинале, NOT "processing" - специально для Olpa
(если только Olpa понимает слово NOT).
(**) - это не описки автора или мои

(taler: это совсем не 1-е апреля или раздел humorа)
amdy taler
Гость




[5690] Вс Апр 18, 2004 11:45

XML не язык программирования ! (сегодня тысячи статей на эти темы)

Типичный пример с данного форума - Olpa интересуется, видите-ли, как ему "кодировать" локализацию. Когда речь об "ОБМЕНЕ", люди "обмениваются" на одном конкретном языке, они не передают код обмена с одновременно всеми терминами и на "ru", и на "de" и на "jp" и тп!

Передать в xml = любому достаточно на ОДНОМ (конкретном) языке. Ну, если очень надо, тогда, к примеру, легко передать одновременно получателю пакет доков на трех разных языках - все всегда так делали. Поэтому "проблема локализации", если в XML и существует, то асбсолютно не в том ключе, как ее хотел бы представить программист Olpa, не способный открыть глаза на что-то другое, чем "типовые до этого парадигмы ПО".

И обратно, если кого-то xml "нужен не для ОБМЕНА, а для хранения (частного хранения) или ОБРАБОТКИ (частной его) обработки", так это никогда не было целью XML, и это НЕ его (XML) проблемы (yes, это действительно проблемы программиста Olpa, не XML, и кого это должно волновать?)


Тим Брей - автор формальной спецификации XML:
=================================

Цитата:

(вопрос): Правильно ли, что любая компания, рассчитывающая на успех, должна найти свой магический баланс между истинной XML-интероперабельностью и вкладыванием достаточного соуса из собственных секретов, дающих ей некие преимущества?

(ответ): Абсолютно. Если вы несете на рынок приложение и размахиваете XML флагом, для меня это означает прежде всего, что как на входе вы принимаете в XML, так и отдаете мне обратно информацию в XML, ничего из двух не урезая. А что там делается внутри в вашем приложении - это ваши личные заботы, которые совершенно никого не волнуют. Волнует - помогает ли мне ваш продукт в бизнесе так, как я этого хочу...

Например, что касается моей компании, то мы и получаем в XML на входе, и отдаем XML на выходе. Но внутри у нас вообще нет никакого XML: там исключительно наши собственные структуры данных. Реальная сила XML проявляется только ВОВНЕ, с целью обмена.
! (знак восклицания)


XML not язык программирования ! (тысячи статей на эту тему
и десятки моих сообщений на данном форуме)
========================================

ps 2 flax: Но я хорошо понимаю, что мне никак не переубедить здесь лиц, собак съевших на "организации процесса *программирования*. Вот почему я обращаюсь еще раз к FLAX'у, если все-таки могут появляться желания обсуждать что-либо без шор, навязываемых "десятками лет программистского мышления", то лично мне это было бы _НАМНОГО_(как вы этого не поймете?) нейтральнее на raleigh.ru
Читатель2
Гость




[9893] Сб Июн 03, 2006 09:25
Ну и маразм
Ой, ееееее... Ну давайте теперь в таблицах SQL программы писать. Их тоже можно интерпретировать, считывая значения и преобразовывая их в операции. Афигетьблин.