You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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 fromSerializer
,Deserializer
andVisitor
, 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:
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 XMLRc
or top-level document store - don't efficiently/transparently integrate into existing Rust codeThe text was updated successfully, but these errors were encountered: