[xml] RelaxNG schema and entities file: namespace warning : Namespace default prefix was not found
Hi, Consider this example: !DOCTYPE foo [ !ENTITY comment 'comment id=comment.xml /' ] foo xmlns=http://foo.bar/ns/foo; ... comment; ... /foo When I run `xmllint --noout --noent --relaxng foo.rng foo.xml' I receive: | namespace warning : Namespace default prefix was not found | ... | element comment: Relax-NG validity error : Did not expect element comment there But `jing foo.rng foo.xml' succeeds and does not complain. I have to add the xmlns attribute to comment for xmllint to succeed. Is this correct or an issue in xmllint? I wouldn't have expected, that I have to add the namespace to this entity. I thought it gets directly replaced. Regards, Daniel ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] Environment Variables in XML are parsed by libxml2 ?
Am Sonntag, den 21.10.2007, 13:44 +0530 schrieb Arijit Das:
Is there any way I can change the following DTD spec inside my XML
document from this:
!DOCTYPE ENVCAP SYSTEM /remote/vgsource1/arijit/Tc.Perforce/lib/envcap.dtd
...to this =
!DOCTYPE ENVCAP SYSTEM $(TCHOME)/lib/envcap.dtd
Why don't you simply use a catalog? You can prepare it on-the-fly using
xmlcatalog and then you could also read ${TCHOME} to prepare the
catalog, although I'm not sure, if this is necessary. Adding the catalog
to XML_CATALOG_FILES is probably enough. Depends on what you want to do.
Regards, Daniel
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] XML conditional section not closed error could need some more info
Am Donnerstag, den 26.04.2007, 04:29 -0400 schrieb Daniel Veillard: On Wed, Apr 25, 2007 at 06:58:49PM +0200, Daniel Leidert wrote: Am Mittwoch, den 18.04.2007, 18:52 +0200 schrieb Daniel Leidert: [..] file:///usr/share/xml/docbook/custom/simple/1.1/sdocbook-custom.dtd:452: parser error : XML conditional section not closed [..] I got some response from the DocBook guys, that said, that it might be a bug in xmllint. The DTD can also be found online: http://www.oasis-open.org/docbook/xml/simple/1.1/sdocbook-custom.dtd Can you help Daniel? I checked some DTD validation tools and they say, the DTD is valid. Also libxml2 2.6.27 seems to validate the file correctly. But 2.6.28 prints the mentioned warning. I checked the DTD, but didn't find any issues. Bug or not a bug? Shall I open a bug-report at the BTS? Sorry, I forgot the issue, please bugzilla it and remind me from time to time if I didn't look at it. I'm just too busy with other stuff right now. It's strange because I don't remember changing anything there recently. The good news is: We tracked down the issue to the lines causing it and there is not a different behaviour between the mentioned libxml2 versions. IMHO the lines causing the issue are valid and it's strange, that they cause this error. But we will do further investigation and after this, I will open a bugzilla-report if necessary. Regards, Daniel ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] XML conditional section not closed error could need some more info
Am Mittwoch, den 18.04.2007, 18:52 +0200 schrieb Daniel Leidert: I have some test cases to check DocBook DTDs. One for simplified DocBook is: ?xml version='1.0'? !DOCTYPE article PUBLIC -//OASIS//DTD Simplified DocBook XML Customization V1.1//EN http://www.oasis-open.org/docbook/xml/simple/1.1/sdocbook-custom.dtd; article titlefoo/title section titlebar/title parafoo/para /section /article But when I try to validate it: xmllint --debug --debugent --noout --nonet --valid test-custom-1.1.xml I get an error: file:///usr/share/xml/docbook/custom/simple/1.1/sdocbook-custom.dtd:452: parser error : XML conditional section not closed Of course, line 452 is the last line in the DTD, so it's not very useful to know, that something has not been closed. Is it possible to add some info, where the conditional section was opened? Or am I wrong here, asking for this? I got some response from the DocBook guys, that said, that it might be a bug in xmllint. The DTD can also be found online: http://www.oasis-open.org/docbook/xml/simple/1.1/sdocbook-custom.dtd Can you help Daniel? I checked some DTD validation tools and they say, the DTD is valid. Also libxml2 2.6.27 seems to validate the file correctly. But 2.6.28 prints the mentioned warning. I checked the DTD, but didn't find any issues. Bug or not a bug? Shall I open a bug-report at the BTS? Regards, Daniel ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
[xml] xmllint: possible bug using --postvalid
Hello, I get this using the --postvalid option of xmllint with a valid XML file: $ xmllint --noout --valid article.xml $ xmllint --noout --postvalid article.xml article.xml:11: element xref: validity error : IDREF attribute linkend references an unknown ID test Document article.xml does not validate The ID exists in another file (section.xml), that is inbound via entity. The samples are attached. Bug or not a bug? A limitation of postvalid? Regards, Daniel article.xml Description: application/docbook section.xml Description: application/xml ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] xmllint: validation of XML files with XInclude-d documents maybe broken
Am Dienstag, den 20.02.2007, 17:43 +0100 schrieb Daniel Leidert: [..] xmllint --xinclude --noout --valid howto-mimedef.xml Matthew Burgess told me to use the --postvalid switch instead, which works. So I did not observe a bug, I just oversaw the right switch :). Thanks to Matthew and sorry for the noise. Regards, Daniel ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
[xml] xmllint: validation of XML files with XInclude-d documents maybe broken
Hello, See the file http://debian.wgdd.de/temp/howto-mimedef.xml as example. This file is a DocBook article, that xincludes several other XML files for appendices or other parts of the article. Now I want to validate the file. Therefor I ran: xmllint --xinclude --noout --valid howto-mimedef.xml and I get a lot of errors. It seems, that e.g. the XIncludes are not included. xmllint complains about the xi:include elements itself. And then it also seems to try to separately validate the xincluded files too, which of course fails for e.g. the included gfdl.xml file, because it does not contain a DTD. But if I do: xmllint --xinclude howto-mimedef.xml test.xml xmllint --valid --noout --valid test.xml everything is fine (the resulting XML file is valid). So I would expect, that a xmllint --xinclude --noout --valid howto-mimedef.xml Am I doing something should also work and not fail. Am I doing something wrong? Does xmllint work as expected here? Regards, Daniel ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] Man page suggestion
Am Freitag, den 09.02.2007, 09:10 -0500 schrieb Daniel Veillard: On Fri, Feb 09, 2007 at 03:05:30PM +0100, Markus Hoenicka wrote: Daniel Veillard [EMAIL PROTECTED] was heard to say: ideally we should be able to generate exhaustive man pages from the XML description, I just never managed to steal the time to write the XSLT stylesheet which would do it (and I would need to learn troff too). You could skip the latter if you use the XSLT stylesheet to generate DocBook refentries from your XML description. DocBook XML can be transformed to man pages with the official stylesheets. it lowers the geek factor and Norm's stylesheet are a bit scary, but sure we are already already using them. Also I'm not sure Docbook is any faster to learn than troff ;-) I already offered my help some time ago, but didn't find time to realize it. Maybe I can do this next week, if you don't have problems with that. Regards, Daniel ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
[xml] xsltproc: weired behaviour with parsing freedesktop.org XML shared-mime-info database (bug?)
Hello, I observe a really weired behaviour here. See the attached stylesheet and process it to the shared-mime-info database (normally $datadir/mime/packages/freedesktop.org.xml). If I process my own XML file, with a similar (but not the same) DTD, containing an identical glob-element, it works. Processing it to the shared-mime-info db, does not give any output. What's the problem here? The shared-mime-info DB is a valid XML file. So what is happening here? Could you help to explain it to me? Maybe I'm just too dumb or I over-read something. Thanks and regards, Daniel test.xsl Description: application/xslt ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] xsltproc: weired behaviour with parsing freedesktop.org XML shared-mime-info database (bug?)
Am Dienstag, den 06.02.2007, 21:08 +0100 schrieb Daniel Leidert: Hello, I observe a really weired behaviour here. See the attached stylesheet and process it to the shared-mime-info database (normally $datadir/mime/packages/freedesktop.org.xml). If I process my own XML file, with a similar (but not the same) DTD, containing an identical glob-element, it works. Processing it to the shared-mime-info db, does not give any output. What's the problem here? The shared-mime-info DB is a valid XML file. So what is happening here? Could you help to explain it to me? Maybe I'm just too dumb or I over-read something. Dooh! [..] !ATTLIST mime-info xmlns CDATA #FIXED http://www.freedesktop.org/standards/shared-mime-info; [..] Got it. My fault. Oversaw this. Regards, Daniel ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
[xml] Possible bug in libxml2?
Hello,
I wanted to create a gettext portable object template (.pot) file from
Norman Walsh's DocBook: The Definitive Guide. Therefor I used:
xml2po -e -o book.pot book.xml
in http://docbook.svn.sourceforge.net/viewvc/docbook/trunk/defguide/en/
and received a segmentation fault. So I started gdb and got the attached
backtrace. Can any of you say, where the segmentation fault is produced
- in xml2po or libxml2/python-libxml2 - so I can file a bug-report?
xmllint validates the XML source if you fix the tag element in
refpages/elements/equation/refentry.xml (should be an sgmltag element).
CCing Danilo Segan, the maintainer of xml2po
Thanks for any help,
Regards, Daniel
The program being debugged has been started already.
Start it from the beginning? (y or n) Starting program: /usr/bin/python
/usr/bin/xml2po -e -o book.pot book.xml
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1209702720 (LWP 25761)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209702720 (LWP 25761)]
0xb7bed365 in xmlSearchNs__internal_alias (doc=0xb7f8007c, node=0xb7007465,
nameSpace=0xb7f87510 \buø·\buø·\020uø·\020uø·\030uø·\030uø· uø·
uø·(uø·([EMAIL
PROTECTED]@uø·Huø·Huø·Puø·Puø·Xuø·Xuø·`uø·`uø·huø·huø·puø·puø·xuø·xuø·\200uø·\200uø·\210uø·\210uø·\220uø·\220uø·\230uø·\230uø· uø· uø·¨uø·¨uø·°uø·°uø·¸uø·¸uø·Àuø·Àuø·Èuø·Èuø·...)
at tree.c:5612
5612tree.c: No such file or directory.
in tree.c
#0 0xb7bed365 in xmlSearchNs__internal_alias (doc=0xb7f8007c, node=0xb7007465,
nameSpace=0xb7f87510 \buø·\buø·\020uø·\020uø·\030uø·\030uø· uø·
uø·(uø·([EMAIL
PROTECTED]@uø·Huø·Huø·Puø·Puø·Xuø·Xuø·`uø·`uø·huø·huø·puø·puø·xuø·xuø·\200uø·\200uø·\210uø·\210uø·\220uø·\220uø·\230uø·\230uø· uø· uø·¨uø·¨uø·°uø·°uø·¸uø·¸uø·Àuø·Àuø·Èuø·Èuø·...)
at tree.c:5612
cur = (xmlNsPtr) 0xa5c0f40
#1 0xb7bf5524 in xmlStaticCopyNode (node=0xa5c0f40, doc=0x8156710, parent=0x0,
extended=1) at tree.c:3931
ulccur = value optimized out
ret = value optimized out
#2 0xb7be84eb in xmlParseReference__internal_alias (ctxt=0xb1138a0) at
parser.c:6202
nw = (xmlNodePtr) 0x7369736f
cur = (xmlNodePtr) 0xa5c0f40
firstChild = (xmlNodePtr) 0x0
ent = (xmlEntityPtr) 0x828e6c0
val = value optimized out
#3 0xb7be6d95 in xmlParseContent__internal_alias (ctxt=0xb1138a0) at
parser.c:8462
cons = 19425
#4 0xb7beb09d in xmlParseElement__internal_alias (ctxt=0xb1138a0) at
parser.c:8623
name = (const xmlChar *) 0xb7ade351 entry
prefix = value optimized out
URI = value optimized out
node_info = {node = 0x114, begin_pos = 2, begin_line = 222324016,
end_pos = 3998, end_line = 0}
line = 276
tlen = value optimized out
ret = (xmlNodePtr) 0xd44d680
nsNr = 0
#5 0xb7be6d88 in xmlParseContent__internal_alias (ctxt=0xb1138a0) at
parser.c:8453
cons = 19425
#6 0xb7beb09d in xmlParseElement__internal_alias (ctxt=0xb1138a0) at
parser.c:8623
name = (const xmlChar *) 0xb7ade34d row
prefix = value optimized out
URI = value optimized out
node_info = {node = 0xd406530, begin_pos = 185677984, begin_line =
222324249, end_pos = 3217717352, end_line = 275}
line = 276
tlen = value optimized out
ret = (xmlNodePtr) 0xd44d540
nsNr = 0
#7 0xb7be6d88 in xmlParseContent__internal_alias (ctxt=0xb1138a0) at
parser.c:8453
cons = 19425
#8 0xb7beb09d in xmlParseElement__internal_alias (ctxt=0xb1138a0) at
parser.c:8623
name = (const xmlChar *) 0xb7ade347 tbody
prefix = value optimized out
URI = value optimized out
node_info = {node = 0x8, begin_pos = 2, begin_line = 222324016, end_pos
= 175, end_line = 13}
line = 14
tlen = value optimized out
ret = (xmlNodePtr) 0xd3fc3c8
nsNr = 0
#9 0xb7be6d88 in xmlParseContent__internal_alias (ctxt=0xb1138a0) at
parser.c:8453
cons = 0
#10 0xb7beb09d in xmlParseElement__internal_alias (ctxt=0xb1138a0) at
parser.c:8623
name = (const xmlChar *) 0xb7ade322 tgroup
prefix = value optimized out
URI = value optimized out
node_info = {node = 0x7, begin_pos = 2, begin_line = 222324016, end_pos
= 159, end_line = 7}
line = 8
tlen = value optimized out
ret = (xmlNodePtr) 0xd3fbc68
nsNr = 0
#11 0xb7be6d88 in xmlParseContent__internal_alias (ctxt=0xb1138a0) at
parser.c:8453
cons = 0
#12 0xb7beb09d in xmlParseElement__internal_alias (ctxt=0xb1138a0) at
parser.c:8623
name = (const xmlChar *) 0xb7ade314 informaltable
prefix = value optimized out
URI = value optimized out
node_info = {node = 0x5, begin_pos = 2, begin_line = 222324016, end_pos
= 102, end_line = 5}
line = 7
tlen = value optimized out
ret = (xmlNodePtr) 0xd3fbbd8
nsNr = 0
#13 0xb7be6d88
[xml] xmlcatalog: inconsistent behaviour between the --add and --del option?
Hello, If I want to add an entry to the catalog, I have to specify the catalog file: xmlcatalog --add 'TYPE' 'ORIG' 'REPLACE' $CATALOG but removing an entry works without giving the catalog file xmlcatalog --del 'VALUE' Normally I would have expected, taht even the `--add' option does not require a catalog file (Shouldn't it simply try to examine XML_CATALOG_FILES)? Or is this behaviour dedicated to the fact, that XML_CATALOG_FILES can be a list of catalogs (which isn't a problem, if en entry shall be removed)? But in this case I would expect, that --del accepts a catalog file too. Regards, Daniel ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] xmlcatalog: inconsistent behaviour between the --add and --del option?
Am Samstag, den 25.11.2006, 16:16 -0500 schrieb Daniel Veillard: On Sat, Nov 25, 2006 at 09:26:27PM +0100, Daniel Leidert wrote: Hello, If I want to add an entry to the catalog, I have to specify the catalog file: xmlcatalog --add 'TYPE' 'ORIG' 'REPLACE' $CATALOG but removing an entry works without giving the catalog file xmlcatalog --del 'VALUE' Normally I would have expected, taht even the `--add' option does not require a catalog file (Shouldn't it simply try to examine XML_CATALOG_FILES)? Or is this behaviour dedicated to the fact, that XML_CATALOG_FILES can be a list of catalogs (which isn't a problem, if en entry shall be removed)? But in this case I would expect, that --del accepts a catalog file too. Looking at xmlcatalog.c code and the 2 APIs used underneath namely xmlCatalogAdd() and xmlCatalogRemove(), I don't see any difference in code between both option w.r.t. what catalog are loaded and affected. If you don't specify a catalog the default one is used in both cases. Sorry I don't really understand the problem. This should work the same in both cases, either with an explicit catalog or a default catalog. However in the add case, assuming the orig value was matched by an entry in the system catalog, maybe you just can't change that system catalog, but it's just suppositions. Ok. Here with two examples (maybe I'm just too stupid): The --add option definitely does not work without a specified catalog-file on the command line: $ xmlcatalog --verbose --add 'publicId' 'foo' 'bar' add command failed Catalogs cleanup Even the following fails: XML_CATALOG_FILES=/path/to/my/catalog.xml xmlcatalog --verbose --noout (--create) --add 'publicId' 'foo' 'bar' fails with the same error. I would have expected, that in the first case, I see the catalog on stdout (like --del works). In the second case, the given file should be updated/created. So far my understaing of the manpage. As I said, maybe I just made a mistake. Used is libxml2 from Debian/Sid Regards, Daniel ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] Update for libxslt/libxml manpages?
Am Donnerstag, den 06.04.2006, 04:33 -0400 schrieb Daniel Veillard: On Thu, Apr 06, 2006 at 01:28:00AM +0200, Daniel Leidert wrote: [..] I would offer to rewrite these manpages in XML and fix the mentioned bugs. As far as I understand Daniel's answer: [..] PS: Would you be interested in updated libxml(3) and libxslt(3) manpages too? I could rewrite them in XML and fix a few bugs. One is, that these That would be great. Actually one of the things I never took the time to do is to make XSLT stylesheets to generate man pages for the functions entry points from doc/libxml2-api.xml and doc/libxslt-api.xml that's probably the simplest. [..] he suggests to use the libxml2-api.xml/libxslt-api.xml files and create the manpages using these files, which seems to be a good idea to me. One possible implementation: The manpages get a basic structure (refentry/refentryinfo + stuff currently mentioned in the existing manpages) and inbound another XML document, which is created via XSLT from the mentioned api-files. The resulting (refentry) XML file can then be processed via xsltproc and the manpage is created. Your opinion? The only danger is that there is more than a thousand entry point in libxml2 (closer to 2000 I guess), and - we don't want one man page per entry that's unshippable ACK. - one page with all entry point is also a bit nightmarish maybe a split of one page per module would be more sensible. ACK. This would also allow to avoid the generation of the man pages for stuff in 'internal' headers. Similary in libxslt we probably don't want to expose everything in the man pages. We can't remove exposed entry point from the API for ABI compatibility but hiding the doc for them sounds a good approach :-) Ok. So I suggest libxml2(3) : main manpage, describing the files and which modules exist - referencing each module (the latter is done by parsing the libxml-api.xml file via XSLT) libxml2-$module(3) : description and synopsis(?) of each module, created from the related api.xml file via XSLT Ditto for libxslt(3). This scheme seems to be used (by default) for Perl documentation, but also for some C/C++ libraries. Your opinion? Regards, Daniel ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
[xml] Re: Updated xsltproc manpage, patch attached
Am Donnerstag, den 06.04.2006, 10:22 +0200 schrieb Daniel Veillard: On Thu, Apr 06, 2006 at 12:52:29AM +0200, Daniel Leidert wrote: [..] Ok. Now 3 patches are attached :) Hum, the URL used for the stylesheet in the patch is not in the catalogs installed on Red Hat and Fedora. I don't think that referencing a snapshot version which will lead to divergence and can't be sanely packaged locally is a good idea. Moreover this is a redirected URL. Right. But it redirects to the same URL. I thought, that you don't use a local version by default, because the manpages are already put into the source. So I thought, changing to the snapshots is not a problem. When the next release of docbook-xsl is made, they could safely changed to the released version. I don't think we can rely on something which is not a released version, and switched back to http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl except for that, patches are applied and commited, There are some problems with the released versions (the upcoming version really improves the manpage stylesheets). First the segmentedlist element is not supported, so the diagnostics section will then be empty atm. Mixing bold and italic elements does not work properly with the released versions. Ditto for mixing group and arg elements, which can lead to obscure results. Referencing a section (like I did in one of the manpages) using the xref elemnt is also not supported in the released versions. So if you decide to not use the snapshots for the moment, I have to change back some stuff. PS: Regarding your second mail, I send this answer to the lists, so we can continue discussion there. Regards, Daniel ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] Re: Updated xsltproc manpage, patch attached
Am Donnerstag, den 06.04.2006, 07:41 -0400 schrieb Daniel Veillard: On Thu, Apr 06, 2006 at 01:35:56PM +0200, Daniel Leidert wrote: Right. But it redirects to the same URL. I thought, that you don't use a libxml2/libxslt make can't rely on remote resources, so if it's not in the catalog it will break. It does break on my systems as a result. versions. So if you decide to not use the snapshots for the moment, I have to change back some stuff. I think that's premature, sorry :-\ No problem. Expect the fixed manpages very soon. PS: Please do not send me any extra CC. Regards, Daniel ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
