[QGHG-it-dev-list] Одговор на Задатак 35 од 2022-11-30: Функције за енкодирање и декодирање xml-стрингова

[Лазар Радосављевић]

Договорено!

Треба онда само да ме додате међу сараднике на Гитхабу (ја сам lazar-rad).
За сад бих могао само pull request да пошаљем.

Поздрав,
Лазар

уто, 14. јан 2025. у 13:57 Marko Vojinovic <vmarko at ipb.ac.rs> је написао/ла:

>
> Pozdrav Lazare,
>
> Srecni praznici! :-)
>
> Super si ovo izanalizirao, nisam znao da je bag u nazivu taga a ne u
> konverziji stringova.
>
> Slazem se da prepravis format tako kako si predlozio (prvo resenje),
> implementiraj ga i
> uploaduj.
>
> A sto se tice funkcija koje si implementirao za konverziju stringova,
> ubaci i njih u
> input_and_output.cpp, bez obzira sto ih ne koristimo. Moguce da cemo ih
> koristiti kasnije,
> jer nesto nisam odusevljen rapidxml bibliotekom, mozda cemo je kasnije
> izbaciti i umesto
> nje staviti neku zgodniju ili napraviti nase lokalno resenje za xml, da se
> ne oslanjamo
> na tudj kod. Ali o tom potom...
>
> Funkcije ubaci u zasebnom push-u, da ih ne mesamo sa onom popravkom
> formata odozgo.
>
> Hvala i pozdrav!
>
> :-)
> Marko
>
>
> Dr. Marko Vojinovic
> Group for Gravitation, Particles and Fields
> Institute of Physics
> University of Belgrade
> ======================
> home page: www.markovojinovic.com
> e-mail:    vmarko at ipb.ac.rs
>
>
>
> On Tue, 14 Jan 2025, Лазар Радосављевић wrote:
>
> > Поштовани,
> >
> > Позабавио сам се проблемом из овог задатка. Написао сам функције које се
> траже и оне лепо раде. Покушао сам онда да их применим у функцијама за
> чување и учитавање симплицијалних комплекса (убацио сам их на она места где
> се уписују,
> > односно дохватају, вредности xml елемената или атрибута) и резултат су
> били потпуно нечитљиви стрингови. Мислим да то има везе с тим што
> библиотека rapidxml има неки свој систем алокације стрингова, који је овим
> путем био поремећен.
> >
> > Међутим, мислим да проблем уопште није био у одсуству ових функција.
> Библиотека rapidxml већ ради конверзију свих „проблематичних” карактера.
> Проблем је у функцији `void save_complex_to_xml_file(SimpComp*, const
> string&)`, у томе
> > како она назива xml-елементе које креира. Наиме, ово је формат
> xml-документа који ће бити произведен:
> >
> > <"complex_name">
> >      <name> "complex_name" </name>
> >      <dimension> "D" </dimension>
> >      <topology> "topology of the complex" </topology>
> >      [<level lvl="l"> "simplices_id_list" </level> ...]
> >      [
> >      <ksimplex id="ksimplex_ID">
> >          <self_level> "ksimplex_lvl" </self_level>
> >          [<color color_type="color_type_id"> "color_value" </color> ...]
> >          [<level lvl="lvl"> "neighbours_at_lvl" </level> ...]
> >      </ksimplex>
> >      ]
> > </complex_name>
> >
> > Име симпкомпа који желимо да сачувамо се користи као садржај елемента
> <name>, али такође и као назив (таг) кореног елемента. По стандарду, називи
> елемената смеју да садрже само алфанумеричке знакове, доње црте, цртице и
> тачке (мада
> > се последња два не препоручују). Друге специјалне знакове, а поготово
> размаке, не смеју да садрже.
> >
> > Такође, називи елемената xml-документа би требало (за конкретну примену)
> да буду предефинисани, а не произвољни. Зато ме чуди то што је стављено да
> се за назив кореног елемента користи стринг који корисник задаје, и који
> може да
> > буде потпуно произвољан. Мислим да би најисправније било да се и назив
> кореног елемента предефинише, као што је случај са свим другим елементима.
> Предлажем да тај назив буде `simpcomp`, јер цео садржај документа и
> представља запис
> > једног симплицијалног комплекса. Име нашег конкретног симпкомпа ће,
> наравно, остати у потпуности сачувано као садржај елемента <name>. Формат
> xml-документа би онда био:
> >
> > <simpcomp>
> >      <name> "complex_name" </name>
> >      <dimension> "D" </dimension>
> >      <topology> "topology of the complex" </topology>
> >      [<level lvl="l"> "simplices_id_list" </level> ...]
> >      [
> >      <ksimplex id="ksimplex_ID">
> >          <self_level> "ksimplex_lvl" </self_level>
> >          [<color color_type="color_type_id"> "color_value" </color> ...]
> >          [<level lvl="lvl"> "neighbours_at_lvl" </level> ...]
> >      </ksimplex>
> >      ]
> > </simpcomp>
> >
> > Алтернативно решење би било да се уведе функција која
> трансформише стринг у облик који је подобан да представља назив елемента.
> Ово је сасвим другачија операција у односу на стандардно xml-овско
> ескејповање. Не би била инвертибилна,
> > мада за тим ни нема потребе. Могла би да се реализује, рецимо, тако што
> би се сви недозвољени знакови заменили доњом цртом, или тако што би се
> игнорисали. На пример, ако смо симпкомп назвали "Ham & Eggs", таг кореног
> елемента би био
> > <Ham___Eggs> или <HamEggs>.
> >
> > Да закључим, ја сам за прво решење, да корени елемент има таг
> <simpcomp>; лакше је, а и сматрам да је боље. Истестирао сам и исправно
> ради. Спреман сам да имплементирам, само чекам одобрење.
> > Срећни новогодишњи и божићни празници!
> > Лазар Радосављевић
> >
> >--
> QGHG-it-dev-list mailing list
> QGHG-it-dev-list at mail.ipb.ac.rs
> https://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ipb.ac.rs/pipermail/qghg-it-dev-list/attachments/20250117/e3882131/attachment.htm>