On Thu, Jan 10, 2008 at 01:49:42AM +0530, ashwin sinha wrote: > > On Jan 8, 2008 8:26 PM, Daniel Veillard <[EMAIL PROTECTED]> > wrote: > > On Tue, Jan 08, 2008 at 08:02:29PM +0530, Ashwin wrote: > > > > Hi, > > > > In the attached file the attribute a1 is declared twice > in the > > internal subset. The draft (XML 1.0) says that this is ok, > however it > > is binding that the type of the attribute value should be taken > as the > > first one which occurs in the definition, in this case CDATA > occurs > > before Nmtokens therefore the type of a1 should be CDATA. > However, > > this is not the case, while parsing the type associated with > a1 is > > NMTOKENS and normalization is performed on the attribute > value > > according to the rules specified in the XML draft. However, > ideally in > > this case there should be no normalization and a1 should be > treated as > > CDATA. > > >Hum, yes there is a problem in this edge case: > > - You will notice that when saving the document xmllint will > not > > output the superfluous NMTOKENS definition in the internal > subset, > > so it seems libxml2 does not store it, which looks good > > - but as you noted the attribute value is normalized and that's > not > > okay. If one comment out the NMTOKENS definition in the > internal subset > > then the value is not normalized, which is the expected > behaviour. > >So for some reason the NMTOKENS information is not completely > dropped > > at parse time and retained and influence the parsing of the > attribute. > > I guess using a debugger and following the attribute processing > in the > > start tag SAX handler should allow to find this out quickly, I'm > on > > the road at the moment, not sure I will be able to spend time on > it quickly > > but if you can look for this it would be nice to get this fixed, > > thanks for the report, ideally the document should be stored in > the regression > > suite once the bug is fixed, > > > Hi, > The above problem occurs because on encountering the second a1 > attribute, even though its a duplicate the parser still adds it to the > hash list using xmlAddSpecialAttr, and then while retrieving using the > hash key it fetches the most recent entry of a1 from the hash > list(which happens to be the 2nd Nmtoken a1 entry.) > > I am hoping to fix the problem by adding a global flag which i > will set in case a duplicate attr value is enountered (the check for > duplicate attr value is being done in valid.c), and adding this flag > to the if check before calling the xmlAddSpecialAttr function. Is > there any potiential problem with this fix?
yes global state is really a problem in a library, this should really be avoided, I don't think this scheme can work well, instead the error of duplication should be caught, andpropagated back to the place where xmlAddSpecialAttr is called. I will look at this probably tomorrow morning, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
