-
Notifications
You must be signed in to change notification settings - Fork 236
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
Comments
it's only the concrete prefixes |
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 It also looks like the |
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. |
Yes, it should.
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). |
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 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 Either way, I think this can be broken into two pieces.
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? |
|
I linked a PR to resolve the reserved namespaces. |
Would this include things like In order to include it as an attribute in an element, I used However, deserialization of the same blob fails because
|
Looking more closely at the issue and the PR. I think my issue is unrelated. I'll add a ticket. |
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:xml:lang
-- https://www.w3.org/TR/xml11/#sec-lang-tag (meta information about natural language of texts, stacked like namespace definitions)xml:space
-- https://www.w3.org/TR/xml11/#sec-white-space (related: Disabletrim_text
in Deserializer from_reader #285)xsi:nil
-- map<element xsi:nil="true"/>
toNone
if deserialized toOption
The text was updated successfully, but these errors were encountered: