When do xmlns get checked?

Question

I am using the C# XmlSerializer to deserialize some XML that has an xmlns declaration in one part of it (note that I truncated the CipherValue to fit this post):

<EncryptedData
  Id="ZbjUzHbD37LI2DEuiEGX6A7PSnQ+19dutLPiDxZqnFY=3NLz2QA5KCiXVlJSXejhDQ=="
  Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns="http://www.w3.org/2001/04/xmlenc#"
  length="44">
  <EncryptionMethod
    Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
  <CipherData>
    <CipherValue>3NLz2QA5KCiXVlJSXejhDZYYa9sLbv/w42....+PsLMCfRFN//StgbYoRqno3WQ==</CipherValue>
  </CipherData>
</EncryptedData>

With this XML loaded into Visual Studio, VS highlights the "+" character in the Id attribute, and the existence of the length attribute as being errors. I assume that the only way that VS could know this, is if it went and examined the URLs in the Type and xmlns attributes. VS making this type of Internet request is sort of OK to me, as I have given VS permission to do things like check for updates etc, so I already know that it will be visiting the Internet on its own terms.

However, the above XML doesn't deserialize in my command line program unless I remove the xmlns (or force a blank namespace via a custom XML Text Reader), so I am assuming that my command line program is also verifying the xmlns by visiting that URL.

This is slightly troubling to me, as although I understand what an xmlns URL is, I haven't explicitly given my program permission to go visit the Internet. In addition, the use case of this program is run locally and analyze some XML generated by another local only program. The idea that it could be making Internet requests was way off my radar.

As well as deserializing this XML, I am also doing some XSLT using the c# XslCompiledTransform class. What I finally realized there was that when performing a transform, the xmlns attribute is not something that you can manipulate with XSLT as the transforms are performed on the conceptual data of the XML and not on the raw XML string. Thus the transform has somehow processed the xmlns when reading the XML.

My questions are:

1. Is the XmlSerializer class making an implicit Internet connection to the xmlns?
2. Is the XslCompiledTransform class doing something similar?
3. If there are implicit connections, do they represent a security risk?
4. And if so, what can be done to mitigate it (aside from forcing a blank namespace)?

---

As per @canton's request, here is the class definition I'm using for the EncryptedData, as well as the fragment showing where it is referenced

    ...
    [XmlElement("EncryptedData")]
    public EncryptedData EncryptedData { get; set; }
    ...

    public class EncryptedData
    {
        [XmlAttribute("Id")]
        public string Id { get; set; }

        [XmlAttribute("Type")]
        public string Type { get; set; }

        [XmlAttribute("xmlns")]
        public string Xmlns { get; set; }

        [XmlAttribute("length")]
        public int Length { get; set; }

        [XmlElement("EncryptionMethod")]
        public EncryptionMethod EncryptionMethod { get; set; }

        [XmlElement("CipherData")]
        public CipherData CipherData { get; set; }
   }

Answer 1

Firstly, a namespace is not a URL! A namespace is just an arbitrary string. The reason that they usually look like URLs is that, If everyone uses a URL under a domain that they own or control then there is no chance of a name clash with anyone else's element of the same name. Even when the namespace is in URL form there is not usually anything actually there and NO tool will try to access it.

Visual Studio maintains a directory of schema files for all Microsoft and standard schemas. You can add your own there if you want intellisense when editing the XML. Check the documentation for the location.

In the absence of an xsd known to VS, the only attribute that is understood by either VS or XmlSerializer is xmlns.

The reason your deserializer wont work is that your elements need to know the namespace. It's easy to miss this as all the examples you will see on the internet tend to not use namespaces.

A good way to go about deserializing is to use xsd.exe to generate classes from either an xsd schema OR a sample data file - The code produces is horrible but can guide you in your prettier version - If you had done this you would have seen that the attributes on the generated code include a namespace e.g.

[XmlElement("EncryptedData", Namespace="http://www.w3.org/2001/04/xmlenc#"]

When creating this manually it is obviously cleaner to put the namespace in a const string.

The rules about what does and does not have a namespace qualifier can be quite confusing hence my recommendation to generate sample code first.

If you actually want schema validation you have to explicitly do it yourself by passing a validating XmlReader to XmlSerializer i.e. validation is, optionally, done as part of reading the XML not as part of the deserialization.