[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [xml] Forcing the xml:base attribute for included files in the same directory
- From: Daniel Veillard <veillard redhat com>
- To: Catherine Proulx <cproulx ieee org>
- Cc: xml gnome org
- Subject: Re: [xml] Forcing the xml:base attribute for included files in the same directory
- Date: Wed, 2 Jul 2008 10:24:07 -0400
On Wed, Jul 02, 2008 at 08:39:02AM -0400, Catherine Proulx wrote:
> Hi,
Hi,
> I have a question regarding the omission of the xml:base attribute when
> including a file located in the same directory as the includer. I've
> read, in an old newsgroup post, that this was done on purpose
> when the xml:base support was implemented
> (http://sources.redhat.com/ml/docbook/2003-03/msg00101.html)
yes on purpose to give the people using DocBook/TEI/... a way to
use XInclude without getting invalidity errors until their DTDs got
updated.
> Is there a workaround for this? In other words, is there
> a way I could force the parser to add the xml:base attribute for all
> inclusions, regardless of their directory?
There is no way directly code is in xinclude.c around line 1681.
> I'm hoping to implement an error-reporting and coverage tool for
> xml-embedded code, and using the xml:base attribute seems like the least
> invasive way to locate a code snippet. (I'm using libxml 2.6.22 by the
> way, but could consider an upgrade if essential. However, nothing in the
> release notes indicated that this behavior had changed) Of course, we
> can always
> move the files around so that includer files will always be in a
> directory of their own. But I'd prefer a more elegant solution if possible.
I'm not sure the xml:base is really the right thing to use. For example
when a tree gets processed with XInclude, libxml2 inserts XML_XINCLUDE_START
and XML_XINCLUDE_END nodes around every included fragment in the resulting
tree (unless asked to not do that with XML_PARSE_NOXINCNODE parser option).
Your code could just walk the resulting tree and locate and analyze them.
That sounds way cleaner and safer in general.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]