среда, 28 марта 2012 г.

Экспорт в XML

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

Кодировка

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

Атрибут или тег?

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

Разные теги рядом

Старайтесь не делать таких агрегаций, в которых рядом могут находиться самые разные теги.
<TEXT>
  asdfgh
  <STRBRK />
  ghjlkl
</TEXT>


* This source code was highlighted with Source Code Highlighter.
Самое частое нарушение этого правила - так называемые разделители. Например, в указанном примере <strbrk /> используется как разделитель. Анализ такой иерархии при помощи XSL будет не то что адско, но очень тяжело осуществим. Даже если вы придумаете какую-то хитрую схему для обработки, то все равно XSL-процессор потратит меньше времени на обработку, если бы такой ошибки в проектировании не было.
Избавиться от разделителей можно легко. Например, в нашем случае решении есть такое
<TEXT>
  <STR>asdfgh</STR>
  <STR>ghjlkl</STR>
</TEXT>


* This source code was highlighted with Source Code Highlighter.

Рекурсия

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

Итого

Конечно, не все, обращаясь со сложными XML документами, проходят через описанные трудности. Например, если вы используете .NET, описали структуру документа классом с атрибутами и просто сериализуете/десериализуете свои объекты, то указанные правила вас касаются меньше всего.
Ну а если, вы не используете средства автоматического экспорта/импорта и все таки подозреваете, что пользователи вашего экспорта будут писать XSL-схемы, то у вас есть шанс сделать их жизнь намного проще.

5 комментариев:

  1. Думаю, стоит ещё упомянуть о том, что прежде, чем колбасить XML, нужно сперва определиться со схемой (XSD). А вообще это очень обширная тема, хотелось бы по подробней почитать о проектировании XML.

    ОтветитьУдалить
    Ответы
    1. Думаю, XSD мало кто делает заранее. А вот после по какому-нибудь синтетическому документу с полным набором тегов делают для последующей валидации. VS кстати это позволяет.

      Удалить
    2. Согласен. Расскажу о ситуации, когда схему надо сгенерировать заранее. Например, у нас есть XML и нам нужно получить другой XML, который было бы удобно переварить или что то с ним сделать. Обычно генерируются схемы XSD, по ним с помощью специальных тулзов составляют XSLT и применяют это XSLT к исходному XML. Как пример, можно почитать Дмитрия.

      Удалить
    3. У Дмитрия как раз оба XSD генерятся на основе уже существующих иерархий. В первом случае это XML (HTML). Во втором случае - класс CLR тип. То есть нельзя сказать, что XSD заранее были заготовлены с потолка.

      Удалить
    4. Я и не говорил с потолка. Я говорил о генерации XSD перед XML.

      Удалить