다음을 통해 공유

Typed XML programmer -- Welcome to LINQ!

  • 아티클

Announcing the LINQ to XSD Preview

 

Ever since PDC 2005, when XLinq was unleashed (now called LINQ to XML), we have been receiving questions about the possibility of a typed XML programming approach in the LINQ world . Not surprisingly, we have been pondering about this problem indeed. This was also mentioned in the XLinq overview. (Please, also see the “Typed XML programmer” series of blog posts.) For some time now we have been focusing incubation efforts on typed XML programming for LINQ. One overall approach is to engage in a mapping of XML types to ‘plain’ object types, that is, classes with ‘fields that maintain state’ and with support for XML serialization and de-serialization. While this approach would effectively reduce typed XML programming to ‘LINQ to objects’ + de-/serialization, it potentially leads to a lossy and complicated XML programming model. Consequently, our efforts have focused on a more natural and faithful approach which builds on top of LINQ to XML.

 

Today we are happy to announce the LINQ to XSD Preview Alpha 0.1:

 

 

We'd like to encourage everyone with a stake in XML programming and ‘schema-first’ applications to take a look at LINQ to XSD and send your observations, questions and suggestions this way; we'll be eagerly waiting for feedback! The whole point of this incubation project is to investigate options for the future of typed XML programming. We are still very early in the design process. So your feedback is critical and can help shape the design of the project as we are going forward.

 

This is pre-release software; it is provided “as-is” – we’re crucially interested in getting feedback from customers but we can’t make any guarantee with regard to supporting or maintaining this software or releasing future versions on any specific timeline. In particular, while the underlying LINQ to XML technology is expected for Orcas, no such commitment exists for LINQ to XSD.

 

 

What is LINQ to XSD?

 

LINQ to XSD provides .NET developers with support for typed XML programming on top of LINQ to XML. While the LINQ to XML programmer operates on generic XML trees, the LINQ to XSD programmer operates on typed XML trees -- instances of .NET types that model the XML types of a specific XML schema (XSD) . To get an idea, consider the following C#3.0 fragment for a LINQ to XML query that computes the total over the items in a XML tree for a purchase order:

 

     (from item in purchaseOrder.Elements("Item")

      select (double)item.Element("Price")

           * (int)item.Element("Quantity")

     ).Sum();

 

Using LINQ to XSD, the query is written in a much clearer and type-safe way:

 

     (from item in purchaseOrder.Item

      select item.Price * item.Quantity

     ).Sum();

 

LINQ to XSD can be used whenever you have an XML schema available, or you are willing to infer a schema from the XML data at hand. LINQ to XSD is integrated into Visual Studio; so you just tag an XML schema as an ‘LINQ to XSD schema’, build your project, and the automatically derived object model is then part of your solution -- just as if XML schemas were .NET types.

 

The derived object model enforces various validation constraints imposed by the underlying XML schema -- quite similar to other technologies for so-called X/O mapping or XML data binding. Two important aspects of LINQ to XSD are its integration into the LINQ family of technologies and its foundation on ‘XML objects’ as opposed to ‘plain objects’. That is, the derived object models provide XML semantics in terms of XML fidelity and programming idioms. To this end, the derived object models define .NET types (classes) that are essentially views on generic LINQ to XML trees. Typed member access and other typed axes can be used in most cases, while untyped tree access is still available, when necessary.

 

 

What’s in the release?

 

  • An overview document -- also available separately.
  • A mapping tool deriving object models from XML schemas.
  • Visual Studio templates for C# LINQ to XSD projects.
  • A command-line interface for the abovementioned tool.
  • Samples (scenario-based and API-based).
  • A technical user manual.
  • A mapping documentation.

 

 

LINQ to XSD-related pointers

 

 

 

We really look forward receiving your feedback.

 

Ralf Lämmel

Data Programmability / XML team

