Skip Menu |
 

This queue is for tickets about the XML-LibXML CPAN distribution.

Report information
The Basics
Id: 33488
Status: resolved
Priority: 0/
Queue: XML-LibXML

People
Owner: Nobody in particular
Requestors: SREZIC [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: 1.66
Fixed in: (no value)



Subject: Wrong link in XML::LibXML::Parser Pod
Download (untitled) / with headers
text/plain 307b
The following paragraph in XML/LibXML/Parser.pod (line 226 in my version) has a wrong link specification: This function parses a well balanced XML string into a L<<<<<< XML::LibXML's DOM L2 Document Fragment Implementation|XML::LibXML's DOM L2 Document Fragment Implementation >>>>>>. Regards, Slaven
Download (untitled) / with headers
text/plain 2.3k
On Thu Feb 21 09:36:43 2008, SREZIC wrote: Show quoted text
> The following paragraph in XML/LibXML/Parser.pod (line 226 in my > version) has a wrong link specification: > > This function parses a well balanced XML string into a L<<<<<< > XML::LibXML's DOM L2 Document Fragment Implementation|XML::LibXML's DOM > L2 Document Fragment Implementation >>>>>>. >
There seem to be similar problems also in other Pods of XML::LibXML. I just looked into Node.pod and found the following ones: L<...> links with URLs should not have a linktext part, according to perldoc perlpodspec (the paragraph there reads: · Authors wanting to link to a particular (absolute) URL, must do so only with "L<scheme:...>" codes (like L<http://www.perl.org>), and must not attempt "L<Some Site Name|scheme:...>" codes. This restriction avoids many problems in parsing and rendering L<...> codes. ) This applies to the following lines in the Node.pod file: Many functions listed here are extensively documented in the L<<<<<< DOM Level 3 specification|http://www.w3.org/TR/DOM-Level-3-Core/ >>>>>>. Please refer to the specification for extensive documentation. Specification (see L<<<<<< http://www.w3.org/TR/xml-c14n|http://www.w3.org/TR/xml-c14n >>>>>>). Such transformation is known as canonization. Specification (see L<<<<<< http://www.w3.org/TR/xml-exc-c14n|http://www.w3.org/TR/xml-exc-c14n Show quoted text
>>>>>>) for exclusive canonization of XML.
65535 will be returned as 65535. Please see L<<<<<< http://bugzilla.gnome.org/show_bug.cgi?id=325533|http://bugzilla.gnome.org/show_bug.cgi?id=325533 Show quoted text
>>>>>> for more details.
Then there are some links which look wrong: This function is the opposite calling of L<<<<<< XML::LibXML DOM Document Class|XML::LibXML DOM Document Class >>>>>>'s adoptNode() function. Because of this it has the same limitations with The recommended way is to use the L<<<<<< XPath Evaluation|XPath Evaluation >>>>>> module to define an explicit context for XPath evaluation, in which a document See also L<<<<<< XPath Evaluation|XPath Evaluation >>>>>>->find. See also L<<<<<< XPath Evaluation|XPath Evaluation >>>>>>->findvalue. This method is similar to the method C<<<<<< toString >>>>>> of a L<<<<<< XML::LibXML DOM Document Class|XML::LibXML DOM Document Class Show quoted text
>>>>>> but for a single node. It returns a string consisting of XML
serialization of Regards, Slaven
Download (untitled) / with headers
text/plain 109b
The POD documentation is generated from DocBook; the generating script is now fixed in SVN. Thanks, -- Petr


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.