Subject: Re: XML::LibXML & Namespaces - msg#00049

Previous Message by Date: click to view message preview

Re: XML::LibXML & Namespaces

Matt Dainty wrote: Could someone be so kind as to point out what I'm doing wrong? The parsed in document is behaving correctly IMO, but the built up document doesn't appear to be passing the namespace of an element onto it's children, such that any child element I create without specifying a namespace, doesn't have one rather than inheriting it from its parent. Yep. What's happening is that by using $doc2->createElement('B'), you are creating a node with NO namespace (or null, or whatever), even though when you print it out, it looks correct, as though it gets the default (inherited) namespace. Actually, the DOM specification warns against mixing the namespace-aware and namespace-UNaware methods, presumably for just this reason. I can fix it by specifying the namespace to all elements I create, but then when I dump out that document, it's riddled with extra xmlns="" attributes which are unnecessary. Yeah, frightening isn't it! (although, at least, the doc is correct) :> The only way I've found so far, is using the method $parent->addNewChild($nsuri,$tag); It creates and adds the element in the context of it's parent, so that it knows exactly what namespaces are visible and avoids creating new internal/redundant namespace nodes (?). Unfortunately it's not part of the DOM spec, and so not portable. Also, you can no longer create nodes in isolation and add them where you want; you've got to put them directly in place. An alternative would be an after-the-fact namespace normalization, but nobody (including myself!!!) has yet written one. It pretty much has to be done at the C level to get access to the actual namespace nodes that libxml2 is using, because there's a lot of pruning that needs to go on; and a lot of care to make sure that the internal structures remain consistent, don't leak memory, etc..... [There is an oddly named reconciliateNS in libxml2, but the documentation doesn't make quite clear that it really does this task... anybody know for sure? It wouldn't seem too hard to add a perl binding to it if it _were_ useful.] The only workaround I can think of is the equivalent of: my $doc3 = $parser->parse_string( $doc2->toString ); ...which would have the desired effect, but strikes me as a bit kludgy. Well, you've demonstrated both resourcefullness and good taste! :> If it's useful, I'm using XML::LibXML 1.58 and XML::LibXML::XPathContext 0.06. My libxml2 C library is 2.6.6 or 2.6.8 depending on the machines I've tried. Cheers Matt -- bruce.miller@xxxxxxxx http://math.nist.gov/~BMiller/ _______________________________________________ Perl-XML mailing list Perl-XML@xxxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Next Message by Date: click to view message preview

Re: XML::LibXML & Namespaces

On Thu, 2004-07-29 at 17:30, Bruce Miller wrote: > Matt Dainty wrote: > > Could someone be so kind as to point out what I'm doing wrong? The > > parsed in document is behaving correctly IMO, but the built up document > > doesn't appear to be passing the namespace of an element onto it's > > children, such that any child element I create without specifying a > > namespace, doesn't have one rather than inheriting it from its parent. > > Yep. What's happening is that by using $doc2->createElement('B'), > you are creating a node with NO namespace (or null, or whatever), > even though when you print it out, it looks correct, as though it gets the > default (inherited) namespace. > > Actually, the DOM specification warns against mixing the namespace-aware > and namespace-UNaware methods, presumably for just this reason. Ah, right, that makes sense now. Okay, so my beef appears to be with the output of my constructed document adding all those extra xmlns attributes. But what logic is going on that when a document is parsed, the current default namespace is inherited correctly? :-/ > > I can fix it by specifying the namespace to all elements I create, but > > then when I dump out that document, it's riddled with extra xmlns="" > > attributes which are unnecessary. > > Yeah, frightening isn't it! (although, at least, the doc is correct) :> > The only way I've found so far, is using the method > $parent->addNewChild($nsuri,$tag); > It creates and adds the element in the context of it's parent, > so that it knows exactly what namespaces are visible and avoids > creating new internal/redundant namespace nodes (?). > > Unfortunately it's not part of the DOM spec, and so not portable. > Also, you can no longer create nodes in isolation and add them > where you want; you've got to put them directly in place. This builds exactly what I want, from a visual perspective, without having to do a toString/parse_string manoeuvre. I shall have to skip DOM portability for the time being, which isn't really too much of an issue. > An alternative would be an after-the-fact namespace normalization, > but nobody (including myself!!!) has yet written one. > It pretty much has to be done at the C level to get access > to the actual namespace nodes that libxml2 is using, because > there's a lot of pruning that needs to go on; and a lot of care > to make sure that the internal structures remain > consistent, don't leak memory, etc..... Something like this which I could run as the last stage prior to output would be handy, and allow me to go back to the DOM-friendly construction methods, although would it make sense to have this stage in the document output methods anyway? Thanks for the pointers. Matt _______________________________________________ Perl-XML mailing list Perl-XML@xxxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Previous Message by Thread: click to view message preview

