More compatibility with standard XmlDocument.

[denis-ivanov]

Types of Changes

Use XmlElement.Prefix empty string instead null.

Prerequisites

Please make sure you can check the following two boxes:

• I have read the CONTRIBUTING document
• My code follows the code style of this project

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• Breaking change (fix or feature that would cause existing functionality to change)
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

Description

I'm trying to solve AngleSharp/AngleSharp.XPath/issues/18 issue. I found that AngleSharp.Xml uses null prefix for XmlElement, but standard XmlDocument uses empty string. I consider we need more compatibility with standard XmlDocument.

Below the same test for XmlDocument

[Test]
public void ParseValidXmlPrefixShouldBeEmpty()
{
    var source = "<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\" />";
    var document = new XmlDocument();
    document.LoadXml(source);
    Assert.AreEqual("", document.DocumentElement.Prefix);
}

[CLAassistant]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Denis Ivanov seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[FlorianRappl]

The problem with this approach is that this is unfortunately not the standard, i.e., if no prefix is given it should be null. If we would just change it to an empty string then things will automatically break that respect the W3C DOM specification.

See, e.g., MDN how prefix on Element (note, this not HTMLElement, i.e., it also applies to XMLElement) should behave. Also the official spec mentions null explicitly a couple of times for determining behavior based on prefix.

Is there another way around it? Maybe by using a normalized version of prefix?

[denis-ivanov]

@FlorianRappl thank you, I will try to find another solution.

[FlorianRappl]

Thanks for understanding @denis-ivanov .

Maybe let's chat (via skype?) later today. I have a feeling you understand the problem already quite well. If we discuss various ways maybe a viable solution comes up.