On Tue, Mar 22, 2005 at 08:17:23AM -0500, Rob Richards wrote: > Daniel Veillard wrote: > > > need to be extremely cautious about that part of the code because it > >affects streaming DTD validation for ID/REF(S) checks, even when the node > >have been removed. > > But in general the code need fixing for correct ID/xml:id support when > >mutating trees. Not sure I will have time looking at it now, but if you're > >interested I would take patches of course ! > > > > > From what I can discern, SAX wouldn't have an issue as it is either > building the tree or just passing name/values. Would there ever be a > case where you could have the doc->ids built with no tree? This seem
xmlreader, when I said streaming I wasn't thinking of SAX. > like the only way you could end up with an attribute with no element. As > far as the reader goes, it has its own FreeProp function so it should > never call xmlFreeProp. In the event you grab an expanded node, can the right but one need to double check there. > xmlFreeNode functions be used or is it mantatory to use the reader free > node functions? if you modify a subtree grabbed from the reader you're very likely in anyway to crash the parser or library, people should not do this ! > As far as trying to fix this area, see attached file for an idea of what > I think is a more appropriate direction for this. I believe xmlIsID is using atype might work, yes. I see the idea but the patch looks far from complete as is (I suppose it's expected). > used incorrectly when mutating trees when trying to determine if an > existing attribute is an id or not. xmlIsID/xmlIsRef should really only > be used when determining whether an attribute should be created as an ID > or IDRef, but not for testing whether an attribute is really an ID or IDRef. but what if people already used that function for that purpose in their code ? > Last question on this, as I couldn't find an answer for this anywhere, > is when an attribute which is an ID is unlinked from an element, though > still is associated to a document, is the attribute still an ID or does > it revert to a normal attribute at that point? I can't answer either, the safest would be to revert it. From a DTD perspective it's the (elem name, att name, document) which defines if it is of type ID, but with xml:id it's just the name which defines it. So the rule will have to be adapted depending on this. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ [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
