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

Add namespace support #2877

Open
Caellian opened this issue Jan 3, 2025 · 2 comments
Open

Add namespace support #2877

Caellian opened this issue Jan 3, 2025 · 2 comments

Comments

@Caellian
Copy link

Caellian commented Jan 3, 2025

Problem

It's virtually impossible to handle XML-like documents from serde because it doesn't support data namespacing.

Proposal

I'm proposing addition of namespace metadata for types and fields, a mechanism to allow accessing it from Serializer, Deserializer and Visitor, as well as a derive attribute (#[serde(namespace = "http://www.w3.org/2000/svg")], #[serde(namespace_from = "svg_namespace_fn")]).

This is not related to attribute/child placement of data - I see how that's probably out of scope of what serde aims to deal with.

Use cases

Namespaces are important for shared document formats which are intended to be consumed by multiple different programs, where those programs might have collisions in naming. Prominent examples that come to mind are SVG <metadata> and WebDAV properties, which basically require namespace support to be handled correctly.

Currently, XML is probably the most wide-known example of such a format, but there may be other. Ideally a format should provide some reserved area for out-of-place storage of "non-standard" data i.e. document metadata, but in-place storage is a valid design choice as well so I think it would be good if serde supported it.

Requirements

Be able to:

  • access declared namespaces at each location in the document tree (they're inherited)
  • access top-level default namespace
  • access declared container/variant namespace
  • access declared field namespace
  • know whether default namespace was explicitly used or implicitly applied (to preserve document structure for round trips).

Backwards compatiblity

Most currently supported formats don't need this, but there's no good way around it for formats that do. I can only think of hackish ways of passing that information through names (e.g. in WebDAV fashion {namespace}actualName) none of which are ideal.

I believe this could be added as a non-breaking change, but I'm not familiar enough with serde's inner workings to be able to definitively say.

Prior art

  • xmlserde provides a serde-like functionality specifically for XML
    • no support for other formats, even if they're more like XML than those supported by serde
  • XML dom libraries
    • rely on Rc or top-level document store - don't efficiently/transparently integrate into existing Rust code
@dtolnay
Copy link
Member

dtolnay commented Jan 3, 2025

Supporting XML-like documents is not a goal for serde. You would be better off using an XML-specific derive macro.

@Caellian
Copy link
Author

Caellian commented Jan 4, 2025

Thanks for quick response.

I know, but namespacing is possibly something that other formats might want to use. Feel free to close the issue if you don't think adding namespaces is a worthwhile endeavor.

While writing the issue I realized that a custom (De)Serializer could also store this type information in a separate HashMap<TypeId, CustomData>, but it would be cool if serde supported this.

I mean, new (popular) formats are rare these days - if someone wants something like namespaces they usually go for XML. But I believe that's mostly because it's easier to use existing stuff is easier. Namespaces could be really useful for formats intended for consumption by different (otherwise incompatible) programs.

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

No branches or pull requests

2 participants