Коллеги, доброе утро!

Вопрос простой, для тех, кто разбирается в технологиях.

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

Например, нужно обрезать title до 5 символов

<books>
 <book>
  <title>123456</title>
  <author>Me</author>
 </book>
 <book>
  <title>12345</title>
  <author>You</author>
 </book>
 <book>
  <title>1234567</title>
  <author>We</author>
 </book>
</books>

То есть получить вот такое:

<books>
 <book>
  <title>12345</title>
  <author>Me</author>
 </book>
 <book>
  <title>12345</title>
  <author>You</author>
 </book>
 <book>
  <title>12345</title>
  <author>We</author>
 </book>
</books>

Здравствуйте, djyuran, Вы писали:

D>Стоит ли для этого использовать XSL трансформацию или проще и правильнее прогнать его в SAX и записать обратно?

Лично я не стал бы связываться с XSLT. Ибо кака: синтаксис дико многословный, возможности куцые, а в вашем случае — если файл большой — надо также учесть, что оно ещё его и целиком в память в DOM загрузит; в итоге и память сожрёт, и медленнее будет. Я так понимаю, вашим преобразованиям вполне хватит SAX — будет и шустро, и непривиредливо.

Спасибо!

Просто для саморазвития, а в XSLT есть возможность преобразовать в другой формат только часть xml, которую я укажу по XPath?
Или если уже взялся за трансформацию и нужны все тэги из начального документа, их так или иначе придется описывать в XSL?

Здравствуйте, djyuran, Вы писали:

D>Спасибо!

D>Просто для саморазвития, а в XSLT есть возможность преобразовать в другой формат только часть xml, которую я укажу по XPath?
D>Или если уже взялся за трансформацию и нужны все тэги из начального документа, их так или иначе придется описывать в XSL?

Можно часть, разумеется. Синтаксис я уже подзабыл за давностию лет, но что-то типа:

<template match="/"><apply-templates select="/your-subtree"/></template>
<template match="/your-subtree">this goes as output root</template>

По сути это обычное функциональное преобразрование.

D>Стоит ли для этого использовать XSL трансформацию или проще и правильнее прогнать его в SAX и записать обратно?

Стоит, особенно если правила будут меняться и/или добавляться. Поддержка сколько-нибудь значительного числа правил, записанных на Яве, очень быстро превратится в кошмар

Тут тебе писали, что XSLT требует грузить весь документ в память — это не совсем верно.

Есть возможность трансформации SAX потока, например http://www.ibm.com/developerworks/xml/library/x-tiptrax/

Естественно, в данном случае XSLT не может быть написан как угодно, потому что в SAX контексте нет возможности ходить по документу взад/вперед. Для твоего случая — проблем не будет.

Опять же, Ява+SAX в любом случае не панацея — если для твоих преобразований требуется перемещаться по документу, то, очевидно, имплементация на Яве через SAX также потребует переписывания на DOM.

Здравствуйте, avpavlov, Вы писали:

D>>Стоит ли для этого использовать XSL трансформацию или проще и правильнее прогнать его в SAX и записать обратно?

A>Стоит, особенно если правила будут меняться и/или добавляться. Поддержка сколько-нибудь значительного числа правил, записанных на Яве, очень быстро превратится в кошмар

Да даже изменение правила с добавлением зависимости от другой части документа, превратит код на SAX в сущий ад, еще и с большой вероятностью глючный. Я бы юзал xsl, если уж совсем не задница по памяти и производительности, меньше проблем в поддержке будет, да и код не надо перекомпилять при изменениях правил.

А вообще, если задача — не часть продакшновского проекта, а какая-то внутренняя утилита для подготовки кучи тестовых данных(по постановке — вполне может быть), то можно обойтись каким-нибудь вызовом sed "s/<title>(.[0-6]).*?<\/title>/<title>\1<\/title>/g fn.xml" и не парить мозг, оно любой файл, хоть на терабайт прожует моментом. Но только если это внутренняя утилита.

Здравствуйте, Eugeny__, Вы писали:

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

В принципе соглашусь, хотя на практике "код на SAX" в таких случаях достаточно прямолинейно эволюционировал в нечто DSL-подобное, обрастая helper-функциями.