Обсуждение:XML

↓

Пожалуйста, добавляйте новые темы снизу

Типы

XML не содержит встроенной в язык поддержки типов данных. В нём нет понятий «целых чисел», «строк», «дат», «булевых значений» и т. д.

Как-то это не совсем верно. XML Schema поддерживает широкий набор типов данных с возможностью определения производных. — Эта реплика добавлена участником IharBury (о • в) 13:08, 19 июня 2007 (UTC)

• я не специалист, но насколько я понимаю, XML Schema - это некое расширение стандарта XML, но не сам язык XML. Другими словами, есть парсеры, которые работают с XML, но "не понимают" XML Schema. Скорее всего, на эту тему нужно сделать отдельную статью. Bibikoff 13:30, 19 июня 2007 (UTC)

Все верно, XML Schema — лишь описание, как проверить XML. --A.I. 13:59, 19 июня 2007 (UTC)

• Это как раз глубочайшая ошибка считать, что XML не содержит встроенной в язык поддержки типов данных. Сам файл XML как раз и представляет собой структуру элементов, с указанием типа данных для каждого элемента. Читайте стандарт. А вот, определение каждого из типов данных находится за пределами самого файла XML (вплоть до варианта «в мозгу» у автора файла XML). Что делать с данным типом данных аккуратно «размазано» по разным точкам, в схемах, в стилях (например, CSS, XSLT), в логике парсера, прикладной программы и так далее.

Объясню. Написано: <name><b>Иванов</b> Иван Иванович</name>. Это означает, что этот элемент - это объект, который содержит данные типа «name». Что и как делать с этим типом, определяется за пределами XML файла. Мы понимаем (по опыту своему), а разработчик документа, то есть в данном конкретном случае Я, точно знаю, что это некий тип, описывающий полное имя человека, в соответствии с этим определяем правила манипуляции с этим участком данных. Внутри объекта типа «name», у нас имеется объект типа «b», по опыту своему мы догадываемся (а я как разработчик точно знаю), что этот тип означает, что данный участок текста должен быть выделен полужирным шрифтом (тип определяет в данном случае не структуру или внутренний формат, а внешнее форматирование), хотя разработчик документа мог иметь ввиду всё что угодно, вплоть до того, что таким образом он просто будет просто означать фамилии, то есть логику. И обработчик документа тоже может относиться к этому типу данных совершенно по своему усмотрению, не взирая на пожелания автора документа, если обработчику написать иную модель поведения. Для согласования типов данных, предназначенных для обмена, обработки и хранения люди и разрабатывают свои стандарты - словари. Например RSS, ФикшнБук и безграничное количество других.

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

Начальный тэг
[40] STag  ::= '<' Name (S Attribute)* S? '>'
…………
Параметр Name в начальном и конечном тэгах определяет тип элемента.
…………
[Определение: Любой элемент, чье начало отмечено начальным тэгом, должен завершиться конечным тэгом, имя которого повторяет тип элемента, указанный в начальном тэге:]

Так, что утверждение, что XML не содержит встроенный язык поддержки типов в корне не верно. Весь файл XML и есть данные, размеченные по типам. А вот логика работы с типами отдана на откуп разработчиков своих собственных систем и словарей. Solomon 23:43, 25 февраля 2008 (UTC)

В догоночку примерчики:

C++: int i=10;

XML: <int id="i">10</int>

В обоих примерах описан объект i типа int равный 10. «Сями», (считайте компилятор по аналогии неким парсером, разбирающим программу, написанную на С++) стандартно определён данный тип int (хотя от разных реализаций языка теоретически можно ожидать разной реакции), стандартом XML определён способ как указать тип, а как его воспринимать и обрабатывать — это дело разработчика и вынесено за пределы самого стандарта. Но парсер пользовательского приложения (так-же как и компилятор С++ в свою очередь), может быть прекрасно осведомлён как обрабатывать данные типа int в данном конкретном файле XML.

Это значит, что в стандарте XML как раз очень замечательно определён механизм типизации данных. И очень жаль, что не многие этого понимают, в том числе и некоторые создатели руководств и самоучителей по XML. Solomon 01:05, 26 февраля 2008 (UTC)

