RE: [xml] Validating using IO parser context

Thanks Daniel!

-----Original Message-----
From: Daniel Veillard [mailto:veillard redhat com]
Sent: Thursday, August 30, 2001 1:11 PM
To: Henke, Markus
Cc: 'xml gnome org'
Subject: Re: [xml] Validating using IO parser context

On Thu, Aug 30, 2001 at 12:00:16PM +0200, Henke, Markus wrote:
Hello out there,

again one more try. Maybe i was sketchy explaining my problem b4.


Hoped so  8)

It's clear (thank you, Daniel) that i've to provide an 
base-URI, since there
is none specified in an IOParserContext
created with a filedescriptor and the DTD is linked by an RELATIV
URI-reference (...SYSTEM "someDTD.dtd").
It's also clear (at least i guess so) that my 
externalEntityLoader has to compute the path to the DTD.

  Right, basically, there is nothing in the XML document which allows
to make this computation. So you are doing something which is 
not directly
supported by the XML specification as such, and can't expect standard
XML tools to handle it natively.

  So, you need to write your own entity loader and put some logic 
there to allow the recognition of your specific need.

Done so. I'm able to provide a base-URI in the parserContext
of the XML document, also able to compute the path to the DTD
in my externalEntityLoader. What i'm missing is some kind of
'global' structure where i can drop the base-URI and which
is accessable for the loader.

The question is HOW can i provide the base URI in a way that the
externalEntityLoader can acces it?

  I don't know any easy way ... if you use
 then you can probably add this information to the ioctx parameter.

Surely, that's an option. But AFAIK i've no access to the ioctx of
the document within an externalEntityLoader. Or i'm wrong here?

The externalEntityLoader runs in a parserContext provided 
by it's signatur

  static xmlParserInputPtr  myEntityLoader(const char *URL, 
 const char *ID,
xmlParserCtxtPtr ctxt)

but that's NOT the context 'origParserCtxt' of the XML-Document

  Have you tried using the _private field of the parser context ?

  Have you tried using the directory field of the parser context ?

Yes, at least i've thought about that. The problem is that i've to
copy the corr. field to the newly created parserContex for the
externalEntityLoader and that creation takes place 'in the depths'
of libxml.

Yes, getting access to the parser context means you will have 
to use lower
level APIs probably.

Maybe i've to dive in and find a place where both contexts meet.

  Have you tried using a catalog too to redirect the given system ID
to another one ?

Havn't dealed with catalog features by now...

So, again the question:
Is there a way in libxml to provide a base URL to a XML 
document so that an
externalEntityLoader can access it?

  Directly I can't tell, maybe there is no infrastructure for it.
Maybe you can but since what you're doing is really specific it's not
surprizing it may not be easy to do in a general framework.
You must accept the fact that doing something which is not directly
supported from the XML standard may be harder to implement.

Clear! Just looking for hints what's the best way to do so.
And again: I pay tribute to the work on libxml that offers so much
capabilities. Working with IOParserContext, externalEntityLoader,
the option to register callbacks for IO, memory- and error-handling
is a great chance to implement XML-features for legacy applications.

Making an URI reference where there is an implicit base but it's not
in the document context is clearly pushing the limit.

Well, i CAN provide a base in document context, but... (look above  8)

  I don't think it's impossible. But it will definitely take you
more work to get working.

No problem, that's my job  8)

  That said if you require extensions I may provide them, or fix code
if there is problems.

I'll look for the place where the parserContext for the externalLoader
is created. Maybe there's a chance to deliver some information from
document-context to loader-context...


Thank you & Ciao, Markus

Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml Gnome XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]