Re: [xml] DTDs

On Tue, Aug 27, 2002 at 09:50:45AM +0200, Daniel Gehriger wrote:
  Fine, very close to catalogs. Another possibility is to not 
switch DTD parsing and have a (set of) preparsed DTD(s) and use
xmlValidateDtd() to check the documents against the DTD(s) 
after parsing.

Catalogs ? You mean the external entity load part ? I tried using
catalogs for this, but I could not find a way to build an in-memory
catalog. It always seems to require some file to start with. If I could

  yes, I just commented on the similarities of the approaches.

create an in-memory catalog, then I would map the DTD ID/URL to
something like "jar:...." or "res:..." (I already wrote the
corresponding protocol handlers). 

  Hum, that would require a new API. Also the problem is that 
catalogs make heavy use of URI-Reference, and when using
a document coming from memory (and hence without base) it becomes
really fragile, I'm afraid ...

How would I preparse a DTD ? Looking through the API, I can't find
anything that would allow me to (a) create an "struct xmlDtd" from a
DTD, or better yet, load it from a serialized "struct xmlDtd".

    xmlDtdPtr       xmlParseDTD             (const xmlChar *ExternalID,
                                             const xmlChar *SystemID);

is that so hard to find ? Just doing a grep ^xmlDtdPtr include/libxml/*.h ???

Something else: I install my external entity loader using
xmlSetExternalEntityLoader(). Before calling this function, I remember
the previous loader using xmlGetExternalEntityLoader(), which I continue
to use in my loader if I don't handler the entity. The problem is that
this requires a global variable. I could not find a way to pass the
previous loader's function pointer as private (context) information to
my loader. The "context" argument to my the loader function only seems
to contain a pointer to the xmlDoc being created. Is there a way to
split xmlParseFile() in two steps ? Step 1: create an empty document,
and set some context information (how ?); Step 2: parse the file, and
make use of this context data in the entity loader ?

  Yes entity reference resolution is not context sensitive, changing
it would be quite complex at this point, sorry it's an application
wide mechanism ...


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]