From: Jerome <rom...@ya...> - 2013-09-30 19:41:55
|
Hi, I suppose that there two issues with citation references handling around individuals. When I export to Gramps XML, the citation set as child level on the person is missing! ie. it seems that exporting link on citation item (Person editor) is ignored on XML backup. I saw some note references on individuals with citation references on XML export. In fact, the note editor only proposes to select sources handles... I did not look if this can generate a problem after an import, but it looks strange, at least into Note Editor. Jérôme |
From: Jerome <rom...@ya...> - 2013-10-01 07:07:59
|
Into 'def write_person(self,person,index=1)' (ExportXml.py): for citation_handle in person.get_citation_list(): self.write_ref("citationref", citation_handle, index+2) why to use 'index+2'? into 'def write_family(self,family,index=1)' (ExportXml.py): for citation_handle in family.get_citation_list(): self.write_ref("citationref", citation_handle, index+1) we have something which sounds more right? Le lun. 30 sept. 2013 at 21:41,Jerome <rom...@ya...> a écrit : > > Hi, > > > I suppose that there two issues with citation references handling > around individuals. > > When I export to Gramps XML, the citation set as child level on the > person is missing! ie. it seems that exporting link on citation item > (Person editor) is ignored on XML backup. > > I saw some note references on individuals with citation references on > XML export. > In fact, the note editor only proposes to select sources handles... I > did not look if this can generate a problem after an import, but it > looks strange, at least into Note Editor. > > > Jérôme > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from > the latest Intel processors and coprocessors. See abstracts and > register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Jerome <rom...@ya...> - 2013-10-01 07:58:43
|
Good new: it seems that linked citations to individuals are exported into next (index+1) tag! Maybe only if it exists? eg, if this person is parent in a family => <parentin hlink="_a898fbc5cb9619fbeeb"/> <citationref hlink="_c7a3c37de665b0740c8"/> So, minor data loss, but an index and location issue (export/import?). We could have a problem for someone without spouse or at least one parent, and any others records, having a citation. I suppose that is why I got inconsistencies by looking at XML backup files and my family trees? I am checking number of citation references into top level like (people/person). Then compare with number of citation references on attributes for this _person_ (attributes on this _person_, attributes on media objects linked with this _person_, attributes on events linked with this _person_), number of citation references on addresses, on associations, on names, on events linked with this _person_, on note linked with this _person_, on this _person_. Le mar. 1 oct. 2013 at 9:07,Jerome <rom...@ya...> a écrit : > > Into 'def write_person(self,person,index=1)' (ExportXml.py): > > > for citation_handle in person.get_citation_list(): > self.write_ref("citationref", citation_handle, index+2) > > why to use 'index+2'? > > into 'def write_family(self,family,index=1)' (ExportXml.py): > > for citation_handle in family.get_citation_list(): > self.write_ref("citationref", citation_handle, index+1) > > we have something which sounds more right? > > > > Le lun. 30 sept. 2013 at 21:41,Jerome <rom...@ya...> a écrit : >> >> Hi, >> >> >> I suppose that there two issues with citation references handling >> around individuals. >> >> When I export to Gramps XML, the citation set as child level on the >> person is missing! ie. it seems that exporting link on citation >> item >> (Person editor) is ignored on XML backup. >> >> I saw some note references on individuals with citation references >> on >> XML export. >> In fact, the note editor only proposes to select sources handles... >> I >> did not look if this can generate a problem after an import, but it >> looks strange, at least into Note Editor. >> >> >> Jérôme >> >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >> most from >> the latest Intel processors and coprocessors. See abstracts and >> register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from > the latest Intel processors and coprocessors. See abstracts and > register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Jerome <rom...@ya...> - 2013-10-02 07:58:39
|
I will commit the change. No data loss after an export, then a new import. :) Note, the citationref was/were added on lines before (not next). ie. self.write_primary_tag("person",person,index) if person.get_gender() == gen.lib.Person.MALE: self.write_line("gender","M",index+1) elif person.get_gender() == gen.lib.Person.FEMALE: self.write_line("gender","F",index+1) else: self.write_line("gender","U",index+1) self.dump_name(person.get_primary_name(),False,index+1) for name in person.get_alternate_names(): self.dump_name(name,True,index+1) #self.dump_event_ref(person.get_birth_ref(),index+1) #self.dump_event_ref(person.get_death_ref(),index+1) for event_ref in person.get_event_ref_list(): self.dump_event_ref(event_ref,index+1) for lds_ord in person.lds_ord_list: self.dump_ordinance(lds_ord,index+1) self.write_media_list(person.get_media_list(),index+1) self.write_address_list(person,index+1) self.write_attribute_list(person.get_attribute_list()) self.write_url_list(person.get_url_list(),index+1) for family_handle in person.get_parent_family_handle_list(): self.write_ref("childof",family_handle,index+1) for family_handle in person.get_family_handle_list(): self.write_ref("parentin",family_handle,index+1) for person_ref in person.get_person_ref_list(): self.dump_person_ref(person_ref,index+1) self.write_note_list(person.get_note_list(),index+1) for citation_handle in person.get_citation_list(): ... So, it was just leading to stange locations... Most under noteref, parentin, childof. :( I suppose this will also fix my second issue around noteref. Jérôme Le mar. 1 oct. 2013 at 9:58,Jerome <rom...@ya...> a écrit : > > Good new: it seems that linked citations to individuals are exported > into next (index+1) tag! Maybe only if it exists? > > eg, if this person is parent in a family => > <parentin hlink="_a898fbc5cb9619fbeeb"/> > <citationref hlink="_c7a3c37de665b0740c8"/> > > So, minor data loss, but an index and location issue (export/import?). > > We could have a problem for someone without spouse or at least one > parent, and any others records, having a citation. > > I suppose that is why I got inconsistencies by looking at XML backup > files and my family trees? > > I am checking number of citation references into top level like > (people/person). > Then compare with number of citation references on attributes for > this > _person_ (attributes on this _person_, attributes on media objects > linked with this _person_, attributes on events linked with this > _person_), number of citation references on addresses, on > associations, > on names, on events linked with this _person_, on note linked with > this > _person_, on this _person_. > > > > Le mar. 1 oct. 2013 at 9:07,Jerome <rom...@ya...> a écrit : >> >> Into 'def write_person(self,person,index=1)' (ExportXml.py): >> >> >> for citation_handle in person.get_citation_list(): >> self.write_ref("citationref", citation_handle, index+2) >> >> why to use 'index+2'? >> >> into 'def write_family(self,family,index=1)' (ExportXml.py): >> >> for citation_handle in family.get_citation_list(): >> self.write_ref("citationref", citation_handle, index+1) >> >> we have something which sounds more right? >> >> >> >> Le lun. 30 sept. 2013 at 21:41,Jerome <rom...@ya...> a écrit >> : >>> >>> Hi, >>> >>> >>> I suppose that there two issues with citation references handling >>> around individuals. >>> >>> When I export to Gramps XML, the citation set as child level on >>> the >>> person is missing! ie. it seems that exporting link on citation >>> item >>> (Person editor) is ignored on XML backup. >>> >>> I saw some note references on individuals with citation >>> references >>> on >>> XML export. >>> In fact, the note editor only proposes to select sources >>> handles... >>> I >>> did not look if this can generate a problem after an import, but >>> it >>> looks strange, at least into Note Editor. >>> >>> >>> Jérôme >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application >>> performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get >>> the >>> most from >>> the latest Intel processors and coprocessors. See abstracts and >>> register > >>> >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >>> >>> >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >> most from >> the latest Intel processors and coprocessors. See abstracts and >> register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from > the latest Intel processors and coprocessors. See abstracts and > register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Jerome <rom...@ya...> - 2013-10-02 09:30:43
|
Spacing? You are right, that's better! :) ... and this explain why it was properly imported! ;) --- test.gramps 2013-10-01 09:29:20.716572697 +0200 +++ test2.gramps 2013-10-01 10:59:46.179470178 +0200 @@ -5,3 +5,3 @@ <header> - <created date="2013-10-01" version="3.4.6-0.SVN23224:23225M"/> + <created date="2013-10-01" version="3.4.6-0.SVN-last"/> <researcher> @@ -47282,4 +47282,4 @@ <parentin hlink="_a898fbc3dcb0a48c6de"/> - <citationref hlink="_c7a3c368e0202329170"/> - <citationref hlink="_c7a3c36bbe979d27c2c"/> + <citationref hlink="_c7a3c368e0202329170"/> + <citationref hlink="_c7a3c36bbe979d27c2c"/> <tagref hlink="_c0fd9e2a1c5333756a7"/> @@ -65849,3 +65849,3 @@ <noteref hlink="_b36ed044aa81b6e5eaf"/> - <citationref hlink="_c7a3c365c646da59679"/> + <citationref hlink="_c7a3c365c646da59679"/> <tagref hlink="_c0fd9e2a1c5333756a7"/> @@ -66614,3 +66614,3 @@ <childof hlink="_a898fbcdc4314b3535f"/> - <citationref hlink="_c7a3c3688eb1dc35bd9"/> + <citationref hlink="_c7a3c3688eb1dc35bd9"/> <tagref hlink="_c0fd9db176d28646369"/> As said, it was minor (a typo), but maybe leading to errors by handling backup files with ElementTree module? I still need to add something for checking citation references on media object reference (person -> media) and my experimental non-standard gramplet will be complete. Thanks! Le mer. 2 oct. 2013 at 10:49,Vassilii Khachaturov <vas...@ta...> a écrit : > I'm confused with your findings. Why should the wrong index offset to > write_ref make any difference, doesn't it only control the initial > spaces for nicely indented XML hierarchy? AFAIU you shouldn't see any > structural differences. > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from > the latest Intel processors and coprocessors. See abstracts and > register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Vassilii K. <vas...@ta...> - 2013-10-02 08:49:57
|
I'm confused with your findings. Why should the wrong index offset to write_ref make any difference, doesn't it only control the initial spaces for nicely indented XML hierarchy? AFAIU you shouldn't see any structural differences. |
From: Vassilii K. <vas...@ta...> - 2013-10-02 10:29:03
|
I still have hard time understanding this. From the XML parse standpoint, these are the same XML, before and after. We're using expat to import XML, which would take the citationref tags you show in the snippet before the same way. It doesn't care about the leading indent! So if you say you're importing the two XMLs using Gramps XML import and are getting different structure, I think there's some confusion going on with the experiment setup. Also, what is ElementTree module? On 02.10.2013 12:30, Jerome wrote: > > Spacing? > > You are right, that's better! :) > ... and this explain why it was properly imported! ;) > > > --- test.gramps 2013-10-01 09:29:20.716572697 +0200 > +++ test2.gramps 2013-10-01 10:59:46.179470178 +0200 > @@ -5,3 +5,3 @@ > <header> > - <created date="2013-10-01" version="3.4.6-0.SVN23224:23225M"/> > + <created date="2013-10-01" version="3.4.6-0.SVN-last"/> > <researcher> > @@ -47282,4 +47282,4 @@ > <parentin hlink="_a898fbc3dcb0a48c6de"/> > - <citationref hlink="_c7a3c368e0202329170"/> > - <citationref hlink="_c7a3c36bbe979d27c2c"/> > + <citationref hlink="_c7a3c368e0202329170"/> > + <citationref hlink="_c7a3c36bbe979d27c2c"/> > <tagref hlink="_c0fd9e2a1c5333756a7"/> > @@ -65849,3 +65849,3 @@ > <noteref hlink="_b36ed044aa81b6e5eaf"/> > - <citationref hlink="_c7a3c365c646da59679"/> > + <citationref hlink="_c7a3c365c646da59679"/> > <tagref hlink="_c0fd9e2a1c5333756a7"/> > @@ -66614,3 +66614,3 @@ > <childof hlink="_a898fbcdc4314b3535f"/> > - <citationref hlink="_c7a3c3688eb1dc35bd9"/> > + <citationref hlink="_c7a3c3688eb1dc35bd9"/> > <tagref hlink="_c0fd9db176d28646369"/> > > As said, it was minor (a typo), but maybe leading to errors by > handling backup files with ElementTree module? > > I still need to add something for checking citation references on > media object reference (person -> media) and my experimental > non-standard gramplet will be complete. > > > Thanks! > > > Le mer. 2 oct. 2013 at 10:49,Vassilii Khachaturov > <vas...@ta...> a écrit : >> I'm confused with your findings. Why should the wrong index offset to >> write_ref make any difference, doesn't it only control the initial >> spaces for nicely indented XML hierarchy? AFAIU you shouldn't see any >> structural differences. >> >> ------------------------------------------------------------------------------ >> >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >> most from the latest Intel processors and coprocessors. See abstracts >> and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > |
From: Jerome <rom...@ya...> - 2013-10-02 12:47:35
|
ElementTree is a python module (set of modules for parsing XML). I am using it as an alternate way for checking my data. eg, like http://gramps-project.org/2010/01/alternative-interfaces/ So, I thought that something was wrong with '.tail' and printout because values were not consitent on my tests. eg, others samples on http://www.opensourcetutorials.com/tutorials/Server-Side-Coding/Python/xml-matters/page4.html But there was something else with my experimentation (top citationref tag into person, family). ie, I need to use an alternate way for listing these elements... As you pointed out, the fixed issue was *only* around trailing spaces. The problem was that reading previously generated XML files was leading to 'visual' confusion. The identation sounded like a great-child node and the content/structure said that it was a child node. When we are looking at large XML files, we do not always look at closing tags, which are sometimes at the end of the line. Same problem with diff and data on multiple lines: we are trusting indentation. There was a typo, it is fixed: indentation is now consistent according to levels. As said, there is no problem, we can keep it unfixed. It was just a typo, making XML walk or diff harder when we are looking at levels. I was wrong, because displayed nodes (via Element objects) were not 'hierarchicaly' correct, but there was also a typo on code (identation). Le mer. 2 oct. 2013 at 12:28,Vassilii Khachaturov <vas...@ta...> a écrit : > I still have hard time understanding this. From the XML parse > standpoint, these are the same XML, before and after. > We're using expat to import XML, which would take the citationref > tags you show in the snippet before the same way. It doesn't care > about the leading indent! > > So if you say you're importing the two XMLs using Gramps XML import > and are getting different structure, I think there's some confusion > going on with the experiment setup. > > Also, what is ElementTree module? > > On 02.10.2013 12:30, Jerome wrote: >> >> Spacing? >> >> You are right, that's better! :) >> ... and this explain why it was properly imported! ;) >> >> >> --- test.gramps 2013-10-01 09:29:20.716572697 +0200 >> +++ test2.gramps 2013-10-01 10:59:46.179470178 +0200 >> @@ -5,3 +5,3 @@ >> <header> >> - <created date="2013-10-01" version="3.4.6-0.SVN23224:23225M"/> >> + <created date="2013-10-01" version="3.4.6-0.SVN-last"/> >> <researcher> >> @@ -47282,4 +47282,4 @@ >> <parentin hlink="_a898fbc3dcb0a48c6de"/> >> - <citationref hlink="_c7a3c368e0202329170"/> >> - <citationref hlink="_c7a3c36bbe979d27c2c"/> >> + <citationref hlink="_c7a3c368e0202329170"/> >> + <citationref hlink="_c7a3c36bbe979d27c2c"/> >> <tagref hlink="_c0fd9e2a1c5333756a7"/> >> @@ -65849,3 +65849,3 @@ >> <noteref hlink="_b36ed044aa81b6e5eaf"/> >> - <citationref hlink="_c7a3c365c646da59679"/> >> + <citationref hlink="_c7a3c365c646da59679"/> >> <tagref hlink="_c0fd9e2a1c5333756a7"/> >> @@ -66614,3 +66614,3 @@ >> <childof hlink="_a898fbcdc4314b3535f"/> >> - <citationref hlink="_c7a3c3688eb1dc35bd9"/> >> + <citationref hlink="_c7a3c3688eb1dc35bd9"/> >> <tagref hlink="_c0fd9db176d28646369"/> >> >> As said, it was minor (a typo), but maybe leading to errors by >> handling backup files with ElementTree module? >> >> I still need to add something for checking citation references on >> media object reference (person -> media) and my experimental >> non-standard gramplet will be complete. >> >> >> Thanks! >> >> >> Le mer. 2 oct. 2013 at 10:49,Vassilii Khachaturov >> <vas...@ta...> a écrit : >>> I'm confused with your findings. Why should the wrong index offset >>> to write_ref make any difference, doesn't it only control the >>> initial spaces for nicely indented XML hierarchy? AFAIU you >>> shouldn't see any structural differences. >>> >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >>> most from the latest Intel processors and coprocessors. See >>> abstracts and register > >>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >>> >> |
From: Doug B. <dou...@gm...> - 2013-10-02 12:57:08
|
Jerome, Sure you can fix it, but just realize that this is just to make it look good (and I suspect for diffs to show no difference). But the change should have no effect on any program parsing. Thanks! -Doug On Wed, Oct 2, 2013 at 8:47 AM, Jerome <rom...@ya...> wrote: > > ElementTree is a python module (set of modules for parsing XML). > I am using it as an alternate way for checking my data. > eg, like http://gramps-project.org/2010/01/alternative-interfaces/ > > So, I thought that something was wrong with '.tail' and printout > because values were not consitent on my tests. > > eg, others samples on > http://www.opensourcetutorials.com/tutorials/Server-Side-Coding/Python/xml-matters/page4.html > > But there was something else with my experimentation (top citationref > tag into person, family). ie, I need to use an alternate way for > listing these elements... > > As you pointed out, the fixed issue was *only* around trailing spaces. > The problem was that reading previously generated XML files was leading > to 'visual' confusion. The identation sounded like a great-child node > and the content/structure said that it was a child node. When we are > looking at large XML files, we do not always look at closing tags, > which are sometimes at the end of the line. Same problem with diff and > data on multiple lines: we are trusting indentation. There was a typo, > it is fixed: indentation is now consistent according to levels. > > As said, there is no problem, we can keep it unfixed. It was just a > typo, making XML walk or diff harder when we are looking at levels. I > was wrong, because displayed nodes (via Element objects) were not > 'hierarchicaly' correct, but there was also a typo on code (identation). > > > Le mer. 2 oct. 2013 at 12:28,Vassilii Khachaturov <vas...@ta...> > a écrit : >> I still have hard time understanding this. From the XML parse >> standpoint, these are the same XML, before and after. >> We're using expat to import XML, which would take the citationref >> tags you show in the snippet before the same way. It doesn't care >> about the leading indent! >> >> So if you say you're importing the two XMLs using Gramps XML import >> and are getting different structure, I think there's some confusion >> going on with the experiment setup. >> >> Also, what is ElementTree module? >> >> On 02.10.2013 12:30, Jerome wrote: >>> >>> Spacing? >>> >>> You are right, that's better! :) >>> ... and this explain why it was properly imported! ;) >>> >>> >>> --- test.gramps 2013-10-01 09:29:20.716572697 +0200 >>> +++ test2.gramps 2013-10-01 10:59:46.179470178 +0200 >>> @@ -5,3 +5,3 @@ >>> <header> >>> - <created date="2013-10-01" version="3.4.6-0.SVN23224:23225M"/> >>> + <created date="2013-10-01" version="3.4.6-0.SVN-last"/> >>> <researcher> >>> @@ -47282,4 +47282,4 @@ >>> <parentin hlink="_a898fbc3dcb0a48c6de"/> >>> - <citationref hlink="_c7a3c368e0202329170"/> >>> - <citationref hlink="_c7a3c36bbe979d27c2c"/> >>> + <citationref hlink="_c7a3c368e0202329170"/> >>> + <citationref hlink="_c7a3c36bbe979d27c2c"/> >>> <tagref hlink="_c0fd9e2a1c5333756a7"/> >>> @@ -65849,3 +65849,3 @@ >>> <noteref hlink="_b36ed044aa81b6e5eaf"/> >>> - <citationref hlink="_c7a3c365c646da59679"/> >>> + <citationref hlink="_c7a3c365c646da59679"/> >>> <tagref hlink="_c0fd9e2a1c5333756a7"/> >>> @@ -66614,3 +66614,3 @@ >>> <childof hlink="_a898fbcdc4314b3535f"/> >>> - <citationref hlink="_c7a3c3688eb1dc35bd9"/> >>> + <citationref hlink="_c7a3c3688eb1dc35bd9"/> >>> <tagref hlink="_c0fd9db176d28646369"/> >>> >>> As said, it was minor (a typo), but maybe leading to errors by >>> handling backup files with ElementTree module? >>> >>> I still need to add something for checking citation references on >>> media object reference (person -> media) and my experimental >>> non-standard gramplet will be complete. >>> >>> >>> Thanks! >>> >>> >>> Le mer. 2 oct. 2013 at 10:49,Vassilii Khachaturov >>> <vas...@ta...> a écrit : >>>> I'm confused with your findings. Why should the wrong index offset >>>> to write_ref make any difference, doesn't it only control the >>>> initial spaces for nicely indented XML hierarchy? AFAIU you >>>> shouldn't see any structural differences. >>>> >>>> ------------------------------------------------------------------------------ >>>> October Webinars: Code for Performance >>>> Free Intel webinars can help you accelerate application performance. >>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >>>> most from the latest Intel processors and coprocessors. See >>>> abstracts and register > >>>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Gramps-devel mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>> >>>> >>> > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Jerome <rom...@ya...> - 2013-10-02 13:17:42
|
Sure, but it makes wrapping content a little bit different when you want to use a common code for looking at citationref tags on families and people! OK, need to check indentation too. Also, need to take care (length) when you want to use "side-by-side" diff or when you want to use 'grep'! eg, $ grep '\- <citationref' change.diff > removed_citationref.txt Jérôme Le mer. 2 oct. 2013 at 14:57,Doug Blank <dou...@gm...> a écrit : > Jerome, > > Sure you can fix it, but just realize that this is just to make it > look good (and I suspect for diffs to show no difference). But the > change should have no effect on any program parsing. > > Thanks! > > -Doug > > On Wed, Oct 2, 2013 at 8:47 AM, Jerome <rom...@ya...> wrote: >> >> ElementTree is a python module (set of modules for parsing XML). >> I am using it as an alternate way for checking my data. >> eg, like http://gramps-project.org/2010/01/alternative-interfaces/ >> >> So, I thought that something was wrong with '.tail' and printout >> because values were not consitent on my tests. >> >> eg, others samples on >> >> http://www.opensourcetutorials.com/tutorials/Server-Side-Coding/Python/xml-matters/page4.html >> >> But there was something else with my experimentation (top >> citationref >> tag into person, family). ie, I need to use an alternate way for >> listing these elements... >> >> As you pointed out, the fixed issue was *only* around trailing >> spaces. >> The problem was that reading previously generated XML files was >> leading >> to 'visual' confusion. The identation sounded like a great-child >> node >> and the content/structure said that it was a child node. When we are >> looking at large XML files, we do not always look at closing tags, >> which are sometimes at the end of the line. Same problem with diff >> and >> data on multiple lines: we are trusting indentation. There was a >> typo, >> it is fixed: indentation is now consistent according to levels. >> >> As said, there is no problem, we can keep it unfixed. It was just a >> typo, making XML walk or diff harder when we are looking at levels. >> I >> was wrong, because displayed nodes (via Element objects) were not >> 'hierarchicaly' correct, but there was also a typo on code >> (identation). >> >> >> Le mer. 2 oct. 2013 at 12:28,Vassilii Khachaturov >> <vas...@ta...> >> a écrit : >>> I still have hard time understanding this. From the XML parse >>> standpoint, these are the same XML, before and after. >>> We're using expat to import XML, which would take the citationref >>> tags you show in the snippet before the same way. It doesn't care >>> about the leading indent! >>> >>> So if you say you're importing the two XMLs using Gramps XML import >>> and are getting different structure, I think there's some confusion >>> going on with the experiment setup. >>> >>> Also, what is ElementTree module? >>> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >> most from >> the latest Intel processors and coprocessors. See abstracts and >> register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> |
From: Jerome <rom...@ya...> - 2013-10-02 15:26:48
|
> We're using expat to import XML, which would take the citationref tags you show in the snippet before the same way. It doesn't care about the leading indent! My bad! I needed some time to understand that my punctuation and smileys were not clear. To point out that it was only a spacing issue, is better than 'real' level issue, and that is also why I did no see any change on import, because import does not care of spacing. About code, I used dump(), and tail() for listing levels with citationrefs on XML Tree. It was not like with 'diff' + 'grep' commands, where spacing was important (number of spaces with regex), but you feel strange when indentation (screen, despite correct in tree) on dump gives a value which is different than the next Element in memory (iteration). Jérôme Le mer. 2 oct. 2013 at 14:57,Doug Blank <dou...@gm...> a écrit : > Jerome, > > Sure you can fix it, but just realize that this is just to make it > look good (and I suspect for diffs to show no difference). But the > change should have no effect on any program parsing. > > Thanks! > > -Doug >>>> Spacing? >>>> >>>> You are right, that's better! :) >>>> ... and this explain why it was properly imported! ;) >>>> >>>> >>>> >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> |