Re: [xml] Generating XML from Schema definitions (again, sorry)

On Thu, Aug 09, 2007 at 12:33:48PM +1000, Callum Gibson wrote:

I just wanted to give an update on where I'm at and have it recorded for
the archive in case anyone else needs to do the same thing.

On 27 Jul 18:50, callum_r_gibson yahoo com au wrote:
}On 27 Jul 03:45, Daniel Veillard wrote:
}}  We don't really have what you expect and for a variety of reasons:
}}    - first you can't systematically derive one kind of document from
}}      a schemas, it's like trying to derive one string from a complex
}}      regexp. You need schemas or regexps preceisely because your
}}      document or string can mute into various ways. It's a completely
}}      open problem if looked from a generic POV.
}I understand what you mean - I assume you're referring to optional and
}repeating elements, for example. However I would be using my internal
}mapping of xpaths (or something similar) to drive which of those elements
}I would need to generate. So I guess I would be looking to use a
}combination of the schema and my own internal data mapping table. That
}should allow a specific document to be output. For example, if you
}traverse into a non-optional element and could find no match
}definition/xpath in the data mapping table or data callback then that
}would obviously be an error. Alternatively, you could default to null or
}empty values.

I've determined I can do what I want with only minimal exposure of
the internals of the schemas code. I do need to use schemasInternals.h
but apart from that the only actual changes to core libxml code is to
add accessor functions to retrieve the doc and schema pointers associated
with an imported schema.

  Okay, good.

In other words, what I'm doing is traversing the xsd schema doc and when
I come across a reference to an imported type or element I lookup that
namespace in the schemasImports hash and get the xmlSchemaImport struct
which contains the imported schema definition and it's document tree.

  So you need a bit more than just the 2 calls below, access to internal data
structures are also needed (which was expected !)

I then basically have a state parser which operates on the xsd document
tree and switches to the imported document tree as necessary. I use hints
from my own application data mapping to determine the resolution of
elements such as abstract types, choices, optional elements and so on.
I've successfully done a test traversal of the schema I'm interested in
and printed out the xml document tree, but I still need to work on
actual mapping of data values.

As I've explained previously, I also want a nice generic way to provide
those hints to my xsd parser (maybe with a "decision" callback). I'll
probably use the parser to generate a template xml doc, with which I can
then fill in the values using callbacks, for example. I'll probably need
to (ab)use the _private pointer for that bit.

  Well _private is by definition a placeholder for users data, so I think
it's not an abuse, it's an abuse when libxml2 (or libxslt) code use that

The changes I made were to add declarations in schemasInternals.h for
two new functions in xmlschemas.c:

XMLPUBFUN xmlDocPtr XMLCALL             xmlSchemaImportGetDoc(void *imp);
XMLPUBFUN xmlSchemaPtr XMLCALL          xmlSchemaImportGetSchema(void *imp);

  I'm a bit surprised by the fact that you pass a void * and not a type
there, so I wonder what it's supposed to be, an internal type I guess.

I also had to include xmlschemas.h in schemasInternals.h to ensure the
definition of xmlSchemaPtr, but I didn't think that was too unreasonable
for any other file which was including schemasInternals.h anyway. The
rest I can do with public functions.

  I think that's the most problematic part, maybe some of the structures
are now stable enough to be made public. We were very concerned about not
exposing too much with Kasimier because we knew the implementation wasn't
complete enough and we didn't want to expose internal bits to be able to 
change the design if needed without having to break the ABI/API or go 
though crazy compatibility exercises.

I love having the source code. Thanks to all libxml contributors. :-)



Red Hat Virtualization group
Daniel Veillard      | virtualization library
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]