В том-то и дело, что определение типа значения нужно каждый раз реализовывать в XML. --A.I. 14:51, 26 февраля 2008 (UTC)

Стоп. Как Вы сами очень замечательно заметили, что стандарт XML – это не язык разметки, это принцип разметки. То есть сам стандарт не определяет (и это понятная позиция) сами типы данных, он определяет, где они (типы) расположены. Тип данных – это имя тега. Определение типа данных – это уже другой уровень абстракции. Вот в XHTML типы данных определены его стандартом. Образно говоря, есть тип данных «полужирный шрифт», есть тип данных «изображение», есть тип данных «ссылка» и так далее. И браузер основываясь на своих знаниях об этих типах данных уже действует соответствующим образом, точно так же как компилятор С++ встречая int понимает какой это тип данных и что с ним можно делать. Был бы В XHTML тип данных int (была бы нужда) браузер бы это знал.

Вы говорите, что определение типа значения нужно каждый раз реализовывать в XML. Естественно. Но, создавая новый компилятор, назовём его С== на основе, например, сишного принципа организации исходников программ, обработку типов в этом компиляторе (я имею ввиду разработку самого компилятора) тоже придется создавать (и если разработчик захочет, то для своего нового компилятора С== он может определить всё так, как ему будет удобно). Так вот создавая прикладную программу, обрабатывающую некий файл, созданный на основе XML нужно тоже учить эту программу понимать свои типы данных, характерных для этого XML файла.

Стандарт «О принципе организации структуры» принципиально не должен сам по себе, определять какие либо типы данных, ибо в нём заложена как раз такая функциональность, что любые типы данных разработчики вольны вводить в любых количествах без каких либо резервированных слов и применять так, как их душе угодно. То есть создавать свои типы практически без ограничений, даже на иномарочных языках типа русского и китайского. А вот уже внешние механизмы (стандарты) контроля типизации, обработки типов данных, халоженных в тех или иных XML файлах существуют, но отдельной стандартизацией или в рамках прикладных разработок.

Кстати, можно тоже сказать, что язык С++ имеет очень слабую типизацию данных, в нём отсутствуют стандартные типы «полужирный шрифт», «италика», «подчёркивание». Как же так, воскликну я. Почему стандарт C++ не предусматривает столь очевидных строковых типов. (Рассматривайте этот абзац как шутку)Solomon 23:22, 26 февраля 2008 (UTC)

Я думаю разговор про типизированность надо вести в рамках сравнения с другими языками разметки :). Например, с YAML. Дело в том, что есть не только какие-то специальные парсеры, рассчитанные на конкретный DTD, но и универсальные (Например, DOM). И, если мы возьмём для чистоты эксперимента нетипизированный язык программирования, пропарсим XML <is>false</is> , то if ($xml->is) {echo 1;} else {echo 0;} выдаст нам, к сожалению 1 (т. к. «false» было загружено как строка, а непустая строка при преобразовании к boolean = true). --A.I. 08:01, 27 февраля 2008 (UTC)

Произвольные имена тегов

Сравнивать XML и HTML нельзя, поскольку XML — это не язык разметки, а принцип разметки. А вот HTML — это уже язык с набором тегов. По этому нельзя считать задумкой произвольные теги в XML. Дело в том, что есть SGML — тоже принцип разметки, на котором и строиться HTML. --A.I. 04:58, 4 декабря 2007 (UTC)

Но зачем же всё нужно было убивать, в том числе и про интернационализацию. Быть может это нужно было чуть дальше перенести, как это сделано в Английской вики? Это раз. Второе. Далеко не все сразу понимают, что теги внутри XML заранее ни кем не определены. Почему нельзя доступным языком объяснить это людям? Solomon 05:16, 4 декабря 2007 (UTC)

Про i18n нужно указать, но не как отличие от HTML. Разве SGML требовал только восьмибитные кодировки? --A.I. 05:50, 4 декабря 2007 (UTC)

Дело в том, что лучше сразу подавать XML как что-то отличное от HTML. Проводить аналогии только между SGML и XML. А-то часто народ путает HTML и XML. Может отдельный раздел «HTML и XML», где прямо развеем распространённые ошибки? --A.I. 05:50, 4 декабря 2007 (UTC)

Вообще фраза про HTML была совсем не главной. Суть была показать, что эти теги ни кто специально не определил, а мы вольны их придумать сами (если они конечно не определены кем-то заранее, например некими словарями XML). Что начиная разработку собственного XML файла можно применять те теги и атрибуты, которые создатель считает необходимым. Вообще мне нравится структура английской версии этой статьи, что сначала <book>Это книга... </book>, а уже потом что-то более сложное. Solomon 06:16, 4 декабря 2007 (UTC)

Valid (перевод)

Как будем переводить этот термин? Мне кажется, что лучше не действительный, а проверенный Уж очень термин действительный русскому уху не понятен в данном контексте. Solomon 21:31, 13 декабря 2007 (UTC)

Можно валидный :). Проверенный действительно ближе к смыслу, потому что происходит от «проверка» (также valid связан с validation). Но действительный как-то ближе к юридическому языку и звучит тут лучше. Кроме того, действительный уже хорошо закрепилось в литературе :(. --A.I. 23:10, 13 декабря 2007 (UTC)

Не нравится мне этот валидный-инвалидный, хотя я именно валидным его и называю. Эти статьи не всегда читают профессионалы, а зачастую как раз просто интересующиеся, поэтому текст (особенно самая первая вводная часть) должен быть паписан как можно более простым языком, особенно базовые понятия. Как вариант, можно писать правильный, но мне больше нравится проверенный Solomon 05:57, 14 декабря 2007 (UTC)

А мне кажется, что проверенный — не совсем точно. Невалидный документ тоже может быть проверенным, и именно по результатам проверки он признается невалидным. Мне кажется, что лучше оставить слово "валидный", попутно объяснив, по каким причинам использована эта калька. somniator 08:42, 14 декабря 2007 (UTC)

Ну калькировать — это неправильно. Мне кажется, надо использовать «действительный», потому что он имеет юридический оттенок и уже прижилось в литературе. Разнобой терминов от книжке к книжке не способствую обучению :). --A.I. 08:57, 14 декабря 2007 (UTC)

В общем, согласен с действительный, но чуть переделаю абзац про "трудности перевода". Solomon 15:42, 14 декабря 2007 (UTC)

А может всё же правильнее Верный документ? Solomon 16:32, 14 декабря 2007 (UTC)

Это от слова «верить» — вроде немного не тот смысл несёт. --A.I. 21:00, 14 декабря 2007 (UTC)

Может «годный»? Kanapfelka 16:25, 20 декабря 2007 (UTC)

Я думаю, что правильно будет доверительный тип документа. Что же касается перевода как действительный, то эта смысловая ниша уже занята действительными числами, и поэтому нельзя использовать слово действительный для понятия валидный. ozes 17:47, 21 ноября 2013 (UTC)

Пустые теги

Вот выдержка из спецификации

Empty-element tags may be used for any element which has no content, whether or not it is declared using the keyword EMPTY. For interoperability, the empty-element tag SHOULD be used, and SHOULD only be used, for elements which are declared EMPTY.[1]

В соответствии с этим, исправлено. --Nu-Hin 12:20, 25 февраля 2008 (UTC)

Неоднозначность моделирования.

Коллеги! Давайте обсудим недостаток "Неоднозначность моделирования", на котором настаивает уважаемый Участник:Timur.shemsedinov. В общем у меня 4 претензии:

• Это очень похоже на оригинальное исследование. Т.е. хорошо бы дать ссылку на некий авторитетный источник. Например, я скорее не согласен с существованием этого недстатка (Я это не к тому, что я авторитет, а к тому, что существование этого недостатка не самоочевидно).
• Если этот недостаток всё таки существует и подтверждён АИ, то давайте изложим его более высокоуровнево. Т.е. приведённое сейчас объяснение требует от читателя знания XML, что есть плохо. Остальные преимущества и недостатки сформулированы на более высоком уровне.
• Если этот недостаток всё таки существует и подтверждён АИ, то хорошо бы изложить его в 1 абзаце, а не в 5-ти. Очень многословно получилось.
• Если этот недостаток всё таки существует и подтверждён АИ, то хорошо бы улучшить формулировку. Сейчас она страдает некоторой неэнциклопедичностью стиля. Bibikoff 10:54, 5 ноября 2008 (UTC)

Да я бы рад его описать как-то более доступно, но нельзя же объяснить, например, явление интерференции без понимания понятий фаза, частота, когерентность, амплитуда и т.д. Человек так же должен быть знаком с языком формул и понимать смежные физические явления. Я к тому, что перефразировать нужно, но все ровно, это будет доступно только ИТ-специалистам. Вот вариант:

• Неоднозначность моделирования.
  • Нет общепринятой методологии для моделирования данных в XML, в то время, как для реляционной модели и объектно-ориентированной такие средства разработаны и базируются на реляционной алгебре, системном подходе и системном анализе.. (Это дублируется ниже).
  • В результате большой гибкости языка? отсутствия строгих ограничений и общепринятой методологии для моделирования данных в XML формате, одна и та же структура может быть представлена множеством способов (различными разработчиками), например, значение может быть записано как атрибут тега или как тело тега и т.д. Например: <a b="1" c="1"/> или <a b="1" c="1"></a> или <a><b>1</b><c>1</c></a> или <a><b value="1"/><c value="1"/></a> или <a><fields b="1" c="1"/></a> и т.д. Tim Bray, Sun Microsystems, "Using XML in Internet Protocols"
    • Так это недостаток или достоинство? Например в достоинствах написано: "Одновременно с этим, разные разработчики не ограничены в выборе экспрессивных методов (Например, можно моделировать данные помещая значения в параметры тегов или в тело тегов, можно использовать различные языки и нотации для именования тэгов и т.д.);"Bibikoff 22:34, 23 ноября 2008 (UTC)
  • В природе есть множество объектов и явлений, для описания которых разные структуры данных (сетевая, реляционная, иерархическая) являются естественными, и отображение объекта в неестественную для него модель, является болезненным для его сути. В случае с реляционной и сетевой моделями определены процедуры декомпозиции, обеспечивающие относительную однозначность, чего нельзя сказать о сетевой модели. Gustavo Alonso, Swiss Federal Institute of Technology, "Myths around Web Services" page 6
  • Информационная природа различных объектов различна, в разных случаях естественными для формализации структурами будут сетевая, реляционная или иерархическая, а отображение объекта в неестественную для него модель приводит к декомпозиции. XML не поддерживает сетевую модель данных, что приводит к неоднозначности описания. В случае с реляционной и сетевой моделями определены процедуры однозначной декомпозиции. Gustavo Alonso, Swiss Federal Institute of Technology, "Myths around Web Services" page 6
    • В виде XML можно хранить реляционные данные. (А для реляционной модели "определена процедура декомпозиции" ). Мне кажется, что недостатки иерархической модели данных не стоит смешивать с недостатками собственно XML как формата. Приведённая цитата критикует иерархическую модель,а не XML Bibikoff 22:34, 23 ноября 2008 (UTC)
  • Поддержка многих языков в именовании тегов дает возможность назвать, например вес русским словом, в таком случае компьютер ни как не сможет установить соответствия этого поля с полем weight в англоязычной версии и т.д.
    • Поддержка многих языков - не является недостатком. Если бы поддерживался только английский язык- тот же аттрибут "вес" мог быть записан как "weight", "tonnage", "brutto" - да мало-ли синонимов можно придумать к слову "вес". Такие вопросы должны регулироваться схемой данных, а не форматом. Bibikoff 22:54, 23 ноября 2008 (UTC)

Как думаете? Так лучше? --Timur.shemsedinov 12:25, 11 ноября 2008 (UTC)

