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

Recognize and process some special XML attributes #464

Open
Mingun opened this issue Aug 25, 2022 · 9 comments
Open

Recognize and process some special XML attributes #464

Mingun opened this issue Aug 25, 2022 · 9 comments

Comments

@Mingun
Copy link
Collaborator

Mingun commented Aug 25, 2022

All names starts with xml (case-insensitive) are reserved by the XML standard, and some of them has special meaning. quick-xml could process some of them:

@funkyfuture
Copy link

it's only the concrete prefixes xml and xmlns that are globally defined: https://www.w3.org/TR/xml-names/#xmlReserved

@wt
Copy link
Contributor

wt commented Jan 24, 2023

The NamespaceResolver doesn't seem to have any entries by default. This seems incorrect by my reading of https://www.w3.org/TR/xml-names11/#xmlReserved. Shouldn't the xml namespace be definitionally mapped to http://www.w3.org/XML/1998/namespace?

It also looks like the xml namespace should not be overrideable.

@wt
Copy link
Contributor

wt commented Jan 25, 2023

FWIW, xmlns also has a similar definitional mapping. However, given how xmlns is handled now in quick-xml, that probably doesn't need to be handled the same way. However, I am wondering if handling them the same way would make it more consistent to deal with reserved namespaces like this.

@Mingun
Copy link
Collaborator Author

Mingun commented Jan 25, 2023

Shouldn't the xml namespace be definitionally mapped to http://www.w3.org/XML/1998/namespace?

Yes, it should.

It also looks like the xml namespace should not be overrideable.

It seems that override it is technically possible, but such XML document is incorrect (but seems still well-formed and valid, but not namespace-well-formed because overriding violates namespace constrains).

@wt
Copy link
Contributor

wt commented Jan 25, 2023

Well-formed docs have to have a root element conforming to the description at https://www.w3.org/TR/xml11/#NT-element. This section says the following:

This specification does not constrain the application semantics, use, or (beyond syntax) names of the element types and attributes, except that names beginning with a match to (('X'|'x')('M'|'m')('L'|'l')) are reserved for standardization in this or future versions of this specification.

This seems to indicate that such attr names with xml at the front are reserved. AFAICT, this includes the namespace part of the attr name. Would this mean that have an attr like xmlfjdkslafjdsl=3 make the document not well-formed? Given that the doc has to be well-formed to be valid, wouldn't that also make the doc invalid?

Either way, I think this can be broken into two pieces.

  1. Initialize the name space resolver so that xml is already resolvable.
  2. If overriding the xml namespace should be blocked, do that also.

I think that we have agreement that 1 is worth doing now. I have an idea for that that I will generate a PR for. I will link it to this issue.

For 2, my opinion is that maybe we should not allow overriding xml namespace by default, but we should maybe have a flag that allows it. What do you think of that?

@Mingun
Copy link
Collaborator Author

Mingun commented Jan 25, 2023

  1. Agreed, please make a PR
  2. I think we should check other popular XML libraries, and do in the similar way

@wt
Copy link
Contributor

wt commented Jan 25, 2023

I linked a PR to resolve the reserved namespaces.

@rrichardson
Copy link

rrichardson commented Feb 15, 2023

Would this include things like xsi:type as well?

In order to include it as an attribute in an element, I used #[serde(rename = "@xsi:type")] which causes it to serialize correctly, e.g. <MyElement xsi:type="MyType">

However, deserialization of the same blob fails because

"missing field `@xsi:type`"

@rrichardson
Copy link

Looking more closely at the issue and the PR. I think my issue is unrelated. I'll add a ticket.

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

4 participants