{"id":17666,"date":"2007-06-17T12:24:48","date_gmt":"2007-06-17T20:24:48","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/powershell\/?p=17666"},"modified":"2019-05-16T12:26:53","modified_gmt":"2019-05-16T20:26:53","slug":"using-a-dsl-to-generate-xml-in-powershell","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/powershell\/using-a-dsl-to-generate-xml-in-powershell\/","title":{"rendered":"Using a DSL to generate XML in PowerShell"},"content":{"rendered":"

A while back, Jeffrey posted an article on how to use string expansion and XML casts to build XML documents in-line in a PowerShell script:\nhttp:\/\/blogs.msdn.com\/powershell\/archive\/2007\/05\/29\/using-powershell-to-generate-xml-documents.aspx\nThe overall feel of the approach that Jeffrey described is very much like that of ASP, JSP, PHP on any of the other systems that use \u201choles\u201d to embed code to dynamically generate document content within the document itself. Ari over at the Windows Core Networking blog had some concerns about this approach for various reasons. You can see his comments at:\nhttp:\/\/blogs.msdn.com\/wndp\/archive\/2007\/06\/15\/offtopic-another-way-to-generate-xml-in-powershell.aspx\nAs an alternative, he suggests a mixed approach that combines strings and the .NET XmlDocument APIs. The result looks like:\n$doc = [xml] “” \n$elem = $doc.CreateElement(“ns:TestBuild”)\n$elem.SetAttribute(“Product”, $Product);\n$elem.SetAttribute(“Lab”, $Lab);\n$elem.SetAttribute(“BuildNumber”, $OSBuildNumber);\n$elem.SetAttribute(“SPBuildNumber”, $SPBuildNumber);\n$elem.SetAttribute(“TimeStamp”, $BuildLabString.Split(“.”)[4]);\n$elem.SetAttribute(“SKU”, $SKU);\n$elem.SetAttribute(“Language”, $SystemLocale.Split(“-“)[0].Trim());\n$elem.SetAttribute(“Culture”, $SystemLocale.Split(“-“)[1].Trim());\n$elem.SetAttribute(“Architecture”, $Processor);\n$elem.SetAttribute(“Type”, $Type);\n$doc.get_ChildNodes().Item(1).AppendChild($elem) | out-null\n$elem = $doc.CreateElement(“ns:Implementation”);\n$elem.SetAttribute(“type”, “WTTResource”);\n$elem.SetAttribute(“ResourceName”, $Name );\n$elem.SetAttribute(“ResourceId”, $ResourceId );\n$elem.SetAttribute(“ResourceConfigurationId”, $Id ); \n$doc.get_ChildNodes().Item(1).AppendChild($elem) | out-null \n$doc.get_ChildNodes().Item(1).SetAttribute(“GUID”, [GUID]::NewGuid().ToString() );\n$doc.save((Join-path $RolePath “RoleInstance.xml”)) \nNow, while this works fine, it really isn\u2019t much different from what you\u2019d do in C# or VB.Net. In theory, PowerShell is supposed to make things like this easier. \nA general approach that languages like Ruby and PowerShell use to simplify these tasks is to create a DSL or Domain-Specific Language. (Obligatory plug \u2013 I cover some of this in Chapter 8 of my book. Plug completed). The idea is to build a Domain-Specific Language (DSL) or \u201clittle language\u201d that is designed to express solutions in a problem domain clearly and concisely. After playing around with notation for an hour or so, I came up with something that let me re-write ARI\u2019s example as:\n$doc = .\/New-XmlDocument {\n @{<\/p>\n

element = “ns:TestBuild”<\/p>\n

attributes = @{<\/p>\n

Lab = $lab<\/p>\n

BuildNumber = $buildnumber<\/p>\n

SPBuildNumber = $OSBuildNumber<\/p>\n

TimeStamp = $BuildLabString.Split(“.”)[4]<\/p>\n

SKU = $sku<\/p>\n

Language = $SystemLocale.Split(“-“)[0].Trim()<\/p>\n

Culture = $SystemLocale.Split(“-“)[1].Trim()<\/p>\n

Architecture = $Processor<\/p>\n

Type = $Type<\/p>\n

}<\/p>\n

}<\/p>\n

@{<\/p>\n

element = “ns:Implementation”<\/p>\n

attributes = @{<\/p>\n

type = “WTTResource”<\/p>\n

ResourceName = $Name<\/p>\n

ResourceId = $ResourceId<\/p>\n

ResourceConfigurationId = $Id<\/p>\n

}<\/p>\n

}<\/p>\n

}<\/p>\n

