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

[Daniel Veillard <veillard redhat com>]

On Thu, Aug 09, 2007 at 12:33:48PM +1000, Callum Gibson wrote:
> Hi,
>
> 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
area.

> 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. :-)

  :-)

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/