Re: XML::LibXML & Namespaces

Matt Dainty wrote: Could someone be so kind as to point out what I'm doing wrong? The parsed in document is behaving correctly IMO, but the built up document doesn't appear to be passing the namespace of an element onto it's children, such that any child element I create without specifying a namespace, doesn't have one rather than inheriting it from its parent. Yep. What's happening is that by using $doc2->createElement('B'), you are creating a node with NO namespace (or null, or whatever), even though when you print it out, it looks correct, as though it gets the default (inherited) namespace. Actually, the DOM specification warns against mixing the namespace-aware and namespace-UNaware methods, presumably for just this reason. I can fix it by specifying the namespace to all elements I create, but then when I dump out that document, it's riddled with extra xmlns="" attributes which are unnecessary. Yeah, frightening isn't it! (although, at least, the doc is correct) :> The only way I've found so far, is using the method $parent->addNewChild($nsuri,$tag); It creates and adds the element in the context of it's parent, so that it knows exactly what namespaces are visible and avoids creating new internal/redundant namespace nodes (?). Unfortunately it's not part of the DOM spec, and so not portable. Also, you can no longer create nodes in isolation and add them where you want; you've got to put them directly in place. An alternative would be an after-the-fact namespace normalization, but nobody (including myself!!!) has yet written one. It pretty much has to be done at the C level to get access to the actual namespace nodes that libxml2 is using, because there's a lot of pruning that needs to go on; and a lot of care to make sure that the internal structures remain consistent, don't leak memory, etc..... [There is an oddly named reconciliateNS in libxml2, but the documentation doesn't make quite clear that it really does this task... anybody know for sure? It wouldn't seem too hard to add a perl binding to it if it _were_ useful.] The only workaround I can think of is the equivalent of: my $doc3 = $parser->parse_string( $doc2->toString ); ...which would have the desired effect, but strikes me as a bit kludgy. Well, you've demonstrated both resourcefullness and good taste! :> If it's useful, I'm using XML::LibXML 1.58 and XML::LibXML::XPathContext 0.06. My libxml2 C library is 2.6.6 or 2.6.8 depending on the machines I've tried. Cheers Matt -- bruce.miller@xxxxxxxx http://math.nist.gov/~BMiller/ _______________________________________________ Perl-XML mailing list Perl-XML@xxxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Next Message by Thread: click to view message preview

Re: XML::LibXML & Namespaces

On Thu, 2004-07-29 at 17:30, Bruce Miller wrote: > Matt Dainty wrote: > > Could someone be so kind as to point out what I'm doing wrong? The > > parsed in document is behaving correctly IMO, but the built up document > > doesn't appear to be passing the namespace of an element onto it's > > children, such that any child element I create without specifying a > > namespace, doesn't have one rather than inheriting it from its parent. > > Yep. What's happening is that by using $doc2->createElement('B'), > you are creating a node with NO namespace (or null, or whatever), > even though when you print it out, it looks correct, as though it gets the > default (inherited) namespace. > > Actually, the DOM specification warns against mixing the namespace-aware > and namespace-UNaware methods, presumably for just this reason. Ah, right, that makes sense now. Okay, so my beef appears to be with the output of my constructed document adding all those extra xmlns attributes. But what logic is going on that when a document is parsed, the current default namespace is inherited correctly? :-/ > > I can fix it by specifying the namespace to all elements I create, but > > then when I dump out that document, it's riddled with extra xmlns="" > > attributes which are unnecessary. > > Yeah, frightening isn't it! (although, at least, the doc is correct) :> > The only way I've found so far, is using the method > $parent->addNewChild($nsuri,$tag); > It creates and adds the element in the context of it's parent, > so that it knows exactly what namespaces are visible and avoids > creating new internal/redundant namespace nodes (?). > > Unfortunately it's not part of the DOM spec, and so not portable. > Also, you can no longer create nodes in isolation and add them > where you want; you've got to put them directly in place. This builds exactly what I want, from a visual perspective, without having to do a toString/parse_string manoeuvre. I shall have to skip DOM portability for the time being, which isn't really too much of an issue. > An alternative would be an after-the-fact namespace normalization, > but nobody (including myself!!!) has yet written one. > It pretty much has to be done at the C level to get access > to the actual namespace nodes that libxml2 is using, because > there's a lot of pruning that needs to go on; and a lot of care > to make sure that the internal structures remain > consistent, don't leak memory, etc..... Something like this which I could run as the last stage prior to output would be handy, and allow me to go back to the DOM-friendly construction methods, although would it make sense to have this stage in the document output methods anyway? Thanks for the pointers. Matt _______________________________________________ Perl-XML mailing list Perl-XML@xxxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs