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

[Marko Vojinovic]

Pozdrav Lazare,

Jeste, potpuno sam zaboravio da treba da te dodam na spisak kolaboratora na GitHub-u...

Evo poslat ti je invitation, pretpostavljam da je to to. ;-)

:-)
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 Fri, 17 Jan 2025, Лазар Радосављевић wrote:

> Договорено!
> 
> Треба онда само да ме додате међу сараднике на Гитхабу (ја сам 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
> 
> 
>