Is it possible not to associate a namespace?

[mlevkov]

Hello,

I have an xml compatible file, however, it does not use the namespace associations in all scopes. Is it possible to still retain the namespace value, but not associate the namespace with a struct?

For example:
I have this file (will skip for brevity)

<MPD mediaPresentationDuration="PT1H50M47S" minBufferTime="PT19S" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="static" xmlns="urn:mpeg:dash:schema:mpd:2011">
<!-- skip for brevity ... -->
</MPD>

the xmlns="urn:mpeg:dash:schema:mpd:2011" is signaled within the library, and appropriately asked to be used. However, I would like to not have such association, if possible.
At the moment, I'm signaling the struct with

#[yaserde(root="MPD", prefix="mpd", namespace="mpd: urn:mpeg:dash:schema:mpd:2011")]

and all the underlying associated structs.

I then get the following output

<mpd:MPD xmlns:mpd="urn:mpeg:dash:schema:mpd:2011" mediaPresentationDuration="PT1H50M47S" minBufferTime="PT19S" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="static"><ProgramInformation moreInformationURL="www.castLabs.com" />
<!-- skip for brevity ... -->
</mpd:MPD>

I'd, however, and, if possible, to have the same output as original. The reason for such, is that I sometimes get a file where I need to only modify one element without changing anything else. To avoid any inconsistancies or structural changes, I'd like to output the same as original only with changed value.

Additionally, is it possible to signal retention of attribute positioning in the order they were originally in? At the moment, the attributes appear to serialize in an unordered fashion.

[MarcAntoine-Arnaud]

Hello again,

It's funny I have also coded something similar to manipulate DASH manifest here.

Regarding you questions:

• currently it's not possible to define only one time the namespace. In fact if we do that it's not a generic model as each structure can be use into any model as a reference (maybe it's no recommended to do that but can be usefull). So to be precise it can be great.
  The second part is the fact of the derive macro just generate code for each structure. We don't take a look to linked structures. That's why it can be complex to implement too.
  Maybe we can provides an helper like an attribute with a pointer function in argument to return the list of namespaces. What do you think ?
  It can look like:

fn dash_namespaces() -> Vec<(String, String)> {
  vec![("mpd".to_string(), "urn:mpeg:dash:schema:mpd:2011".to_string())]
}

#[derive(Debug, Clone, PartialEq, YaSerialize, YaDeserialize)]
#[yaserde(prefix = "mpd", namespaces = "dash_namespaces")]
pub struct Role {
....
}

[MarcAntoine-Arnaud]

To your second question, about changing nothing it can't happen.
The simple reason is that:
The deserializer take information in disorder (xml attributes don't needs to ordered for example).
So once the model is loaded you don't keep information about placement, so we cant but back in the same order.

This also implies to store order somewhere, and it's not possible as in you struct you don't have place for that.

For the serializing order I think it's namespaces first and after it's in structure placement order.

[mlevkov]

Hello,

I saw your library, it is very ironic that I've started to develop a library since I was not able to find a DASH (until now ;)) in Rust. I've many use cases that I'd like to cover. Your library is quite excellent and I'd like to applaud for the effort. In fact, I've landed here because yaserde offers many of the features that DASH manifest creation and manipulation requires. All the notes for the foundational elements that I thought would be needed are covered with the tool you linked to. I can either continue to contribute to that tool and abandon development of my own, or use yaserde library, fork or borrow concepts from your tool (of course with your permission)and develop own with features that I need. My basic premise is a development of media manifest manipulation microservice (DASH + HLS + Others), which I've started here. Ultimately development of media packager in Rust ;).

Development of pointer function is an excellent idea. I've dealt with removal of namespaces through post processing because I'm just learning ;) here . However, this is a much better way of handling such cases. Totally for it. Though, would be interesting to see how it is used afterwards.

Certainly positioning is not a big deal and I agree with you that it is not critically sufficient to complicate the process because XML's flexibility.

[MarcAntoine-Arnaud]

Hello @mlevkov,

It can be great if we can work together on this kind of features, I also need to support soon HLS etc.
Maybe it can make sense to export the base of the library (because it's liked to the Media Cloud AI project), but the base is here.

For the initial issue I think to add a new attribute default_namespace which serialise XML without prefix for this namespace.
So it can looks like:

#[derive(Debug, Clone, PartialEq, YaSerialize, YaDeserialize)]
#[yaserde(prefix = "mpd", namespaces = "dash_namespaces", default_namespace="mpd")]
pub struct Role {
....
}

[MarcAntoine-Arnaud]

If it's fine for you, close this PR.
We can discuss about DASH manifest in private (maarnaud@media-io.com)

[mlevkov]

Thank you!

[mlevkov]

Hello @MarcAntoine-Arnaud ,

I am getting errors when I use this feature. Should I paste the issues in this ticket or open a new one?

[MarcAntoine-Arnaud]

Hi @mlevkov ,
Can you use a new one mentioning a link to that issue.

Thank you !