Re: [xml] reverse engineering a schema



On Sat, Apr 12, 2003 at 08:16:56PM -0400, David Weinkauf wrote:
Hi,

I'm attempting to write a program which displays a schema's content 
model in a 'tree' format. For example, if given the file 'po.xml' found 
in libxml/examples the output would be:

purchaseOrder[ orderDate]
|-- shipTo[ country]
|   |-- name
|   |-- street
|   |-- city
|   |-- state
|   `-- zip
|-- billTo[ country]
|   |-- name
|   |-- street
|   |-- city
|   |-- state
|   `-- zip
|-- comment
`-- items
    `-- item[ partNum,@subNum]
        |-- productName
        |-- quantity
        |-- USPrice
        |-- comment
        `-- shipDate
21 elements

  Hum, interesting. Currently the schemas validation layer does not store
type informations back into the tree (though I think of a trick for doing
so), so I think it's not easy to do in the current form.

Currently I have a working version, but it requires the internals of 
some of the structures found in xmlregexp.c to become available at the 
API level. This is because I use the content models generated for each 
element after the schema is parsed to achieve the reverse engineering 
and hence, create the tree. What are your thoughts on making the 
internals of 'struct _xmlRegexp' available at the libxml2 API level?

   Heh, how long did you hack to get there :-)
Well I'm not strongly against, rather that that part wasn't really stable
and also that exposing the structure makes it part of the ABI I need to
maintain compatibility for. Exposing structure implementation is also
less clean than creating APIs to give those informations.

Also, if I'm going about this problem the wrong way, please let me know.

  No, there are other ways, like storing the "PSVI" informations in the
tree, or building an API to access those regexp structures, which also
mean state, atoms and counters to be exposed, i.e. all the internals
of the regexp engine.
  On the other hand, the regexp layer is now reused by DTD and also 
by Relax NG (not commited yet) so it seems stable enough, and probably won't
need any change in the future. Opening the structure and making it part of
the API/ABI should not be a big deal. Probably better than trying to design
a zillion accessor functions for the structures.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
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]