Re: [xml] Improper Type Returned For Repeated Attribute Declaration

On Thu, Jan 10, 2008 at 01:49:42AM +0530, ashwin sinha wrote:

   On  Jan  8,  2008  8:26  PM,  Daniel Veillard <[1]veillard redhat com>

   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
   >      before   Nmtokens   therefore  the  type of a1 should be CDATA.
   >     this  is  not  the  case, while parsing the type associated with
   a1 is
   >      NMTOKENS  and  normalization  is  performed  on  the  attribute
   >      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
        >   output  the  superfluous NMTOKENS definition in the internal
       >   so it seems libxml2 does not store it, which looks good
       > - but as you noted the attribute value is normalized and that's
        >    okay.  If  one  comment  out the NMTOKENS definition in the
     internal subset
        >   then  the  value  is  not  normalized, which is the expected
        >So  for  some reason the NMTOKENS information is not completely
     >  at  parse  time  and  retained  and influence the parsing of the
     >  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
     >  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,

         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,


Red Hat Virtualization group
Daniel Veillard      | virtualization library
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]