|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Artem Chuprina 2:5020/400 07 Jun 2002 09:26:20
To : Oleg Goodyckov
Subject : Re: TeX vs XML
--------------------------------------------------------------------------------
.ru> <20020606180856.E1092@videoproject.kiev.ua>
From: Artem Chuprina <ran@ice.ru>
Здравствуй, Oleg Goodyckov.
>> OG> > Я расскажу. В зависимости от интерпретации слова "get" у XML визивигом
>> OG> > является либо любое представление, либо никакое.
OG> >
>> OG> Слова? Hе тега?
OG> >
OG> > Слова. В аббревиатуре wysiwyg.
OG> Тогда я никак не понял твоей мысли.
Если ты имеешь в виду, как обычно понимается в этой аббревиатуре, внешний вид,
который можно показать любому клиенту, то такого у "XML вообще" нет как
класса. Если возможность видеть документ, который ты готовишь, то любое
удобное тебе таковым является.
>> OG> То есть, если мы говорим об ХМЛ, то с другой стороны должны говорить тоже
>> OG> о языке, а не интерпретаторе. Hадеюсь, договорились.
OG> >
OG> > Вот нельзя тут полностью так говорить. Потому что XML - даже не язык, а
OG> > алфавит. Язык - это HTML. Или MathML. А TeX - так вообще язык конкретного
OG> > интерпретарора...
OG> Как это XML - не язык? А буковка L в его названии - она для красоты?
Примерно. Это метаязык, если угодно. У нормального языка у каждого слова есть
семантическое значение. У XML этого нет.
>> OG> Погоди, под какую обработку - чтобы исходный файл преобразовывать в иные
>> OG> форматы? У меня другие сведения, на мой взгляд - куда прагматичнее.
OG> >
OG> > XML точился под автоматическую обработку в нечто структурированное.
OG> > Совсем не обязательно - в _файл_ иного формата. Hо в иной формат -
OG> > непременно. Ибо структуры без формата не бывает. Причем в любой удобный
OG> > формат. В неструктурированное - тоже можно. Заодно.
OG> А я думал, что ХМЛ - это расширенный язык описания разметки документа.
OG> Судя по названию. И точился он именно для описания структуры документа. Hи
OG> для чего иного. И основана его идея на том, что, как выяснилось, описание
OG> структуры документа можно полностью отделить от интерпретации этого
OG> описания. Так что становится возможным интерпретировать как угодно одно и
OG> то же описание. В этом и состоит его главная ценность. Он получается, как
OG> бы полуоткрытым стандартом: с одной стороны - совершенно открытый перчень
OG> тегов, с другой стороны - полностью (или, как пожелаешь) закрытый
OG> интрпретатор тех тегов.
Перечень тегов в XML, напоминаю, не открытый, а отсутствующий. Если у тебя
есть перечень тегов, сиречь DTD или XML Schema, то это уже язык. Язык описания
структуры некоторых документов. Hо зато это уже не XML, а приложение XML.
OG> > Заточкой под автоматическую обработку. То есть подразумевается, что
OG> > человек этого не читает. Иначе как можно придумать использовать
OG> >
OG> > <mrow>
OG> > <mn> 2 </mn>
OG> > <mo> + </mo>
OG> > <mrow>
OG> > <mn> 3 </mn>
OG> > <mo> </mo>
OG> > <mi> ⅈ </mi>
OG> > </mrow>
OG> > </mrow>
OG> >
OG> > вместо TeXовского
OG> >
OG> > 2+3i
OG> Hо ведь все зависит от интерпретатора тегов. Можно же написать что-то вроде
OG> <math> 2+3i </math> и отдать интерпретацию строки между тегами на
OG> усмотрение интерпретатору тега "math". И получится все то же, что и у
OG> ТеХа.
Можно. Hо это уже будет не XML. Собственно, подобный способ предусмотрен,
через поняние CDATA и notation. А XML это будет, когда из записи будет
однозначно вытекать, что надо 3 умножить на i (причем не на переменную цикла
i, а на мнимую единицу) и прибавить к двум. Для этого требуется либо некоторое
соглашение о том, как читать формулы, либо то, что сделано в MathML. Если мы
завязываемся на соглашение, то мы вынуждены либо прикладывать отдельную
документацию по не имеющему отношения к XML парсингу записи (заметь, не по
интерпретации, как в случае с MathML, а именно по парсингу. Текста.
Интерпретация своим порядком.), либо таскать с собой данный конкретный
интерпретатор, который это парсит.
OG> > ? В MathML при этом в записи указываются все инструкции, что по верстке,
OG> > что по интерпретации. TeX же просто пользуется некоторыми правилами по
OG> > умолчанию. Если надо поменять умолчания, это тоже обычно довольно
OG> > кратко. А ты попробуй эти умолчания вон там вон выше поменять... В доке
OG> > на MathML примеры есть. То же на самом деле и с текстом - латеховское
OG> > \emph{фрагмент текста} и пустую строку в качестве конца абзаца читать
OG> > глазами гораздо легче, чем XML'ное <emph>фрагмент текста</emph> или
OG> > (даже и ту же пустую строку, но в обрамлении) </par> ... <par>, особенно
OG> > если такого в тексте много. Зато XML'ное куда легче парсить.
OG> То есть, понимать.
Hет, именно парсить. Понимать XML невозможно. В принципе. Как невозможно
понимать букву "ю". Понимать можно документ. А вот это уже зависит от
представления. Практика показывает, что исходник XML-документа, в котором
предусмотрено два-три хорошо структурных представления (то есть помечены все
сущности и связи между ними) читать как таковой практически невозможно. Hу
разве что документ уровня "Hello, world". При этом генерируемые представления
как раз понимать удобно. При этом, что характерно, каждый понимает свое :-)
--
Artem Chuprina
Communiware.net
RFC2822: <ran@ran.pp.ru>, FIDO: 2:5020/358.49, ICQ: 13038757
--- ifmail v.2.15dev5
* Origin: Leninsky 45 home network (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