Comments

  • Anonymous
    November 27, 2006
    PingBack from http://blogs.msdn.com/ralflammel/archive/2006/11/13/table-of-contents-for-typed-xml-programmer-series.aspx

  • Anonymous
    November 27, 2006
    Woo hoo!  I wondered when y'all were going to post this.  :)

  • Anonymous
    November 27, 2006
    The comment has been removed

  • Anonymous
    November 27, 2006
    Voici un nouveau venu dans la famille " Linq To .... " qui risque de plaire à pas mal de développeurs

  • Anonymous
    November 27, 2006
    After working sometime with LINQ this becomes quite a missing feature. This will make my life way easier

  • Anonymous
    November 27, 2006
    I was waiting for this! :)

  • Anonymous
    November 28, 2006
    Not to be ungrateful, but I'm a little disappointed that "typed" XML programming is only putting a typed wrapper around raw XML. I'm not quite satisfied with setters and getters on numeric properties having to format and parse strings every time. What I really want is XML objects that store the data according to the XSD type and when using XmlReader and XmlWriter call the appropriate strongly-typed methods, so strongly-typed data can be copied from one XML object to another via XmlReader or XmlWriter without formatting, parsing, or even boxing.

  • Anonymous
    November 28, 2006
    Workflow/BPM/WCF/SOA David Chappell presents arguments both pro and con as to whether Microsoft qualifies

  • Anonymous
    November 28, 2006
    Hi MKane91301, thanks for your reflection. When you say that you are a little disappointed because typed XML programming is only [my emphasis] putting a typed wrapper around raw XML, then you seem to focus on performance, which is important, but it is not the only dimension we need to keep an eye on. The wrapper approach has the distinguished advantage of reusing existing LINQ to XML objects, as is, and keeping them in tact. This is an extremely valuable feature in a setting where we assume that people mostly use LINQ (LINQ to XML) and occasionally (hopefully often) want to create typed views w/o disturbing the application context of these XML trees. One can try to use caching to get the best of both worlds. However, this is a sort of wormhole I should blog about in all detail some day. Also, a big problem, IMHO, with the approach that stores parts of trees or just values in plain fields (as you seem to ponder about) is that this leads eventually to the lossiness and complexity of serialization approaches. Your feedback is very appreciated. Thanks, Ralf Laemmel

  • Anonymous
    November 28, 2006
    why generated classes are not partial ? (or they are but in l2xsd_overview.doc they are not in exapmle ;p)

  • Anonymous
    November 28, 2006
    Hi rad9k, sure the generated classes are partial (and public). The pseudo code in the overview doc favored to elide these modifiers, but this may be debatable as I sense from your email. Thanks, Ralf

  • Anonymous
    November 28, 2006
    Now that I kicked off LINQ to XSD (a piece of XMLware), it’s time to rest and think about IT and entropy

  • Anonymous
    November 28, 2006
    Microsoft XML Team's WebLog : Typed XML programmer -- Welcome to LINQ! Download details LINQ to XSD LINQ를

  • Anonymous
    November 28, 2006
    How is Linq-to-XSD different from generating classes via xsd.exe, loading these typed objects into memory via XmlSerializer, and then running plain Linq on in-memory objects? Thanks - George

  • Anonymous
    November 29, 2006
    Georges question is something that probably many people have in mind We had some articles on this topic here in xml team blog, but of course it will be interesting to get back to this subject ;ppp For sure l2xsd have two advantages:

  • generated classes inherit from XElement ; so they are interopable with rest of xlinq infrastructure. What doest that mean? Generated classes can be treated generlicly as untyped xml
  • generated classes are doing some sort of xsd-based constraints checks when making modifications. I had not looked at generated code (performance overhead ? can those constrains checks be turned off & on by some document/element scope ?) but it seems that there is something like this anything more ?
  • Anonymous
    November 29, 2006
    hmm and besides there is some quite important subject XML INDEXING for querying ;p As far as I know in System.Xml & in xlinq there is no xml indexing at all As such indexing needs some way to specify what subelements/attributes should be indexed it is nice to get back to this topic while working with xsd. Maybe some sort of “indexthis” annotations in xsd ? Some might say “indexing is for databases”. Yes it is. But now ram is big enough to work with so called “in memory” databases. So instead of using sql server xml indexing we might have linq based in memory xml database. We need two things:
  • indexing. As mentioned above
  • disk written change log. This could be embedded in generated setters methods Of course some transaction support and locking will be nice, but those two are quite a lot ;p And Of course same for linq2objects. We need indexes supporting collections with index aware IQueryable implementations. It is  A MUST

  • Anonymous
    November 29, 2006
    LINQ to XSD has been released in alpha form by the XML team, and they are requesting feedback. You can...

  • Anonymous
    November 29, 2006
    The comment has been removed

  • Anonymous
    November 30, 2006
    LINQ to XSD has been released in alpha form by the XML team, and they are requesting feedback. You can...

  • Anonymous
    December 01, 2006
    Hi, do you guys support recursive element definitions in XSD? If so, how? Is it documented anywhere? I've found it documented all over as supposedly possible in XSD, with numerous examples, but the .NET 2.0 XML parser barfs and claims the element is "not declared". I can do it with something resembling a forward declaration (found that in the sqlxml docs), but then of course the "children" aren't validated at all.

  • Anonymous
    December 01, 2006
    Ed Plunkett, if you mean (mutually or directly) recursive element declarations, yep, of course, this is covered by XSD and so it is by LINQ to XSD. Not sure that I understand what XML APIs you are having problems with. Please send me a repro, if you like, ralfla@microsoft.com. I should be able to forward it as appropriate. Thanks, Ralf Laemmel

  • Anonymous
    December 06, 2006
    I downloaded the LINQ to XSD alpha preview. After reading the disclaimer multiple times (it seems Microsoft...

  • Anonymous
    December 08, 2006
    DonXML says (referring to PLinq): "Overall, this stuff looks very cool.  And it seems that LINQ is going to be a big part of how they plan to implement it, giving me even more of a reason to get going on LINQ before all the cool kids realize that WPF, WCF and WF are yesterday's news, and LINQ is where it is at ;)" The same applies to LINQ for XSD. See http://oakleafblog.blogspot.com/2006/12/reduce-objectxml-impedance-mismatch.html. --rj

  • Anonymous
    December 22, 2006
    In a comment on “ More Haskell in Java 7 or 8? ”, I get this question “How does your `Retroactive Interface

  • Anonymous
    January 12, 2007
    I had a lot of time to think about Elliotte Harold's call for XML predictions on the way home from Redmond

  • Anonymous
    January 15, 2007
    I haven't written about LINQ to XSD yet on this blog. So, here goes... LINQ to XML has been revealed

  • Anonymous
    January 15, 2007
    I haven't written about LINQ to XSD yet on this blog. So, here goes... LINQ to XML has been revealed

  • Anonymous
    January 16, 2007
    Architecture More competition! No, I am very glad to see my good friend and Architect Harry start a series

  • Anonymous
    March 07, 2007
    Como no podía ser de otra forma, y después de hablar de las bases de LINQ y de LINQ To SQL , desde el

  • Anonymous
    March 19, 2007
    x/omappingxmldatabindinglinqhttp://blogs.msdn.com/xmlteam/archive/2006/11/27/typed-xml-programme...

  • Anonymous
    April 30, 2007
    The comment has been removed

  • Anonymous
    July 13, 2007
    There are two very important LINQ implementations to keep your eye on as we near the release of Visual...

  • Anonymous
    December 11, 2007
    Workflow/BPM/WCF/SOA David Chappell presents arguments both pro and con as to whether Microsoft qualifies

  • Anonymous
    January 26, 2008
    www website website http http://silviaolmeda.bz.tc/ www

  • Anonymous
    September 16, 2008
    When I was writing the LINQ to XML documentation , Ralf Lämmel was the program manager for LINQ to XSD

  • Anonymous
    November 11, 2008
    Офіційні: LINQ to SQL (DLINQ) LINQ to XML (XLINQ) LINQ to XSD LINQ to Entities BLINQ PLINQ Неофіційні

  • Anonymous
    November 17, 2008
    Офіційні: LINQ to SQL (DLINQ) LINQ to XML (XLINQ) LINQ to XSD LINQ to Entities BLINQ PLINQ Неофіційні

  • Anonymous
    November 21, 2008
    Architecture More competition! No, I am very glad to see my good friend and Architect Harry start a series

  • Anonymous
    December 03, 2008
    Architecture More competition! No, I am very glad to see my good friend and Architect Harry start a series like mine and Mike's with his Morning Coffee 10 . I'm going to have to quicken the pace-) Software Development/Tools JetBrains has released their