Core11: an "XML pattern" to break free from XDocument/XElement

[This post is part of a series, "wish-list for future versions of VB"]


IDEA: An "XML pattern". Currently we have a "collection pattern" so that For Each and "New From {...}" can be used on arbitrary user-defined types. And we also have a "query pattern" so that LINQ queries can be used on arbitrary user-defined types. We should also have an "XML pattern" so that XML literals and XML query operators can bind to arbitrary user-defined types, and also to the other XML-like tree structures provided by Microsoft.


SCENARIO: Silverlight. Currently we have to use the ugly workaround that we query the DOM HtmlElement tree, then convert it into XDocument/XElement so we can use XML literals/queries on it, and then convert it back. Here's the kind of code we'd like to write:

        ' XML query syntax:

        Dim doc As Windows.Browser.HtmlDocument = Windows.Browser.HtmlPage.Document

        Dim e As Windows.Browser.HtmlElement = doc.getElementById("link")

        Dim href = e.@href

        Dim children = e...<a>


        ' XML construction syntax:

        Dim e2 As Windows.Browser.HtmlElement = <b>Hello</b>




SCENARIO: XAML. It's common to construct XAML on-the-fly, e.g. to populate your UI based on what you get from a schema or database. At the moment you have to turn the XML literal into a stream, and then XAML has to reconstruct it from the stream. It feels ugly...


        ' current workaround for constructing XAML with XML literals:

        Dim UI = <Label Name="Label1">This is turned into </Label>

        Me.Content = System.Windows.Markup.XamlReader.Load(UI.CreateReader())



SCENARIO: User-defined data structures. Sometimes we want to construct user-defined data-structures that look like trees or lists. At the moment we can construct them with object initializers and collection initializers, but it feels like XML would be a more natural way to construct and query these structures. Note: we specifically want to store this data in our own strongly-typed classes with their own behaviors, e.g. INotifyPropertyChanged, property-validation &c: it's not adequate for us to use XML. We'd also want everything (construction as well as querying) to be strongly typed. It'd also be good if the decision about what kind of node to add could be made at runtime e.g. based on what attributes are provided.

Class Customer

    Public Property Name As String

    Public Property Telephone As String

    Public Orders As IEnumerable(Of Order)

End Class


Dim x As Customer = <Customer Name="Fred" Telephone="555-621-6121">

                       <Order Id="1234" Status="fulfilled"/>

                       <Order Id="5678" Status="unfulfilled"/>



Dim todo = From o In Customers...<Order> Where o.Status = "unfulfilled"



<Extension()> Sub AddAttribute(t As Customer, attr As String)

<Extension()> Sub AddNode(t As Customer, node As Order)

<Extension()> Sub AddAttribute(t As Order, attr As String)

<Extension()> Function Descendants(t As Customer, tag As String) As IEnumerable(Of Order)




Comments (4)

  1. Dzonny says:

    This is the most powerful and most interesting item in your wish-list I’ve seen till now! I love it.

    If it will really work it can than be used for CodeDOM, WinForms, LINQ-to-Entities classes. And if it will treat XML not as only XML but as sort of structured object initializer – so type-safe checks, undefined attributes banned at compile time etc. I’ll really love it!

  2. Kevin Ryall says:

    This has absolutely massive potential – I love the user defined data structures idea. I’m already thinking of so many ways I could use this…

  3. Jeff says:

    This is my favorite idea so far. I agree with Donny – I’d absolutely love to see XAML as a strongly-typed initializer usable in code.

  4. Kyralessa says:

    Very interesting.  I particularly like that last scenario with the XML syntax for constructing a deep object graph.

Skip to main content