• • В целом, мне кажется, что информационное моделирование не имеет никакого отношения к формату XML. Информационное моделирование делается без всякой привязки к физической реализации. Для одной концептуальной модели может быть использована и сетевая, и реляционная и иерархическая реализация. Bibikoff 22:54, 23 ноября 2008 (UTC)
  • Например здесь описано различие между логическими и физическими моделями. Bibikoff 06:48, 29 ноября 2008 (UTC)

Дилетантская статья

Эту статью на русском языке, не знаю как на других - писали дилетанты слабо, почти не разбирающиеся в XML. — Эта реплика добавлена с IP 91.78.86.43 (о) 08:58, 22 января 2009 (UTC)

В Википедии самообслуживание. Если Вы не довольны статьёй — перепишите её, ведь Википедии пишется самими читателями. --A.I. 01:07, 23 января 2009 (UTC)

надо чтобы каждый кому не понятно что такое XML кликнул "правка" и сам разобрался

• Википедия:Правьте смело! -- A^VB^talk 07:16, 23 января 2009 (UTC)

"словарь"

а также для создания на его основе более специализированных языков разметки (например, XHTML), иногда называемых словарями.

Я лично впервые слышу, что это называют "словарями". И даже не понимаю, с какого слова из стандарта XML это слово сюда переведено. Есть идеи? Надо исправлять. А то дальше по тексту это неуместное словечко вовсе нещадно эксплуатируется... --Nashev 14:59, 16 апреля 2010 (UTC)

Двоичные форматы быстрее, не надо парсить и экранировать кавычки.

Нужна серьёзная переработка

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

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

Исходя из этого, многие положения статьи требуют пересмотра.

1) утверждения "XML предназначен" могут базироваться только на целях, деклалированных в стандарте (а не на практике его использования). Так, указание на XML как средство "предназначенного" для замены (расширения) баз данных не соответствует заявленным в стандарте целям (хотя в DB2 такое использование имеет место). . Соответственно, логично исключены сравнения XML с реляционным подходом (это более уместно в статье о DB2, например). Равно не врисываются "Достоинства и недостатки", вытекающие из прикладного взгляда не предмет. Грубо говоря, если валенком неудобно резать арбуз, из этого не вытекает, что это недостаток валенка. 2) Сравнения в HTML не вполне уместны, поскольку это средства разного класса. 3) Упоминание о семантике. "Действительный документ дополнительно соответствует некоторым семантическим правилам" Правила носят не семантический характер, они описывают структуру. Вообще освещение XML схем несколько устарело (не ссылается на XML Schema) и не вполне аккуратно. 4)Отображение XML во Всемирной паутине - речь идёт об отображении в браузерах, и эта информация более уместна в статьях о браузерах. 5) Словари XML - что-то непонятное. Можно говорить о разметочных языках с синтаксисом XML. 6) Отдельный больной вопрос: терминология well formed и valid. Честно говоря, не знаю, на какой источник в этом вопросе нужно опираться как на авторитет. well formed - термин, как мне представляется, изначально избыточный, поскольку речь идёт просто о соответствии синтаксису, а соотвествие синтаксису в XML обязательно по стандарту. Масло масляное. Будь моя воля, я бы вообще этот термин на русском не заводил и не употреблял.

Valid, говоря по сути - "соответсвующий схеме". Так бы и говорил.

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

66.234.210.208 05:50, 15 февраля 2013 (UTC) MS

Поскольку стрктура статьи поддалкивает к эволюционному изменению, начну с первых разделов, опираясь в основном на стандарт. Опускаю раздел История. Вот черновик начала

XML (англ. eXtensible Markup Language — расширяемый язык разметки; произносится [экс-эм-э́л]) — рекомендованный [Консорциумом Всемирной паутины] [язык разметки]. Стандарт XML[оригинал, перевод] описывает [XML документы] и частично описывает поведение XML процессоров (программ, обрабатывающих XML документы).

XML разрабытывался как язык с простым формальным [синтаксисом], удобный для создания и обработки документов программами и одновременно удобный для чтения и создания документов человеком, с подчёркиванием нацеленности на использование в интернете. Язык называется расширяемым, поскольку язык не фиксирует разметку, используемую в документах: разработчик волен создать разметку в соответствии с потребностями к конкретной области, будучи ограниченным лишь синтаксическими правилами языка. Сочетание всех этих качеств: простого формального синтаксиса, удобства для человека, расширяемости, - привело к широкому использованию как собственно XML, так и множества производных, более специализированных языков на базе XML, в самых разнообразных программных срествах.

Источники

XML является подмножеством языка [SGML] (это было заявленной целью при разработке языка).

Синтаксис

Стандарт XML предписывает строгое следование определённым в стандарте ограничениям. Специальный термин: "корректный [из русского перевода стандарта] XML документ", - относится к документу, соответствующему всем ограничениям стандарта. Стандарт предписывает XML процессору рассматривать нарушение корректности документа как [фатальную ошибку].

...

Если возражений не будет, перейду к правке.

66.234.210.208 19:25, 16 февраля 2013 (UTC) MS

Раздел История может быть удалён без ущерба для информативности статьи.

66.234.210.208 08:04, 17 февраля 2013 (UTC) MS

Выправил основную часть статьи. Следущий шаг - вычистить и согласовать свежий текст и остальную часть

198.49.180.40 01:28, 21 февраля 2013 (UTC)MS

Второй этап - создать хорошую структуру для описиния трансформаций, визуализации, производных языков и тп. Третий - доработать основную часть и выделить в отдельную статью, сделав основную статью контейнером ссылок. Четвёртый - выбросить всё и написать статью, как для энциклопедии, для непрофессионалов 66.234.210.208 07:17, 22 февраля 2013 (UTC) MS

Структура обозначилась, над тестом ещё можно поработать 198.49.180.40 02:19, 23 февраля 2013 (UTC) MS

После переработки структуры за деревьями появился лес, стало понятнее, как всё-таки нужно структурировать информацию о XML. 1. Язык 2. Правила обработки, языки описания обработки и визуализации, инструменты. 3. Использование и т.д. 66.234.210.208 18:19, 23 февраля 2013 (UTC) MS

Нужна переработка-2

Первичная переработка, заявленная в предыдущем разделе, выполнена. Второй этап - переработка структуры к следуюшему виду:

1. Язык 2. Регламентация работы с документами: правила, языки, протоколы и интерфейсы для работы с документами 3. Инстументы для работы с документами: редакторы, браузеры, парсеры, базы данных 4. Недостатки, персективы развития, альтернативы 5. См. также: примеры языков и протоколов, использующих синтаксис XML 198.49.180.40 16:46, 25 февраля 2013 (UTC)MS

структура верхнего уровня обозначилась, осталось привести содержание в соответствие со структурой и заполнить пробелы, которые теперь очевиднее 66.234.210.208 05:51, 26 февраля 2013 (UTC) MS

Метаязык

Нигде не уточняется, что XML не совсем язык, а метаязык

91.185.61.187 07:54, 18 апреля 2013 (UTC)

Метаязык

Нигде не уточняется, что XML не совсем язык, а метаязык

91.185.61.187 07:54, 18 апреля 2013 (UTC)

"Расширяемый язык" - сказано, и это отражает суть. А "метаязык"? Тут надо разбираться в правомочности употребления этого термина в данном контексте. А нужно ли?

66.234.210.208 06:51, 3 мая 2013 (UTC)MS

Ворпос

Я хочу разобраться, что такое xml читаю статью и очень слабо понимаю язык. Вот пример, фраза "В элементе атрибуты могут использоваться только в начальном теге и теге пустого элемента." это тоже самое что "Атрибуты в элементе могут использоваться только в начальном теге и теге пустого элемента."? Если да, то зачем так писать, ну люди же так не говоря? Я понимаю мастер йода так выражается, но зачем так писать, в этом есть какой-то смысл? Такие обороты встречаются повсеместно. Или: повсеместно такие обороты встречаются. 46.188.122.64 12:26, 30 января 2015 (UTC)

Работа ссылок в оглавлении

При клике на ссылку "пример документа" ничего не происходит. На остальных пунктах оглавления навигация работает нормально. Кто-нибудь знает как поправить ссылку на "пример документа"? 5.165.65.158 23:07, 12 декабря 2015 (UTC)