Extracting Metadata - Understanding XSD’s Role in Code Generation
(Page 11 of 22 )
XSD plays several roles in code generation. It’s the base schema description language used in XML editing, it’s used by the code generation harness, and it’s a metadata source. XSD is a poor metadata source because it doesn’t catch the richness of other sources such as SQL-92 databases and because it’s awkward to use. To solve the second problem, you can use a two-phase extraction—first building the XSD and then translating it into a friendly format. When you don’t have a rich underlying source, XSD provides effective metadata source.
What’s the difference between the structure of an XSD and the friendly XML I’m suggesting for code generation? The basic differences are that the friendly metadata contains familiar terms such as Table and Column in the element names and contains all information about a table within its hierarchy (descendant elements and attributes). You can compare these formats as you see both XSDs and the friendly XML target (which is the same target as SQL-92 databases) in the next few sections. XSD also provides only a subset of that metadata provided by the databases. The XSDToFriendlyXML.xslt template available on the Web site translates standard XSDs to this friendly XML format. Appendix B discusses this XSLT template.
You usually retrieve the XSD by a process called inference. Inference guesses at schema rules based on a sample XML file. XSD is an important but difficult to grasp technology; there’s more about XSD in Appendix A.
Inferring XSD Schemas XSD is itself XML, making it usable with a variety of tools, including XML editors and XSLT. That’s cool, but XSD schemas are nonintuitive, ugly, and really hard to build. That’s the bad news. The good news is that you may never have to create one from scratch because there are a variety of tools to infer the schema.
The most accessible inference to you is probably the one supplied with .NET—one of several operations performed by XSD.EXE. (See Footnote 11.) Table 2-1 shows the different input options for XSD.EXE when you run it from the command line. If you have Visual Studio .NET installed, the easiest way to find XSD.EXE is to open a Visual Studio command prompt. This sets the path to include [Program Files]\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin, which contains XSD.EXE.
(Footnote 11. There’s another inference engine downloadable from Microsoft (http://www.gotdotnet.com/team/ xmltools). If you don’t find it, try searching for XSD Inference on the gotdotnet site. This engine can build XSDs from XML files that choke XSD.EXE. Another benefit of this alternate inference engine is that you can call it multiple times with different XML documents to evolve a schema. I have used XSD.EXE in this book so you don’t have to download an extra tool.)
INPUT | OUTPUT | IMPORTANT SWITCHES | SWITCH DESCRIPTION |
.xdr | XSD schema | /o:<directoryName> | Specifies output directory |
.xml | XSD schema | /o:<directoryName> | Specifies output directory |
.xsd | Strongly typed DataSet or class source code | /o:<directoryName> | Specifies output directory |
| | | |
| | /d | Produces strongly typed DataSet |
| | / c | Produces strongly typed class |
| | /l:<languageName> | Specifies language as CS (C#), VB (Visual Basic .NET), JS ( JSharp) |
| | | |
| | /e:<elementName> | Specifies specific elements to generate (defaults to all) |
| | | |
.dll or .exe | XSD schema for specified types | /o:<directoryName> | Specifies output directory |
| | /t:<typeName> | Specifies the specific types to generate |
The XSD.EXE application’s behavior when you pass a file with the extension .xdr, .xml, .dll, or .exe is important in the context of metadata. With all of these file types, the output is an XSD file. (See Footnote 12.) Because you can also express DataSets as XML, you can infer an XSD schema for anything you can stuff into a DataSet. As a result, you can use XSD.EXE to create a schema for most things that you would classify as data. Visual Studio .NET uses the same inference engine to create XSDs if you right-click an XML document and select Create Schema.
(Footnote 12. A separate key role of XSD.EXE is creating the ADO.NET strongly typed DataSet.)
NOTE: You can also directly create XSDs with Visual Studio .NET. The XSD design surface is displayed when you add a DataSet or XSD to your project. These use the same design surface because a DataSet is defined within Visual Studio .NET as an XSD. Although you may only be familiar with the graphical design tool of the XSD/DataSet surface, you can see the XSD itself if you select the XML tab. You can also programmatically infer a schema for an ADO.NET DataSet using the GetXMLSchema method. |
 This is from Code Generation in Microsoft .NET, by Kathleen Dollard (Apress, ISBN 1590591372). Check it out at your favorite bookstore today. Buy this book now. |
Next: Exploring the Structure of an XSD >>
More Database Articles
More By Apress Publishing
/ 18 
