Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some struct bindings are missing XML Schema #79

Open
Ameobea opened this issue Oct 1, 2020 · 3 comments
Open

Some struct bindings are missing XML Schema #79

Ameobea opened this issue Oct 1, 2020 · 3 comments

Comments

@Ameobea
Copy link

Ameobea commented Oct 1, 2020

I am using your crate for parsing XML schema (XDS), and ran into the need to traverse the raw parsed schema tree. There are a few cases where libxml2 does explicit casts between pointer types (says it's a xmlSchemaType * when it's actually a xmlSchemaParticle *).

This is fine; the generated bindings properly reflect the type of the struct itself and can't do anything about their casting it. However, I think this has caused some structs to not be included in the bindings. The ones that I encountered and had to generate bindings for manually were:

  • _xmlSchemaTreeItem
  • xmlSchemaTreeItemPtr
  • _xmlSchemaParticle

_xmlSchemaTreeItem is a bit of a weird case since it's "The abstract base type for tree-like structured schema components". You may be against including that in the bindings which I'd understand, but I do think adding at least adding _xmlSchemaParticle to the bindings would be valuable since users can obtain pointers to them via the existing API (even though the libxml2 types may lie about what kind of pointer they are).

I don't know if this was something that was manually removed from the generated bindings or if the bindgen tool simply missed them for some reason, but either way if this is something you'd like to add I could go about making a PR to implement that if it's easier for you.

@dginev
Copy link
Member

dginev commented Oct 1, 2020

I am unsure as to why these structs were not in the bindings, but I certainly welcome adding them! Feel free to make a PR with your additions, and if you'd like to add a minimal test that would be great too - happy to add them to the main crate.

What goes into the bindings isn't really that important to me personally, since they aren't directly/officially intended for public consumption - the Rust API is. So I would always prefer to err on the side of more coverage on that side of affairs.

Thanks for bringing this up!

@Ameobea
Copy link
Author

Ameobea commented Oct 1, 2020

Thanks for the response @dginev!

Looking into this further, it looks like the structs in question aren't specified in the headers include/libxml/*.h but rather are only defined in the .c files (xmlschemas.c and xmlschemastypes.c specifically). This leads me to believe that they're an internal API of the libxml2 library and they don't want them to be exposed, and possibly I'm not doing my XSD traversal in the correct way since I depend on them.

Are you still in favor of adding them to the generated bindings?

@dginev
Copy link
Member

dginev commented Oct 2, 2020

Ah ok, if they are from .c files, we may consider them as auxiliary helpers -- and you have to figure out what the "best practice" for using libxml2 itself is w.r.t to schemas, since I myself have no familiarity with those workflows. If you think certain functions are questionable, might as well skip adding them for now.

We have a single file hosting C helpers at the moment, aptly called c_helpers.rs, and you can check out some examples here:
https://github.com/KWARC/rust-libxml/blob/master/src/c_helpers.rs#L14

Maybe adding to that file is a good way to proceed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants