DDJ: I've noticed the Visual Basic XML features are getting a lot of interest from people who do a lot of work with XML. Visual Basic and C# have taken a different approach here. C# seems to have a "Paste As" approach such that when you paste XML into the code editor it generates the correct XLINQ API code. Visual Basic, on the other hand, supports pasting the literal XML directly into your code. Talk a little bit about that design decision, if you wouldn't mind.
AS: What we've heard over and over is that VB should be all about productivity, and about having the least amount of conceptual burden. With the XML feature set, we didn't want to have an API get in between the XML that you're trying to express, and the code that you have to write. This isn't just a "demo feature" either. You should be able to take any XML 1.0 and copy and paste it in to a VB code file.
The other feedback that we heard during Whidbey development, especially with things like the My feature, is that people only want us to build higher level abstractions if they reflect best practices. As a result, the XML literal feature reflects exactly what you could write with the XLINQ API. There's no magic going on. In C#, you paste as XML, and the development environment translates what you paste into API calls. In VB, you paste the literal XML into your code, and it's the VB compiler that translates it to API calls.
DDJ: Gotcha. You're doing more work at the compiler level so that the developer need only understand XML and the querying syntax, and not the entire underlying XLINQ API.
AS: Right, but at the same time there are going to be situations where you do need to fall back to the API. For example, we have three member axes for XML as part of the Visual Basic language. We have the elements axis, the attributes axis, and the descendents axis, but we haven't introduced the ancestors axis as a Visual Basic language construct. We don't think it's going to be as common for people to need this, and we're pretty conservative about what we put into the language. But, because XML literals translate directly to the XLINQ API, you can always fall back and use that underlying API. It's really seamless to do this.
The other thing that we've done in this CTP relates back to some other feedback that we heard about the XML feature set. People didn't like having the syntax for traversing an XML axis, and accessing XElement members, merged. For example, in previous CTPs, the code that you would write to access an element would be the simple dot operator [Editors Note: For example, User.Name]. However this was confusing. User is an XElement type, and when users type the dot, they expect to see members of the XElement type, not the child nodes. We've changed the syntax so there's a strong distinction between when you're using the XML axes, and when you're accessing the members of the type. [Editors Note: The syntax would now be User.
DDJ: One thing that you mentioned that that's been worked on a lot since the PDC is the editor experience. That makes sense because, frankly, XML can be so big and ugly to work with. In specific, you mention differentiation between working with XML nodes, and XElement members.
AS: And in the future, we hope to have full Intellisense for the underlying XML document that you're working with. This distinction between accessing the XElement axes vs. the members is going to come in handy in providing a better Intellisense experience.
DDJ: Where are you at with some of the other things in the XML ecosystem? For example, what about validating against a schema or transforming using a stylesheet?
AS: XLINQ isn't designed to be a pure replacement for XSLT, there will be times when XSLT is a better tool for the job for transformation. But, because we can produce XML and consume XML, you are going to be able to pretty easily do transformations with XLINQ. With regards to schema validation, the XLINQ API doesn't currently have schema validation. We're looking into how to do it. If we do it, it will be an attribute of the underlying XLINQ API, and not something specific to the integrated XML in Visual Basic. On the other hand we are planning to provide Intellisense for the XML that you're trying to produce, and also, eventually, Intellisense for the XML that you're trying to read from. This won't be strong schema validation, but it will be guidance similar to what exists in the XML editor today, that will help you construct XML that conforms to an existing schema.
DDJ: But the important thing that I assume is that XLINQ will compose with the classes in the System.XML namespace. You may not build schema support right into XLINQ, but you'll still be able to use the schema support that's already in System.XML on the XML that you generate with XLINQ.
AS: Absolutely.
