GNOME Bugzilla – Bug 701674
Cannot set bits to make libxml insert default-valued attributes during validation
Last modified: 2013-08-02 13:28:12 UTC
Hi all -- (I sent this in email to libxmlplusplus-list 10 days ago, but it is still awaiting moderation.) (I selected Dom Parser as the component for this bug, but I think it may apply to all parser types.) I'm porting a python (with amara XML framework) application to C++, but I am unable to reproduce a bit of functionality that we depend on -- under amara (and just about any other XML frameworks I've used), if a DTD specifies default values for some attributes, the validation step would create those attributes on the DOM representation of the XML (even if they were not already specified in the input XML text). libxml can do this, but libxml++ is not setting the bits to cause libxml to do this. And, as far as I have been able to figure out, there is no way for user code to set those bits between the time the parser is created and the XML is validated. (I am using DOMParser::parse_memory().) Maybe I've missed something. From reading the source of xmllint (a libxml application that ships with the libxml distribution), it appears the key step is EITHER setting the XML_PARSE_DTDATTR option on the libxml parser before calling the parse function, OR setting the XML_COMPLETE_ATTRS bit in the global C variable xmlLoadExtDtdDefaultValue before calling the parse function. It seems to me that inserting the default-valued attributes should be the default behavior; if the DTD author went to the trouble of specifying them, s/he wants them used. But you may not want to make such a non-backward-compatible change. If you think I'm on the right track I can write a patch -- Thanks, Bob
In the latest version of libxml++, 2.36.0, xmlpp::Element::get_attribute() and xmlpp::Element::get_attribute_value() get both explicit and implicit (default- valued) attributes, but the list returned by xmlpp::Element::get_attributes() contains only explicitly (in the xml file) specified attributes. You want also the default-valued attributes in that list, don't you? I made a quick test by adding XML_PARSE_DTDATTR to the parser options in Parser::initialize_context(), and that did it, as expected. A patch that does not break API or ABI is preferable. It would be implemented quicker than an API/ABI-breaking patch. Now the default behavior (the only behavior) is not to include default-valued attributes in the generated xmlpp::Document. A patch that does not break API must keep that as the default behavior. What behavior is most wanted, depends on what you do with the read xml file, I suppose. If you just want to read it, you probably want all attributes included in the generated Document, as you say. If you want to read the xml file, make some changes to it, and write the changed file back to disk, you might prefer not to have all default-valued attributes added to the xml file. You're welcome to write a patch, I you like.
> I you like. Shall be "if you like."
Created attachment 249368 [details] [review] patch: Parser: Add [set|get]_include_default_attributes() I've made a patch. What do you think, Bob? Is it ok? I'd be glad, if you can suggest a better name than set_include_default_attributes(). Do you think the [set|get]_parser_options() methods in the patch can be useful? If Murray reads this: I suppose I shall make a new 2.36 branch in git before I push a patch like this one. Shall it be called gnome-2-36, like existing gnome-2-nn branches in libxml++? Branches in other packages are named differently, such as glibmm-2-nn and libsigc-2-nn.
Kjell, sorry for not responding sooner. Yes, please branch before adding API, and please use the existing branch name system for the module. I suggest that you go ahead if Bob does not respond.
I have pushed the patch https://git.gnome.org/browse/libxml++/commit/?id=06997287505cb50ec053b216bdc5912e93770a2d