$doc.save((Join-path $RolePath “RoleInstance.xml”)) <\/p>\n

What I\u2019ve done here is create a script New-XmlDocument. This command takes a scriptblock as its only argument. The scriptblock contains a number of hash literals that describe the elements to create. Each hashtable contains two members \u2013 the type of element to build and the list of its attributes. The attribute list is, in turn, a hashtable with name\/value pairs for each attribute. A similar approach could be used to add child notes at each level. The script to process this data structure turns out to be quite simple:\nparam ([scriptblock] $sb)<\/p>\n

# Hard coded for now – should be parameterized<\/p>\n

$doc = [xml] ‘‘ #<\/p>\n

# Execute the scriptblock to get the list of element hashtables<\/p>\n

$elements = & $sb <\/p>\n

# Now iterate over the list construction elements then adding<\/p>\n

# the specified attributes. <\/p>\n

foreach ($e in $elements)<\/p>\n

{<\/p>\n

$elem = $doc.CreateElement($e.element)<\/p>\n

foreach ($attr in $e.Attributes.GetEnumerator())<\/p>\n

{<\/p>\n

$elem.SetAttribute($attr.name, $attr.value)<\/p>\n

}<\/p>\n

# The next step would be to recursively construct the<\/p>\n

# children of this node but that’s not implemented yet… <\/p>\n

# Finally add this element<\/p>\n

[void] $doc.get_ChildNodes().Item(1).AppendChild($elem)<\/p>\n

}<\/p>\n

#<\/p>\n

# Return the constructed document…<\/p>\n

# $doc<\/p>\n

While this script is not a complete solution (it doesn\u2019t support building child nodes) it does illustrate how, in a few lines of code, you can build a custom \u201clanguage\u201d that lets you express the intent of your solution clearly and concisely. You can also take advantage of PowerShell\u2019s use of dynamic scopes to specify \u201cresources\u201d in the document description by simply defining a variable at one level and then using it in a nested scope. You can create \u201cbase\u201d attribute descriptions as hashtables stored in these resource variables and then derive complete descriptions by using PowerShell\u2019s ability to add two hashtables together. Finally, instead of directly encoding all of the literal hashtables, you can could a function in the body of the document that returns a collection of hashtables simplifying the construction of repeated nodes.\nThere is one other very useful extension that could be added to this script and that\u2019s schema validation. As each element is constructed, it would be easy to check a hashtable to see if the element is permitted in the document. Once you have the element, additional hashtables can be used to verify that the attributes are correct and are of the correct type, etc. As you might imagine, the schema notation once again lends itself to a \u201clittle language\u201d solution, however it is left as an exercise to the reader J\n-bruce\n===================================================================\nBruce Payette [MSFT] <\/p>\n

Windows PowerShell Tech Lead <\/p>\n

Visit the Windows PowerShell Team blog at: http:\/\/blogs.msdn.com\/PowerShell<\/p>\n

Visit the Windows PowerShell ScriptCenter at: http:\/\/www.microsoft.com\/technet\/scriptcenter\/hubs\/msh.mspx<\/p>\n

Windows PowerShell in Action (book): http:\/\/manning.com\/powershell<\/p>\n

XmlBuilder.zip<\/p>\n","protected":false},"excerpt":{"rendered":"

A while back, Jeffrey posted an article on how to use string expansion and XML casts to build XML documents in-line in a PowerShell script: http:\/\/blogs.msdn.com\/powershell\/archive\/2007\/05\/29\/using-powershell-to-generate-xml-documents.aspx The overall feel of the approach that Jeffrey described is very much like that of ASP, JSP, PHP on any of the other systems that use \u201choles\u201d to embed […]<\/p>\n","protected":false},"author":685,"featured_media":13641,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[33,11,22],"class_list":["post-17666","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-powershell","tag-language","tag-philosophy","tag-typexml"],"acf":[],"blog_post_summary":"

A while back, Jeffrey posted an article on how to use string expansion and XML casts to build XML documents in-line in a PowerShell script: http:\/\/blogs.msdn.com\/powershell\/archive\/2007\/05\/29\/using-powershell-to-generate-xml-documents.aspx The overall feel of the approach that Jeffrey described is very much like that of ASP, JSP, PHP on any of the other systems that use \u201choles\u201d to embed […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/17666","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/users\/685"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/comments?post=17666"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/17666\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media\/13641"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media?parent=17666"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/categories?post=17666"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/tags?post=17666"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}