Eric White's Blog : OpenXML

Working with Numbering in Open XML WordprocessingML

EricWhite — Tue, 15 Dec 2009 22:44:00 GMT

[Blog Map]

Update Dec 15, 2009: This is the 8th in a series of posts on implementing a transform of WordprocessingML to XHtml.

1) Transforming Open XML Word-Processing Documents to XHtml

2) Transforming Open XML Word-Processing Documents to XHtml (Post #2)

3) Transforming Open XML Word-Processing Documents to Html (Post #3)

4) Open XML WordprocessingML Style Inheritance

5) Comparison of Html/CSS Tables to WordprocessingML Tables

6) Assembling Paragraph and Run Properties for Cells in an Open XML WordprocessingML Table

7) Implementing 'Inheritance' in XML

8) Working with Numbering in Open XML WordprocessingML

When implementing a conversion of Open XML word processing documents to HTML, one of the interesting issues is accurately converting numbered and bulleted lists. You must pay special attention to them, because they impact the text that the document contains, but that text isn't directly in the markup. If you are accurately extracting the text of the document, you must process some elements and attributes to assemble the correct text.

Numbered items and bulleted lists are not trivial, and justifiably so. There are a large number of features of numbered and bulleted lists, each used by a different set of users. These features are represented by elements in the markup. However, you don't need to pay attention to all elements. Some aspects of the markup are there just to affect the user interface, and you don't need to pay attention to those elements when determining the textual representation of a numbered or bulleted item. This post presents just the essentials that you need to know to work with numbered and bulleted items.

Note: This blog post is an MSDN article that I've written. It will be published on MSDN sometime in the near future. Thanks to Tristan Davis, Zeyad Rajabi, and Brian Hyams for tech reviewing this post.

The easiest way to talk about numbering markup is to relate the markup to the user interface of Word. You are concerned only with the document modifications that we can make with these three buttons:

There is a fair amount of indirection for WordprocessingML numbering markup. There are three patterns for this indirection in the markup:

Direct numbering for simple numbered or bulleted lists
Style based numbering, i.e. Heading1 is at the first level of indentation, Heading2 is at the second level of indentation, etc.
Named numbering styles

I'll examine each of these patterns in depth.

Markup for a Simple Numbered List

First, I'll show the markup that is generated if you create a simple numbered list:

So that I can discuss the markup accurately, I need to make an important distinction between two aspects of numbered or bulleted lists. For each numbered or bulleted item, there are two components – the list item, and the paragraph text:

We need to make this distinction because the list item is what we need to assemble for each paragraph. In addition, there is separate formatting markup for the list item. The same distinction applies to a numbered list:

The following diagram shows the indirection for a simple numbered or bulleted list:

I'll examine the markup for the following simple numbered list:

The markup in the main document part looks like this:

<w:p>

<w:pPr>

<w:pStyle w:val="ListParagraph"/>

<w:numPr>

<w:ilvl w:val="0"/>

<w:numId w:val="1"/>

</w:numPr>

</w:pPr>

<w:r>

<w:t>Paragraph one.</w:t>

</w:r>

</w:p>

The w:numPr element contains the numbering elements that we're concerned with. The w:ilvl element is a zero based number that indicates the indentation level. The numbered items are at the least indented level, so the value of w:ilvl is zero. The w:numId element is an index into the w:num elements, which is located in the numbering part.

Note: The w:numId can contain a value of 0, which is a special value that indicates that numbering has been removed at this level of the style hierarchy. While processing this markup, if the w:val='0', the paragraph doesn't have a list item.

The numbering part markup looks like this:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<w:numbering xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main">

<w:abstractNum w:abstractNumId="0">

<w:nsid w:val="5FE17486"/>

<w:multiLevelType w:val="hybridMultilevel"/>

<w:tmpl w:val="1084E0BA"/>

<w:lvl w:ilvl="0"

w:tplc="0409000F">

<w:start w:val="1"/>

<w:numFmt w:val="decimal"/>

<w:lvlText w:val="%1."/>

<w:lvlJc w:val="left"/>

<w:pPr>

<w:ind w:left="720"

w:hanging="360"/>

</w:pPr>

</w:lvl>

<w:lvl w:ilvl="1"

w:tplc="04090019"

w:tentative="1">

<w:start w:val="1"/>

<w:numFmt w:val="lowerLetter"/>

<w:lvlText w:val="%2."/>

<w:lvlJc w:val="left"/>

<w:pPr>

<w:ind w:left="1440"

w:hanging="360"/>

</w:pPr>

</w:lvl>

</w:abstractNum>

<w:num w:numId="1">

<w:abstractNumId w:val="0"/>

</w:num>

</w:numbering>

The index in the w:numPr element in the main document part refers to the w:num element highlighted in yellow above. In this case, that element contains a single element, w:abstractNumId, which refers to the w:abstractNum element above it. The w:abstractNum element contains the information necessary to format the list item. Note that the w:abstractNum element does not contain formatting information for the paragraph (except for indentation information, with pertains to both the list item and the paragraph). Formatting for the paragraph itself is stored in the main document and styles part, as usual. There are three elements (w:nsid, w:multiLevelType, and w:tmpl) that only impact the user interface in the word processing application, and you can disregard them. From now on in this post, I will eliminate those elements from markup listings. The w:lvl elements and the w:lvl child elements define the formatting for each indentation level of the list items. There are additional w:lvl elements (removed from the listing) that define the formatting for list items for each level at level two and above. The w:tplc and w:tentative attributes of the w:lvl element are there for the user interface only. I'll remove them from further listings.

Note: the indirection from w:num to w:abstractNum allows for markup that overrides formatting of list items. I'll show this markup later.

The elements that you are really interested in are children of the w:lvl element – the w:start, w:numFmt, w:lvlText, and w:lvlJc elements, and the complex element w:pPr.

The w:start element specifies the starting number for the indentation level. Do you start counting at 0, 1, or some other number? Negative start numbers are not allowed (and are not very useful).

In this example, the w:numFmt element indicates that the document uses a decimal in the list item for indentation level 0, and that the document uses a lower case letter for indentation level 1. There are a fair number of options for this element:

Bullets
Decimal (1, 2, 3)
Decimal Zero (01, 02, 03)
Upper Roman (I, II, III)
Lower Roman (i, ii, iii)
Upper Letter (A, B, C)
Lower Letter (a, b, c)
Ordinal (1st, 2nd, 3rd)
Cardinal Text (One, Two Three)
Ordinal Text (First, Second, Third)

Note: There are other options for other languages that I've not included. Various Asian languages have numbering systems that are not included in this list. In the near future, I'll be posting code to assemble the list item text, and in that code, I am supporting only the above list. I've designed that code so that it is easily extended to include other numbering systems.

You use the w:lvlText element as a template to construct the list item. For level 0, this example uses "%1.", which indicates that whatever w:numFmt text was determined for the least indented item above replaces the %1 in the format string. For level 1, this example uses "%2.", which indicates that whatever text was determined for the first indentation replaces the %2. Note that for the w:lvl elements, you specify indentation level with a zero based index, whereas in the w:lvlText template, you specify replacement tokens using a one based index. This makes sense – the w:lvl elements are used only by developers, and zero based indexes are easier, whereas the template is used and specified by users, so a one based index makes sense. These two elements are pretty powerful, and allow you to put together hierarchical list formats to satisfy just about any need. I will show more examples of these two elements further on.

Note: For bulleted lists, even if the w:lvltext element contains replacement tokens (%1, %2, etc.), the replacement tokens are not replaced with the level number. This does not impact our code, because the w:lvlText element will not contain replacement tokens.

The w:lvlJc element controls whether the list items are right or left justified, as well as some other options. The following shows the difference between left and right justification for numbered items that use text. It is easy to see in this example, but is more difficult to notice when using bulleted lists or numbered lists that use digits.

Finally, there are paragraph properties that apply to the list item, most importantly here specifying the indentation and hanging indentation.

The w:lvl element can also contain run properties that apply to the list item. If you change the font of the list item to Courier, it would look like this:

Her is an example of the w:lvl element that contains run properties that define the font for the list item:

<w:lvl w:ilvl="0">

<w:start w:val="1"/>

<w:numFmt w:val="ordinalText"/>

<w:lvlText w:val="%1)"/>

<w:lvlJc w:val="left"/>

<w:pPr>

<w:ind w:left="720"

w:hanging="360"/>

</w:pPr>

<w:rPr>

<w:rFonts w:ascii="Courier New"

w:hAnsi="Courier New"

w:hint="default"/>

</w:rPr>

</w:lvl>

As usual, the paragraph in the main document part also contains a reference to a style:

<w:p>

<w:pPr>

<w:pStyle w:val="ListParagraph"/>

<w:numPr>

<w:ilvl w:val="0"/>

<w:numId w:val="1"/>

</w:numPr>

</w:pPr>

<w:r>

<w:t>One</w:t>

</w:r>

</w:p>

We can find that style in the styles part, which specifies the formatting for the paragraph text:

<w:style w:type="paragraph"

w:styleId="ListParagraph">

<w:name w:val="List Paragraph"/>

<w:basedOn w:val="Normal"/>

<w:pPr>

<w:ind w:left="720"/>

<w:contextualSpacing/>

</w:pPr>

</w:style>

This is the normal pattern for markup for styled paragraphs.

Markup for a Simple Bulleted List

Next, I'll show the markup that is generated if you create a simple bulleted list:

The markup indirection pattern for a simple bulleted list is the same as the pattern for a simple numbering list.

For the simple bulleted list, the main document part (document.xml) contains paragraphs that are identical to the simple numbered list:

<w:p>

<w:pPr>

<w:pStyle w:val="ListParagraph"/>

<w:numPr>

<w:ilvl w:val="0"/>

<w:numId w:val="1"/>

</w:numPr>

</w:pPr>

<w:r>

<w:t>One</w:t>

</w:r>

</w:p>

Here's what the numbering part looks like:

<w:abstractNum w:abstractNumId="0">

<w:lvl w:ilvl="0">

<w:start w:val="1"/>

<w:numFmt w:val="bullet"/>

<w:lvlText w:val=""/>

<w:lvlJc w:val="left"/>

<w:pPr>

<w:ind w:left="720"

w:hanging="360"/>

</w:pPr>

<w:rPr>

<w:rFonts w:ascii="Symbol"

w:hAnsi="Symbol"

w:hint="default"/>

</w:rPr>

</w:lvl>

<w:num w:numId="1">

<w:abstractNumId w:val="0"/>

</w:num>

</w:numbering>

The w:val attribute of the w:lvlText element here is saved as the character 0xB7, which is the bullet symbol for this level (from the Symbol font). The Visual Studio XML editor shows this character as a box in the courier font. The main point about this example is that you can write a generalized method to assemble text for the list item, and this method will work for both numbered and bulleted lists.

The w:start element doesn't have an effect on the list item because the w:lvlText template element doesn't contain a replacement token (%1, %2, etc.) But even if it did, we would not replace the token.

Markup for a Multi-Level List

You can see that this framework nicely allows for multi-level lists. You can change the source document to look like this:

The paragraphs in the main document part looks like this. The w:ilvl element for the second paragraph is set to "1".

<w:p>

<w:pPr>

<w:pStyle w:val="ListParagraph"/>

<w:numPr>

<w:ilvl w:val="0"/>

<w:numId w:val="1"/>

</w:numPr>

</w:pPr>

<w:r>

<w:t>One</w:t>

</w:r>

</w:p>

<w:p>

<w:pPr>

<w:pStyle w:val="ListParagraph"/>

<w:numPr>

<w:ilvl w:val="1"/>

<w:numId w:val="1"/>

</w:numPr>

</w:pPr>

<w:r>

<w:t>Two</w:t>

</w:r>

</w:p>

The numbering and style parts are not modified in this example.

Markup for Numbering that is Linked to Styles

There is a feature of numbering that makes it very convenient for users but makes the markup a little more involved. You can link a style to a numbering type and level, and then all paragraphs of that style are then represented with a list item. The canonical example is linking Heading1 style to the first level of indentation, Heading2 style to the second level, and so on. A document using this approach looks like this:

The markup indirection pattern for numbering that is linked to styles looks like this:

In this case, the main document part doesn't contain any markup related to numbering:

<w:p>

<w:pPr>

<w:pStyle w:val="Heading1"/>

</w:pPr>

<w:r>

<w:t>Overview of Numbering</w:t>

</w:r>

</w:p>

<w:p>

<w:pPr>

<w:pStyle w:val="Heading2"/>

</w:pPr>

<w:r>

<w:t>Markup of a Simple Numbered List</w:t>

</w:r>

</w:p>

The markup in the style part for the Heading1 style contains a reference to the w:num element in the numbering part:

<w:style w:type="paragraph"

w:styleId="Heading1">

<w:name w:val="heading 1"/>

<w:basedOn w:val="Normal"/>

<w:pPr>

<w:numPr>

<w:numId w:val="1"/>

</w:numPr>

<w:spacing w:before="480"

w:after="0"/>

<w:outlineLvl w:val="0"/>

</w:pPr>

<w:rPr>

<w:rFonts w:asciiTheme="majorHAnsi"

w:eastAsiaTheme="majorEastAsia"

w:hAnsiTheme="majorHAnsi"

w:cstheme="majorBidi"/>

<w:b/>

<w:bCs/>

<w:color w:val="365F91"

w:themeColor="accent1"

w:themeShade="BF"/>

<w:sz w:val="28"/>

<w:szCs w:val="28"/>

</w:rPr>

</w:style>

The numbering part looks like this:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<w:numbering xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main">

<w:abstractNum w:abstractNumId="0">

<w:lvl w:ilvl="0">

<w:start w:val="1"/>

<w:numFmt w:val="decimal"/>

<w:pStyle w:val="Heading1"/>

<w:lvlText w:val="%1"/>

<w:lvlJc w:val="left"/>

<w:pPr>

<w:ind w:left="432"

w:hanging="432"/>

</w:pPr>

</w:lvl>

<w:lvl w:ilvl="1">

<w:start w:val="1"/>

<w:numFmt w:val="decimal"/>

<w:pStyle w:val="Heading2"/>

<w:lvlText w:val="%1.%2"/>

<w:lvlJc w:val="left"/>

<w:pPr>

<w:ind w:left="576"

w:hanging="576"/>

</w:pPr>

</w:lvl>

</w:abstractNum>

<w:num w:numId="1">

<w:abstractNumId w:val="0"/>

</w:num>

</w:numbering>

The w:pStyle element links back to the style in the style part. You determine the indentation level by finding the w:pStyle element that matches the style of the paragraph and looking at the parent w:lvl complex element. As usual, you assemble the text of the list item from the other child elements of the w:lvl element.

Overriding a Number Format in a Multi-Level List with a New Number Format

You can override the numbering format for any level in a multi-level list with a new number format, and this impacts the markup. To create this markup, first create a multi-level list:

Then select a paragraph, and define a new number format:

In the Define new Number Format dialog box, change some aspect. In this example, I changed Heading2 so that the list item is the cardinal number followed by a parenthesis: "One)".

The markup for the main document part now looks like this:

<w:p>

<w:pPr>

<w:pStyle w:val="Heading1"/>

</w:pPr>

<w:r>

<w:t>Paragraph One</w:t>

</w:r>

</w:p>

<w:p>

<w:pPr>

<w:pStyle w:val="Heading2"/>

<w:numPr>

<w:ilvl w:val="1"/>

<w:numId w:val="2"/>

</w:numPr>

</w:pPr>

<w:r>

<w:t>Paragraph Two</w:t>

</w:r>

</w:p>

<w:p>

<w:pPr>

<w:pStyle w:val="Heading3"/>

</w:pPr>

<w:r>

<w:t>Paragraph Three</w:t>

</w:r>

</w:p>

The markup in the numbering part now has two w:num elements, each pointing to their own abstract numbering format:

<w:num w:numId="1">

<w:abstractNumId w:val="1"/>

</w:num>

<w:num w:numId="2">

<w:abstractNumId w:val="0"/>

</w:num>

The abstract numbering markup can be then processed as usual. The main point here is when you format numbering using styles, the markup follows the indirection detailed in this section, but if a paragraph of that style contains a w:numPr element, this overrides the link from the abstract numbering format to the style.

Overriding a Number Format in a Multi-Level List, creating a new Multi-Level List Format

The user can override the numbering format for any level in a multi-level list, creating a new multi-level list format, and this impacts the markup. To create this markup, first create a multi-level list:

Then select a paragraph, and define a new multi-level list:

In the Define new Multilevel list dialog box, change some aspect of the list level. In my example, I changed the format so that list items at the second level of indentation use upper case alpha for the item marker.

The markup for the main document part contains a w:numPr element that overrides the link from the abstract numbering format to the style, in the same way as when creating a new number format:

<w:p>

<w:pPr>

<w:pStyle w:val="Heading1"/>

</w:pPr>

<w:r>

<w:t>Paragraph One</w:t>

</w:r>

</w:p>

<w:p>

<w:pPr>

<w:pStyle w:val="Heading2"/>

<w:numPr>

<w:ilvl w:val="1"/>

<w:numId w:val="3"/>

</w:numPr>

</w:pPr>

<w:r>

<w:t>Paragraph Two</w:t>

</w:r>

</w:p>

<w:p>

<w:pPr>

<w:pStyle w:val="Heading3"/>

</w:pPr>

<w:r>

<w:t>Paragraph Three</w:t>

</w:r>

</w:p>

The w:numPr element in the paragraph properties overrides the link between the abstract numbering format and the Heading2 style. The numbering part now contains a new w:num element that defines w:lvlOverride elements:

<w:num w:numId="1">

<w:abstractNumId w:val="0"/>

</w:num>

<w:num w:numId="2">

<w:abstractNumId w:val="1"/>

</w:num>

<w:num w:numId="3">

<w:abstractNumId w:val="0"/>

<w:lvlOverride w:ilvl="0">

<w:lvl w:ilvl="0">

<w:start w:val="1"/>

<w:numFmt w:val="decimal"/>

<w:pStyle w:val="Heading1"/>

<w:lvlText w:val="%1"/>

<w:lvlJc w:val="left"/>

<w:pPr>

<w:ind w:left="432"

w:hanging="432"/>

</w:pPr>

<w:rPr>

<w:rFonts w:hint="default"/>

</w:rPr>

</w:lvl>

</w:lvlOverride>

<w:lvlOverride w:ilvl="1">

<w:lvl w:ilvl="1">

<w:start w:val="1"/>

<w:numFmt w:val="upperLetter"/>

<w:pStyle w:val="Heading2"/>

<w:lvlText w:val="%1.%2"/>

<w:lvlJc w:val="left"/>

<w:pPr>

<w:ind w:left="576"

w:hanging="576"/>

</w:pPr>

<w:rPr>

<w:rFonts w:hint="default"/>

</w:rPr>

</w:lvl>

</w:lvlOverride>

. . .

Two of the w:num elements now refer to the same abstract numbering format, but the second one now overrides the list item formatting. You can see that the level override for level 1 now specifies that the value for the w:numFmt element is "upperLetter".

The w:startOverride Element

The w:lvlOverride element can contain a child w:startOverride element:

<w:num w:numId="2">

<w:abstractNumId w:val="2"/>

<w:lvlOverride w:ilvl="0">

<w:startOverride w:val="5"/>

</w:lvlOverride>

<w:lvlOverride w:ilvl="1">

<w:startOverride w:val="1"/>

</w:lvlOverride>

. . .

</w:num>

The w:startOverride element causes the starting number of the indent level to be the value specified. This is sometimes used when the user specifically sets this value in the user interface to force counting to start from a specific number. This is one way that markup forms a document that skips an number in a numbered list:

There is another way that markup can specify a starting number. I'll show this markup this shortly.

Defining a new List Style

One option in Word is that you can define a new named list style, and then use that style elsewhere in the document. This is a quick and easy way to implement your own customized numbering format. To do this, select the text to number, and pick "Define New List Style" from the Multi-level List drop down:

This brings up the Define New List Style dialog box.

After filling out this dialog, the selected paragraphs will have the numbering format that you specify. You can then further apply this same style in other locations in the document. Using this feature impacts the markup.

Here is the indirection when using this pattern:

The document part looks the same as when applying other forms of numbering:

<w:p>

<w:pPr>

<w:pStyle w:val="ListParagraph"/>

<w:numPr>

<w:ilvl w:val="0"/>

<w:numId w:val="2"/>

</w:numPr>

</w:pPr>

<w:r>

<w:t>1</w:t>

</w:r>

</w:p>

We can find the referenced w:num element in the numbering part:

<w:num w:numId="2">

<w:abstractNumId w:val="0"/>

</w:num>

But if we look at the abstract numbering element, it looks quite different. It doesn't contain child w:lvl elements, and uses the w:numStyleLink element to refer to the style that I defined in the dialog box.

<w:abstractNum w:abstractNumId="0">

<w:nsid w:val="03916EF0"/>

<w:multiLevelType w:val="multilevel"/>

<w:tmpl w:val="0409001D"/>

<w:numStyleLink w:val="EricsListStyle"/>

</w:abstractNum>

In the styles part, you can find the newly defined style, which then refers back to a w:num element in the numbering part:

<w:style w:type="numbering"

w:customStyle="1"

w:styleId="EricsListStyle">

<w:name w:val="EricsListStyle"/>

<w:uiPriority w:val="99"/>

<w:rsid w:val="00B1427D"/>

<w:pPr>

<w:numPr>

<w:numId w:val="1"/>

</w:numPr>

</w:pPr>

</w:style>

The w:num element in the numbering part looks like this:

<w:num w:numId="1">

<w:abstractNumId w:val="1"/>

</w:num>

This refers to a w:abstractNum element, which contains the level formats, as usual:

<w:abstractNum w:abstractNumId="1">

<w:nsid w:val="2D235466"/>

<w:multiLevelType w:val="multilevel"/>

<w:tmpl w:val="0409001D"/>

<w:styleLink w:val="EricsListStyle"/>

<w:lvl w:ilvl="0">

<w:start w:val="1"/>

<w:numFmt w:val="decimal"/>

<w:lvlText w:val="%1)"/>

<w:lvlJc w:val="left"/>

<w:pPr>

<w:ind w:left="360"

w:hanging="360"/>

</w:pPr>

</w:lvl>

<w:lvl w:ilvl="1">

<w:start w:val="1"/>

<w:numFmt w:val="lowerLetter"/>

<w:lvlText w:val="%2)"/>

<w:lvlJc w:val="left"/>

<w:pPr>

<w:ind w:left="720"

w:hanging="360"/>

</w:pPr>

</w:lvl>

. . .

This is a fair amount of indirection, but using LINQ to XML, it results in only a few statements to follow this indirection.

Alternatives for the List Item Suffix

The list suffix is the white space content between the list item and the paragraph. There are only two possible values – tab and space. We can alter a list definition to use a space for the list item suffix instead of a tab:

The markup uses the w:suff element to specify this:

<w:abstractNum w:abstractNumId="0">

<w:nsid w:val="21E167DA"/>

<w:multiLevelType w:val="multilevel"/>

<w:tmpl w:val="5BE82C98"/>

<w:lvl w:ilvl="0">

<w:start w:val="1"/>

<w:numFmt w:val="decimal"/>

<w:pStyle w:val="Heading1"/>

<w:suff w:val="space"/>

<w:lvlText w:val="%1"/>

<w:lvlJc w:val="left"/>

<w:pPr>

<w:ind w:left="432"

w:hanging="432"/>

</w:pPr>

<w:rPr>

<w:rFonts w:hint="default"/>

</w:rPr>

</w:lvl>

The w:lvlRestart Element

The w:lvlRestart element allows the markup to control when a particular level restarts counting. In the following example, the level four list item starts recounting when there is an intervening level one item:

The markup (for the above example) for the w:lvl element where the w:ilvl attribute is equal to "3" looks like this:

<w:abstractNum w:abstractNumId="0">

<w:nsid w:val="065A6A4E"/>

<w:multiLevelType w:val="multilevel"/>

<w:tmpl w:val="06A2CF44"/>

<w:lvl w:ilvl="3">

<w:start w:val="1"/>

<w:numFmt w:val="decimal"/>

<w:lvlRestart w:val="1"/>

<w:lvlText w:val="%1.%2.%3.%4."/>

<w:lvlJc w:val="left"/>

<w:pPr>

<w:ind w:left="1728"

w:hanging="648"/>

</w:pPr>

<w:rPr>

<w:rFonts w:hint="default"/>

</w:rPr>

</w:lvl>

The w:isLgl Element

The w:isLgl element changes the textual representation of a list item so that it uses digits for all levels instead of the specified number format for that level, but only when formatting text for a given indentation level. Consider the following document, where items at the third indentation level use legal numbering:

If this list didn't use legal numbering for the third level of indentation, it would look like this:

The markup for w:isLgl looks like this:

<w:abstractNum w:abstractNumId="0">

. . .

<w:lvl w:ilvl="2">

<w:start w:val="1"/>

<w:numFmt w:val="decimal"/>

<w:pStyle w:val="Heading3"/>

<w:isLgl/>

<w:lvlText w:val="%1.%2.%3)"/>

<w:lvlJc w:val="left"/>

<w:pPr>

<w:ind w:left="720"

w:hanging="720"/>

</w:pPr>

<w:rPr>

<w:rFonts w:hint="default"/>

</w:rPr>

</w:lvl>

Algorithm to Assemble List Item Text

The key aspects for assembling list item text is to determine:

The w:lvl formatting for the paragraph
The indentation level of the paragraph
The number for each parent level of indentation for the paragraph. For example, if a paragraph is at the 4th indentation level, you need to determine the level numbers of the 1st, 2nd, 3rd, and 4th levels associated with that paragraph.

Once you have these three items, it is a simple text formatting exercise to assemble the list item text.

A paragraph may contain numbering properties that contain a w:ilvl and w:numId element.

<w:p>

<w:pPr>

<w:pStyle w:val="ListParagraph"/>

<w:numPr>

<w:ilvl w:val="0"/>

<w:numId w:val="1"/>

</w:numPr>

</w:pPr>

<w:r>

<w:t>Paragraph one.</w:t>

</w:r>

</w:p>

In this case, you use the w:ilvl specified for the indentation level. You go to the numbering part, and look up the w:num element. If there is a w:lvlOverride element that contains a w:lvl element, then that w:lvl element applies. If there is no w:lvlOverride element, or if the w:lvlOverride element doesn’t contain a w:lvl element for the indentation level, then find the associated w:abstractNum element, and use the w:lvl formatting specified in the w:abstractNum. If the w:num element contains a w:lvlOverride element, you use the w:lvl specified for the indentation level in the override.

If the paragraph does not contain a w:numPr complex element, then if the style of the paragraph contains a w:numPr element, there is an abstract numbering element that refers to the style. We use the w:lvl that refers to the style. This also gives us the indentation level.

Once we've determined the w:lvl formatting element, and the indentation level, we can determine the list number for each level. You need to count the paragraphs at the same level before the current paragraph, paying attention to the w:lvlRestart element and the w:start element. This is where functional programming will shine – I can build a stateless expression to calculate the item number for each indentation level. This may not be the most efficient way to do this – it may use more CPU processing than another approach, but it will be easy to debug, and probably fast enough for most scenarios. In my informal testing on my slowest machine, it is still basically instantaneous.

Once you have the appropriate w:lvl element and the list of item numbers for each level of indentation, it is a simple text assembly process to put together the list item text.

This may seem like a lot of logic to assemble the list item text, but it is less than 400 lines of code when properly factored and implemented using LINQ to XML.

Implementing 'Inheritance' in XML

EricWhite — Sun, 13 Dec 2009 12:41:00 GMT

[Blog Map]

Update Dec 15, 2009: This is the 7th in a series of posts on implementing a transform of WordprocessingML to XHtml.

1) Transforming Open XML Word-Processing Documents to XHtml

2) Transforming Open XML Word-Processing Documents to XHtml (Post #2)

3) Transforming Open XML Word-Processing Documents to Html (Post #3)

4) Open XML WordprocessingML Style Inheritance

5) Comparison of Html/CSS Tables to WordprocessingML Tables

6) Assembling Paragraph and Run Properties for Cells in an Open XML WordprocessingML Table

7) Implementing 'Inheritance' in XML

8) Working with Numbering in Open XML WordprocessingML

Some XML vocabularies implement a powerful XML pattern that is analogous to inheritance in programming language type systems. Open XML WordprocessingML has these semantics around styles. When you define a new style, you can base this style on another style, and if the new style doesn't explicitly define some aspect of the style, the new style 'inherits' this aspect from its base style. This post presents some code that uses one approach for implementing inheritance semantics.

Consider the following XML:

<Root>

<Font>

</Font>

</Positioning>

</Style>

<Font>

</Font>

</Positioning>

</Style>

<Style StyleId="Heading1"

BaseStyleId="CompanyThemeHeading1">

</Positioning>

</Style>

</Root>

The Heading1 style is based on the CompanyThemeHeading1 style, which is itself based on RootStyle. The programming task is to 'roll up' these styles, and assemble a new Style element that contains all inherited child elements as appropriate. Note that the order of the Style elements in the XML document is not significant. The method to 'roll up' these styles should work properly regardless of the document order of the Style elements.

In the case of Open XML styles, there are three varieties of inheritance semantics:

Replace an element with the same element and attributes in the derived style.
Merge child elements with the corresponding element in the derived style. In the case of WordprocessingML, when an element has these semantics, it will not have any attributes, so we can disregard them.
Merge attributes with the attributes of the same element in the derived style. In the case of WordprocessingML, when an element has these semantics, it will not have any child nodes, so we can disregard them.

We should note that this doesn't cover all possibilities of inheritance semantics. Other possibilities:

Merge attributes and replace child elements
Merge attributes and merge child elements
Replace attributes and merge child elements

For a detailed examination of the Open XML inheritance semantics, see Open XML WordprocessingML Style Inheritance.

When implementing this in code, the first task is to write an iterator that will return a collection of styles. We pass the StyleId of the most derived style, and this method will follow the style chain, yielding up each style in order.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Xml.Linq;

class Program

{

static IEnumerable<XElement> StyleChainReverseOrder(XElement styles, string styleId)

{

string current = styleId;

while (true)

{

XElement style = styles.Elements("Style")

.Where(s => (string)s.Attribute("StyleId") == current).FirstOrDefault();

yield return style;

current = (string)style.Attribute("BaseStyleId");

if (current == null)

yield break;

}

static void Main(string[] args)

{

XElement styles = XElement.Load("Styles.xml");

foreach (var style in StyleChainReverseOrder(styles, "Heading1"))

{

Console.WriteLine(style);

Console.WriteLine();

}

If you are not familiar with writing iterators, see The Yield Contextual Keyword.

When you run this example, you see:

<Style StyleId="Heading1"

BaseStyleId="CompanyThemeHeading1">

</Positioning>

</Style>

<Style StyleId="CompanyThemeHeading1"

BaseStyleId="RootStyle">

<Font>

</Font>

<VisualProps ForeColor="Blue"

BackColor="OffWhite" />

</Positioning>

</Style>

<Font>

</Font>

</Positioning>

</Style>

We've retrieved the collection of relevant styles (Heading1, CompanyThemeHeading1, and RootStyle), but they are in the reverse order to the order that we want to process them. That is easy enough to fix – we write a method that returns the collection in reverse:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Xml.Linq;

class Program

{

static IEnumerable<XElement> StyleChainReverseOrder(XElement styles, string styleId)

{

string current = styleId;

while (true)

{

XElement style = styles.Elements("Style")

.Where(s => (string)s.Attribute("StyleId") == current).FirstOrDefault();

yield return style;

current = (string)style.Attribute("BaseStyleId");

if (current == null)

yield break;

}

static IEnumerable<XElement> StyleChain(XElement styles, string styleId)

{

return StyleChainReverseOrder(styles, styleId).Reverse();

}

static void Main(string[] args)

{

XElement styles = XElement.Load("Styles.xml");

foreach (var style in StyleChain(styles, "Heading1"))

{

Console.WriteLine(style);

Console.WriteLine();

}

Now we can write a method to merge two styles. The Style element has 'merge child semantics', so we'll write a method to do that:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Xml.Linq;

class Program

{

static IEnumerable<XElement> StyleChainReverseOrder(XElement styles, string styleId)

{

string current = styleId;

while (true)

{

XElement style = styles.Elements("Style")

.Where(s => (string)s.Attribute("StyleId") == current).FirstOrDefault();

yield return style;

current = (string)style.Attribute("BaseStyleId");

if (current == null)

yield break;

}

static IEnumerable<XElement> StyleChain(XElement styles, string styleId)

{

return StyleChainReverseOrder(styles, styleId).Reverse();

}

static XElement MergeChildElements(XElement mergedElement, XElement element)

{

// If, when in the process of merging, the source element doesn't have a

// corresponding element in the merged element, then include the source element

// in the merged element.

if (mergedElement == null)

return element;

XElement newMergedElement = new XElement(element.Name,

element.Attributes(),

element.Elements().Select(e =>

{

// Replace

if (e.Name == "Font"

// || e.Name = "OtherElementWithReplaceSemantics"

)

return e;

// Merge attributes

if (e.Name == "VisualProps")

return new XElement(e.Name,

e.Attributes(),

mergedElement.Elements(e.Name).Attributes()

.Where(a => !(e.Attributes().Any(z => z.Name == a.Name))));

// All other elements have merge child elements

XElement correspondingElement = mergedElement.Element(e.Name);

if (correspondingElement == null)

return e;

return new XElement(e.Name,

e.Attributes(),

e.Elements().Select(c =>

MergeChildElements(correspondingElement.Element(c.Name), c)),

correspondingElement.Elements().Where(m => e.Element(m.Name) == null)

);

}),

mergedElement.Elements()

.Where(m => !element.Elements(m.Name).Any()));

return newMergedElement;

}

static void Main(string[] args)

{

XElement styles = XElement.Load("Styles.xml");

var styleChain = StyleChain(styles, "Heading1").ToArray();

XElement s1 = MergeChildElements(

styleChain[0],

styleChain[1]);

Console.WriteLine(s1);

}

This is a recursive method – when merging child elements, we need to implement appropriate semantics for each of the child elements. To test the method, we merge the first two styles in the style chain. When we run this on our sample XML document, we see:

<Style StyleId="CompanyThemeHeading1"

BaseStyleId="RootStyle">

<Font>

</Font>

<VisualProps ForeColor="Blue"

BackColor="OffWhite" />

</Positioning>

</Style>

This is what we expected. We see the Font element from the CompanyThemeHeading1 style. The attributes of the VisualProps element are merged. Positioning, which has 'merge child elements' semantics, contains correct SpaceAfter element, which replaced the SpaceAfter element in the RootStyle.

Now we can write a one statement method that uses the Aggregate extension method to roll up all styles:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Xml.Linq;

class Program

{

static IEnumerable<XElement> StyleChainReverseOrder(XElement styles, string styleId)

{

string current = styleId;

while (true)

{

XElement style = styles.Elements("Style")

.Where(s => (string)s.Attribute("StyleId") == current).FirstOrDefault();

yield return style;

current = (string)style.Attribute("BaseStyleId");

if (current == null)

yield break;

}

static IEnumerable<XElement> StyleChain(XElement styles, string styleId)

{

return StyleChainReverseOrder(styles, styleId).Reverse();

}

static XElement MergeChildElements(XElement mergedElement, XElement element)

{

// If, when in the process of merging, the source element doesn't have a

// corresponding element in the merged element, then include the source element

// in the merged element.

if (mergedElement == null)

return element;

XElement newMergedElement = new XElement(element.Name,

element.Attributes(),

element.Elements().Select(e =>

{

// Replace

if (e.Name == "Font"

// || e.Name = "OtherElementWithReplaceSemantics"

)

return e;

// Merge attributes

if (e.Name == "VisualProps")

return new XElement(e.Name,

e.Attributes(),

mergedElement.Elements(e.Name).Attributes()

.Where(a => !(e.Attributes().Any(z => z.Name == a.Name))));

// All other elements have merge child elements

XElement correspondingElement = mergedElement.Element(e.Name);

if (correspondingElement == null)

return e;

return new XElement(e.Name,

e.Attributes(),

e.Elements().Select(c =>

MergeChildElements(correspondingElement.Element(c.Name), c)),

correspondingElement.Elements().Where(m => e.Element(m.Name) == null)

);

}),

mergedElement.Elements()

.Where(m => !element.Elements(m.Name).Any()));

return newMergedElement;

}

static XElement AssembleDerivedStyle(XElement styles, string styleId)

{

return StyleChain(styles, styleId)

.Aggregate(

new XElement("Style"),

(mergedStyle, style) => MergeChildElements(mergedStyle, style));

}

static void Main(string[] args)

{

XElement styles = XElement.Load("Styles.xml");

Console.WriteLine(AssembleDerivedStyle(styles, "Heading1"));

}

When you run this on the sample data, you see:

<Style StyleId="Heading1"

BaseStyleId="CompanyThemeHeading1">

<VisualProps Bold="true"

ForeColor="Blue"

BackColor="OffWhite" />

</Positioning>

<Font>

</Font>

</Style>

This is what we expected. VisualProps has merged attributes, Font is inherited from CompanyThemeHeading1, and Positioning has the SpaceAfter element from the CompanyThemeHeading1 style, and the Indent element from the Heading1 style.

Using the SharePoint 2010 Client Object Model with Open XML

EricWhite — Tue, 01 Dec 2009 13:46:00 GMT

The SharePoint 2010 Managed Client Object Model is a set of .NET managed libraries that allow us to write code for client computers to work with many of the common objects in our SharePoint sites. Programs running on the client can add and remove lists, add, update, and delete list items, modify documents in document libraries, create sites, manage permissions of items, add and remove web parts from a page, and much more.

Open XML, the document format of Office 2007 and 2010, is an ISO/IEC standard (IS29500), which describes the internals of word-processing, spreadsheet, and presentation documents. Open XML files are stored per the Open Packaging Conventions specification (Part 2 of IS29500). They are essentially ZIP files that contain XML parts inside. The Open XML SDK is a .NET managed library that makes it easy to write programs to create, modify, or query Open XML documents. At the end of this article, I’ve listed a number of resources to help you get started using the Open XML SDK 2.0.Contents

Note: This blog post is an MSDN article that I've written. It will be published sometime in the near future. It provides you with what you need to start working with documents in document libraries using the client object model. Thanks to Michael Cheng for technically reviewing this post.

Overview

Retrieving a Document from a Document Library

Modifying a Document in a Document Library

Uploading a Document to a Document Library

Creating a New Document in Memory and Adding it to a Document Library

Processing all Documents in a Library

Creating an Open XML Word-Processing Document from a SharePoint Wiki

Conclusion

Additional Resources

Overview

Using these two technologies together enables some interesting scenarios:

You can write a client-side application that creates a word-processing document or presentation from data retrieved elsewhere, and automatically uploads this document to a document library in SharePoint.
You can write an application to query all documents in a document library, extracting information from each document.
You can write an application to process all documents in a document library, making the same modifications to each one. One interesting possibility is that you can remove all comments and personal information, and accept all tracked changes in each document in the library.
You can extract the contents of a SharePoint wiki, and construct an Open XML document from those contents.

This article builds on the information presented in Using the SharePoint 2010 Managed Client Object Model. Read that post if you are not familiar with how SharePoint client object model works.

Retrieving a Document from a Document Library

There are two basic operations when working with the client object model and Open XML — retrieving a document, and saving a document. Following is a small example that retrieves a document from a document library, and prints the text of the first paragraph.

This article uses Windows console applications for the sample code, but you can use the same approach with other application types.

To build the example, you need to add references to four assemblies. Two assemblies are necessary for accessing the SharePoint Managed Client Object Model: Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll. Two assemblies are necessary for using the Open XML SDK: DocumentFormat.OpenXml.dll and WindowsBase.dll. The post Using the SharePoint 2010 Managed Client Object Model contains detailed instructions on building a console application that uses the SharePoint 2010 client object model.

To build the examples presented in this post, you will also need to download and install the Open XML SDK. The Open XML SDK documentation contains instructions on building Open XML SDK applications. Download the Open XML SDK 2.0

using System;

using System.IO;

using System.Linq;

using DocumentFormat.OpenXml.Packaging;

using DocumentFormat.OpenXml.Wordprocessing;

using Microsoft.SharePoint.Client;

// The following using directive is used to resolve the ambiguity

// between the System.IO.File and Microsoft.SharePoint.Client.File

// classes.

using ClientOM = Microsoft.SharePoint.Client;

class Program

{

static private void CopyStream(Stream source, Stream destination)

{

byte[] buffer = new byte[32768];

int bytesRead;

{

bytesRead = source.Read(buffer, 0, buffer.Length);

destination.Write(buffer, 0, bytesRead);

} while (bytesRead != 0);

}

static void Main(string[] args)

{

ClientContext clientContext =

new ClientContext("http://intranet.contoso.com");

List sharedDocumentsList = clientContext.Web.Lists

.GetByTitle("Shared Documents");

CamlQuery camlQuery = new CamlQuery();

camlQuery.ViewXml =

@"<View>

<Query>

<Where>

<Eq>

</Eq>

</Where>

</Query>

</View>";

ListItemCollection listItems = sharedDocumentsList.GetItems(camlQuery);

clientContext.Load(sharedDocumentsList);

clientContext.Load(listItems);

clientContext.ExecuteQuery();

if (listItems.Count == 1)

{

ClientOM.ListItem item = listItems[0];

Console.WriteLine("FileLeafRef: {0}", item["FileLeafRef"]);

Console.WriteLine("FileDirRef: {0}", item["FileDirRef"]);

Console.WriteLine("FileRef: {0}", item["FileRef"]);

Console.WriteLine("File Type: {0}", item["File_x0020_Type"]);

FileInformation fileInformation =

ClientOM.File.OpenBinaryDirect(clientContext, (string)item["FileRef"]);

using (MemoryStream memoryStream = new MemoryStream())

{

CopyStream(fileInformation.Stream, memoryStream);

using (WordprocessingDocument doc =

WordprocessingDocument.Open(memoryStream, false))

{

var firstParagraph = doc

.MainDocumentPart

.Document

.Body

.Elements<Paragraph>()

.FirstOrDefault();

if (firstParagraph != null)

{

string text = firstParagraph.InnerText;

Console.WriteLine(text);

}

else

Console.WriteLine("Document doesn't contain any paragraphs.");

}

else

Console.WriteLine("Document not found.");

}

[Download Code]

This example produces output similar to the following:

FileLeafRef: Test.docx

FileDirRef: /Shared Documents

FileRef: /Shared Documents/Test.docx

File Type: docx

This is the text of the first paragraph.

This example prints the fields that we’ll often use when working with documents in a document library:

The FileLeafRef field contains the name of the file.

The FileDirRef field contains the document library name. If the file is in a folder, FileDirRef will also contain the name of the folder.

The FileRef field contains the full name, including the document library name, any folders, and the name of the file.

The CAML query looks for an item in the document library where the FileLeafRef field has a value of Test.docx, and sets the RowLimit element of the View element to one.

camlQuery.ViewXml =

@"<View>

<Query>

<Where>

<Eq>

</Eq>

</Where>

</Query>

</View>";

Because the example sets the RowLimit element to one, we know that the query will return a ListItemCollection object with either zero or one items in it, so we can test if listItems.Count == 1 to determine if the query found the document or not.

To retrieve the file, we use the Microsoft.SharePoint.Client.File.OpenBinaryDirect method to return an object of type Microsoft.SharePoint.Client.FileInformation.

FileInformation fileInformation =

ClientOM.File.OpenBinaryDirect(clientContext, (string)item["FileRef"]);

The FileInformation object contains a reference to a stream, which we can use to stream the file to our application. However, that stream is not a resizable stream. The WordprocessingDocument.Open method takes a stream as an argument, but that stream must be a resizable stream. Therefore, we have to create a MemoryStream object, and then copy from the stream returned by the FileInformation.Stream property into the MemoryStream object. If we try to open the WordprocessingDocument object from the stream returned by the FileInformation.Stream property, the Open XML SDK will throw an exception, System.IO.IOException, with the message “Cannot open package because FileMode or FileAccess value is not valid for the stream.”

You may have noticed that it was not necessary to call the ClientContext.ExecuteQuery method before accessing the FileInformation.Stream property. This is because the File.OpenBinaryDirect method does not participate in the normal network communication of the client object model. In the article Using the SharePoint 2010 Managed Client Object Model, I explained how the client side of the client object model bundles requests as XML, the XML is sent to the server, which fulfills the requests, and then sends the response in JSON. If you were to upload files using the XML and JSON, the client object model would need to convert the binary Open XML document to Base64 encoding. Using this encoding is less efficient than directly sending the binary data. Microsoft recommends that where possible to directly send binary data. This will result in a more efficient application and less network traffic.

Once we have a MemoryStream object, which is resizable if created with the constructor that takes no parameters, then we can open the document using the Open XML SDK, and process it as usual.

The MemoryStream class contains a constructor that takes a byte array, which is then subsequently used as the backing store for the stream. However, that constructor returns a memory stream that is not resizable, so we can never use that constructor to create a memory stream for use with the Open XML SDK.

Modifying a Document in a Document Library

We can modify the previous example so that it alters the document, and places the altered document back into the document library.

using System;

using System.IO;

using System.Linq;

using DocumentFormat.OpenXml.Packaging;

using DocumentFormat.OpenXml.Wordprocessing;

using Microsoft.SharePoint.Client;

using ClientOM = Microsoft.SharePoint.Client;

class Program

{

static private void CopyStream(Stream source, Stream destination)

{

byte[] buffer = new byte[32768];

int bytesRead;

{

bytesRead = source.Read(buffer, 0, buffer.Length);

destination.Write(buffer, 0, bytesRead);

} while (bytesRead != 0);

}

static void Main(string[] args)

{

ClientContext clientContext =

new ClientContext("http://intranet.contoso.com");

List sharedDocumentsList = clientContext.Web.Lists

.GetByTitle("Shared Documents");

CamlQuery camlQuery = new CamlQuery();

camlQuery.ViewXml =

@"<View>

<Query>

<Where>

<Eq>

</Eq>

</Where>

</Query>

</View>";

ListItemCollection listItems =

sharedDocumentsList.GetItems(camlQuery);

clientContext.Load(sharedDocumentsList);

clientContext.Load(listItems);

clientContext.ExecuteQuery();

if (listItems.Count == 1)

{

ClientOM.ListItem item = listItems[0];

Console.WriteLine("FileLeafRef: {0}", item["FileLeafRef"]);

Console.WriteLine("FileDirRef: {0}", item["FileDirRef"]);

Console.WriteLine("FileRef: {0}", item["FileRef"]);

Console.WriteLine("File Type: {0}", item["File_x0020_Type"]);

FileInformation fileInformation =

ClientOM.File.OpenBinaryDirect(clientContext,

(string)item["FileRef"]);

using (MemoryStream memoryStream = new MemoryStream())

{

CopyStream(fileInformation.Stream, memoryStream);

using (WordprocessingDocument doc =

WordprocessingDocument.Open(memoryStream, true))

{

// Insert a new paragraph at the beginning of the

//document.

doc.MainDocumentPart.Document.Body.InsertAt(

new Paragraph(

new Run(

new Text("Newly inserted paragraph."))), 0);

}

// Seek to beginning before writing to the SharePoint server.

memoryStream.Seek(0, SeekOrigin.Begin);

// SaveBinaryDirect replaces the document on the SharePoint

// server.

ClientOM.File.SaveBinaryDirect(clientContext,

(string)item["FileRef"], memoryStream, true);

}

else

Console.WriteLine("Document not found.");

}

[Download Code]

Notice that we passed true to the WordprocessingDocument.Open method, because we are going to modify the document. Once we have the document open using the Open XML SDK, we can modify it as usual.

After exiting the scope created by the statement that opens the document (by calling the WordprocessingDocument.Open method), the MemoryStream object will contain the modified document. Before we can stream it back to the server, we need to seek to the beginning of the stream. Then, we call the File.SaveBinaryDirect method, which places the altered document back into the document library.

Uploading a Document to a Document Library

The next operation that we want to cover is uploading an existing document to a document library. We can upload a document by calling the File.SaveBinaryDirect method, passing the server relative URL, and a stream. The following example uploads a new document to the Shared Documents folder:

using System;

using System.IO;

using DocumentFormat.OpenXml.Packaging;

using DocumentFormat.OpenXml.Wordprocessing;

using Microsoft.SharePoint.Client;

// The following directive is used to avoid ambiguity between the

// System.IO.File and Microsoft.SharePoint.Client.File classes.

using ClientOM = Microsoft.SharePoint.Client;

class Program

{

static void Main(string[] args)

{

ClientContext clientContext =

new ClientContext("http://intranet.contoso.com");

using (FileStream fileStream =

new FileStream("NewDocument.docx", FileMode.Open))

ClientOM.File.SaveBinaryDirect(clientContext,

"/Shared Documents/NewDocument.docx", fileStream, true);

}

[Download Code]

Creating a New Document in Memory and Adding it to a Document Library

There are two common ways that Open XML developers create documents:

Use an existing document as a template, open it, modify it in some desired way, and then save it to the desired location.
Create a document from scratch. Often, this is done with the help of DocumentReflector, a tool that comes with the Open XML SDK 2.0. This tool enables you to generate the C# code to create any Open XML document.

In either case, you can create the new document in a MemoryStream object. The following example reads a document into a byte array, creates a resizable memory stream using the MemoryStream constructor that takes no arguments, writes the byte array to the MemoryStream, alters that document in memory, then uploads the newly altered document to the Shared Documents library.

To run this example, create a new word-processing document named Template.docx, initialize it with any content you want (including no content at all), and place it in the bin directory where the example will run. The example inserts a new paragraph at the beginning of the document before uploading it to the document library.

using System;

using System.IO;

using DocumentFormat.OpenXml.Packaging;

using DocumentFormat.OpenXml.Wordprocessing;

using Microsoft.SharePoint.Client;

using ClientOM = Microsoft.SharePoint.Client;

class Program

{

static void Main(string[] args)

{

ClientContext clientContext =

new ClientContext("http://intranet.contoso.com");

byte[] byteArray = System.IO.File.ReadAllBytes("Template.docx");

using (MemoryStream memoryStream = new MemoryStream())

{

memoryStream.Write(byteArray, 0, (int)byteArray.Length);

using (WordprocessingDocument doc =

WordprocessingDocument.Open(memoryStream, true))

{

// Insert a new paragraph at the beginning of the

//document.

doc.MainDocumentPart.Document.Body.InsertAt(

new Paragraph(

new Run(

new Text("Newly inserted paragraph."))), 0);

}

string fileUrl = "/Shared Documents/NewDocumentFromTemplate.docx";

memoryStream.Seek(0, SeekOrigin.Begin);

ClientOM.File.SaveBinaryDirect(clientContext, fileUrl, memoryStream, true);

}

[Download Code]

Processing all Documents in a Library

Sometimes you want to iterate through all documents in a library, performing the same query or modification on each. The document library may contain folders, each containing documents, and possibly sub-folders. The following example shows how to use the Scope=’Recursive’ attribute of the View element to process all documents in a library, including documents that are in sub-folders.

If you are processing all documents in a large document library that contains more than 2000 documents, you will want to implement a paging algorithm, as detailed in Using the SharePoint 2010 Managed Client Object Model. If you are building an interactive application that does this, you may want to use asynchronous processing, as detailed in the section of that article entitled Asynchronous Processing.

using System;

using System.IO;

using System.Linq;

using DocumentFormat.OpenXml.Packaging;

using DocumentFormat.OpenXml.Wordprocessing;

using Microsoft.SharePoint.Client;

using ClientOM = Microsoft.SharePoint.Client;

class Program

{

static private void CopyStream(Stream source, Stream destination)

{

byte[] buffer = new byte[32768];

int bytesRead;

{

bytesRead = source.Read(buffer, 0, buffer.Length);

destination.Write(buffer, 0, bytesRead);

} while (bytesRead != 0);

}

static void Main(string[] args)

{

ClientContext clientContext =

new ClientContext("http://intranet.contoso.com");

List sharedDocumentsList = clientContext.Web.Lists

.GetByTitle("Shared Documents");

CamlQuery camlQuery = new CamlQuery();

camlQuery.ViewXml =

@"<View Scope='Recursive'>

<Query>

<Where>

<Eq>

</Eq>

</Where>

</Query>

</View>";

ListItemCollection listItems =

sharedDocumentsList.GetItems(camlQuery);

clientContext.Load(listItems);

clientContext.ExecuteQuery();

foreach (var item in listItems)

{

Console.WriteLine("FileLeafRef: {0}", item["FileLeafRef"]);

Console.WriteLine("FileDirRef: {0}", item["FileDirRef"]);

Console.WriteLine("FileRef: {0}", item["FileRef"]);

FileInformation fileInformation =

ClientOM.File.OpenBinaryDirect(clientContext,

(string)item["FileRef"]);

using (MemoryStream memoryStream = new MemoryStream())

{

CopyStream(fileInformation.Stream, memoryStream);

using (WordprocessingDocument doc =

WordprocessingDocument.Open(memoryStream, true))

{

var firstParagraph = doc.MainDocumentPart.Document

.Body.Elements<Paragraph>().FirstOrDefault();

if (firstParagraph != null)

{

string text = firstParagraph.InnerText;

Console.WriteLine(" First paragraph text: {0}",

text);

}

else

Console.WriteLine(

"Document doesn't contain any paragraphs.");

}

Console.WriteLine();

}

[Download Code]

When processing all Open XML documents in a document library or in a folder, it is convenient to use a CAML query to filter for documents of the desired document type, “docx” in this example. The emphasized code in the CAML query in the example shows how to do this.

The PowerTools for Open XML project contains a library to accept all tracked revisions for a word-processing document. It is an easy modification to this example to create a program that will iterate through all documents in a document library, accepting changes for each. You can find the RevisionAccepter class under the Downloads tab at http://www.codeplex.com/powertools.

Creating an Open XML Word-Processing Document from a SharePoint Wiki

Using the Open XML SDK along with the client object model allows us to do some innovative things. Sometimes a SharePoint wiki user might have the need to distribute an Open XML word-processing document to people who don’t have access to that wiki. Those people may be customers or vendors who don’t have access to the corporate network, but have a need for the information contained in the wiki. It would be convenient to convert a SharePoint wiki to an Open XML document that you can send to anyone who has Microsoft Word 2007 or 2010. We can build an example program that does this using the client object model.

We will use the altChunk capabilities of Open XML to accomplish this. Open XML WordprocessingML provides the capability for importing external content through the altChunk element. To use altChunk, you do the following:

You create a new part in the package. The part can have a number of content types, including entire Open XML documents, HTML, or plain text. We’ll use the ability to import HTML in this example.
You store the content that you want to import into the part.
When you create the part, you create a relationship from the main document part to the new alternative format part.
You add a w:altChunk element at the location where you want to import the alternative format content. The r:id attribute of the w:altChunk element identifies the chunk to import. The w:altChunk element is block-level content, which means that you can insert it in the document anywhere you can insert a paragraph (w:p) element.

This example extracts the HTML for each topic in the wiki, and inserts each page into its own part, and imports each part into the document using w:altChunk.

One important point to make about altChunk is that it is used only for importing content. If you open the document using Word 2007 or Word 2010 and save it, the newly saved document will not contain the alternative format content part, nor the altChunk markup that references it. Microsoft Word 2007 or Microsoft Word 2010 will convert the HTML to WordprocessingML markup such as paragraph elements (w:p), run elements (w:r), and text elements (w:t).

First, I’ll show a small example that extracts the contents of each wiki page as HTML:

using System;

using System.Xml.Linq;

using Microsoft.SharePoint.Client;

class RetrieveListItems

{

static void Main()

{

ClientContext clientContext = new ClientContext("http://intranet.contoso.com");

List oList = clientContext.Web.Lists.GetByTitle("Eric's Wiki");

CamlQuery camlQuery = new CamlQuery();

camlQuery.ViewXml = @"<View/>";

ListItemCollection listItems = oList.GetItems(camlQuery);

clientContext.Load(

listItems,

items => items.Include(

item => item["FileRef"],

item => item["WikiField"]));

clientContext.ExecuteQuery();

foreach (ListItem oListItem in listItems)

{

Console.WriteLine("FileRef: {0}", oListItem["FileRef"]);

XElement e = XElement.Parse((string)oListItem["WikiField"]);

Console.WriteLine(e);

Console.WriteLine("====================================");

}

[Download Code]

Change the URL that is passed to the ClientContext constructor to the URL of your SharePoint site. Change the title that is passed to the ClientContext.ListCollection.GetByTitle method to the title of a wiki in your SharePoint site.

This example uses LINQ to XML to format (indent) the XHTML that we retrieve from the wiki. When you run this example, you will see something like the following:

FileRef: /Erics Wiki/AnotherPage.aspx

<tbody>

<div>

<p>This is some content in another page.</p>

<p>

</p>

<p></p>

</div>

</td>

</tr>

</tbody>

</table>

<span id="layoutsData" style="display:none">false,false,1</span>

</div>

====================================

FileRef: /Erics Wiki/This is a longer title of a page.aspx

<tbody>

<div>

<p>This page contains some content we will extend in the future.</p>

<p></p>

</div>

</td>

</tr>

</tbody>

</table>

<span id="layoutsData" style="display:none">false,false,1</span>

</div>

As you can see, the contents of each page in the wiki are contained in a <div> element. Inside the <div> element is a table element that the wiki uses for layout. The element that we’re really interested in is the <div> element inside the table cell that has a class attribute with the value of ms-rte-layoutszone-outer. When we construct the HTML to insert in the alternative format import part, we will insert that inner <div> element into the <body> element of the HTML document. The example will then write the newly constructed HTML into the alternative content part.

This conversion does not convert wiki links to bookmarks and links within the document. In addition, there are certain characters that can be inserted in the wiki page that don’t convert properly. It is a proof-of-concept, and is intended to show the possibilities of using the client object model with Open XML. It is not intended to solve all issues associated with conversion of a SharePoint wiki to an Open XML document.

Here is the example to extract the contents of all pages of a SharePoint wiki, and create a word-processing document from them.

using System;

using System.Linq;

using System.IO;

using System.Xml.Linq;

using Microsoft.SharePoint.Client;

using ClientOM = Microsoft.SharePoint.Client;

using DocumentFormat.OpenXml.Packaging;

using DocumentFormat.OpenXml.Wordprocessing;

class RetrieveListItems

{

static void Main()

{

ClientContext clientContext =

new ClientContext("http://intranet.contoso.com");

List oList = clientContext.Web.Lists.GetByTitle("Eric's Wiki");

CamlQuery camlQuery = new CamlQuery();

camlQuery.ViewXml = @"<View/>";

ListItemCollection listItems = oList.GetItems(camlQuery);

clientContext.Load(

listItems,

items => items.Include(

item => item["FileLeafRef"],

item => item["WikiField"]));

clientContext.ExecuteQuery();

System.IO.File.Delete("WikiDocument.docx");

System.IO.File.Copy("EmptyDocument.docx", "WikiDocument.docx");

int altChunkIdCounter = 1;

int blockLevelCounter = 0;

bool first = true;

using (WordprocessingDocument myDoc =

WordprocessingDocument.Open("WikiDocument.docx", true))

{

MainDocumentPart mainPart = myDoc.MainDocumentPart;

mainPart.Document.Body.RemoveAllChildren<Paragraph>();

foreach (ClientOM.ListItem listItem in listItems)

{

string wikiPageTitleAspx = (string)listItem["FileLeafRef"];

string wikiPageTitle = wikiPageTitleAspx.Substring(

0, wikiPageTitleAspx.Length - 5);

if (first)

{

first = false;

mainPart.Document.Body.InsertAt(new Paragraph(

new ParagraphProperties(

new RunProperties(

new RunFonts()

{

AsciiTheme = ThemeFontValues.MajorHighAnsi,

HighAnsiTheme = ThemeFontValues.MajorHighAnsi

new Bold(),

new Color()

{

Val = "1F497D",

ThemeColor = ThemeColorValues.Text2

new FontSize() { Val = 28 },

new FontSizeComplexScript() { Val = 28 }),

new ParagraphStyleId() { Val = "Heading1" }),

new Run(

new RunProperties(

new RunFonts()

{

AsciiTheme = ThemeFontValues.MajorHighAnsi,

HighAnsiTheme = ThemeFontValues.MajorHighAnsi

new Bold(),

new Color()

{

Val = "1F497D",

ThemeColor = ThemeColorValues.Text2

new FontSize() { Val = 28 },

new FontSizeComplexScript() { Val = 28 }),

new Text(wikiPageTitle))),

blockLevelCounter++);

}

else

{

mainPart.Document.Body.InsertAt(new Paragraph(

new Run(

new Break() { Type = BreakValues.Page })),

blockLevelCounter++);

mainPart.Document.Body.InsertAt(new Paragraph(

new ParagraphProperties(

new RunProperties(

new RunFonts()

{

AsciiTheme = ThemeFontValues.MajorHighAnsi,

HighAnsiTheme = ThemeFontValues.MajorHighAnsi

new Bold(),

new Color()

{

Val = "1F497D",

ThemeColor = ThemeColorValues.Text2

new FontSize() { Val = 28 },

new FontSizeComplexScript() { Val = 28 }),

new ParagraphStyleId() { Val = "Heading1" }),

new Run(

new RunProperties(

new RunFonts()

{

AsciiTheme = ThemeFontValues.MajorHighAnsi,

HighAnsiTheme = ThemeFontValues.MajorHighAnsi

new Bold(),

new Color()

{

Val = "1F497D",

ThemeColor = ThemeColorValues.Text2

new FontSize() { Val = 28 },

new FontSizeComplexScript() { Val = 28 }),

new Text(wikiPageTitle))),

blockLevelCounter++);

}

XElement wikiField = XElement.Parse((string)listItem["WikiField"]);

XElement div = wikiField.Descendants("div").Where(e =>

(string)e.Attribute("class") == "ms-rte-layoutszone-inner")

.FirstOrDefault();

string html = String.Format(

"<html><head/><body>{0}</body></html>",

div != null ? div.ToString() : "");

string altChunkId = String.Format("AltChunkId{0}",

altChunkIdCounter++);

AlternativeFormatImportPart chunk =

mainPart.AddAlternativeFormatImportPart(

AlternativeFormatImportPartType.Xhtml, altChunkId);

using (Stream chunkStream = chunk.GetStream(FileMode.Create,

FileAccess.Write))

using (StreamWriter stringStream = new StreamWriter(chunkStream))

stringStream.Write(html);

AltChunk altChunk = new AltChunk();

altChunk.Id = altChunkId;

mainPart.Document.Body.InsertAt(altChunk,

blockLevelCounter++);

}

mainPart.Document.Save();

}

[Download Code]

It provides quite a bit of functionality in less than 130 lines of code. Here is what one of the pages in the SharePoint wiki looks like:

The same page, as shown in Word 2010 looks like this:

Conclusion

The SharePoint 2010 Managed Client Object Model enables developers to write powerful client-side applications that work with SharePoint 2010 Foundation Server and SharePoint 2010 Server. The Open XML SDK provides the ability to create, modify, and query Open XML documents. When used together, they enable new ways of using Open XML documents to collaborate and share information.

Additional Resources

This article combines the use of two technologies: the Open XML SDK, and the SharePoint 2010 Managed Client Object Model. The first place to start with Open XML is the Open XML Developer Center on MSDN. There is a lot of content there, including MSDN articles, How To videos, and links to lots of blog posts. In particular, the following will help you get started with the Open XML SDK 2.0:

Download the Open XML SDK 2.0

Creating Documents by Using the Open XML Format SDK 2.0 (Part 1 of 3)

Creating Documents by Using the Open XML Format SDK 2.0 (Part 2 of 3)

Creating Documents by Using the Open XML Format SDK 2.0 (Part 3 of 3)

There are a lot of resources to help you get started using the SharePoint 2010 Managed Client Object Model. First, read in Using the SharePoint 2010 Managed Client Object Model. In addition, the following are good resources for the client object model:

Using the Client APIs

SharePoint 2010 Developer Center

How to: Work with Web Sites

How to: Work with Users and Groups

How to: Break Role Assignment Inheritance

How to: Work with User Custom Actions

Assembling Paragraph and Run Properties for Cells in an Open XML WordprocessingML Table

EricWhite — Thu, 12 Nov 2009 05:25:00 GMT

[Blog Map]

Update Dec 15, 2009: This is the 6th in a series of posts on implementing a transform of WordprocessingML to XHtml.

1) Transforming Open XML Word-Processing Documents to XHtml

2) Transforming Open XML Word-Processing Documents to XHtml (Post #2)

3) Transforming Open XML Word-Processing Documents to Html (Post #3)

4) Open XML WordprocessingML Style Inheritance

5) Comparison of Html/CSS Tables to WordprocessingML Tables

6) Assembling Paragraph and Run Properties for Cells in an Open XML WordprocessingML Table

7) Implementing 'Inheritance' in XML

8) Working with Numbering in Open XML WordprocessingML

When we want to render a paragraph and its runs inside of a cell, we need to assemble the paragraph and run properties from a number of places. In a previous post, I explained how style inheritance works, and how you 'roll-up' styles from the style chain. That is only part of the story. This post details how we assemble styling information from:

Table styles
The formatting directly applied to tables, paragraphs, and runs
The global default paragraph and run properties.

In the process of assembling paragraph and run properties, we also need to correctly handle something called 'Toggle Properties'.

Note: next, I'm going to tackle the semantics of numbering styles, and then I believe I'm ready to start coding in earnest. I've made a decision in this project to first implement a transform to XHtml without styling information. The resulting XHtml will contain just the content of the document. I decided to do this because it is useful in its own right, and we need it for another project. Having code to extract the contents of a document in the most succinct form possible has a lot of uses. Of course, this XHtml still can be rendered in a browser, and in some cases, it will be useful to do this. Then, after publishing that code, I'll start implementing styling behavior.

Table Styles

A very powerful and cool feature of Word is that when you are applying a table style you pick and choose which aspects of the style you want to apply. For consistency, you can apply the same style to all tables in your document, but some tables may have a total row, and other tables may not:

You can apply the same style to both, then pick and choose which aspects of the table style to apply. When you are applying a table style, this is what the Ribbon in Word 2007 looks like:

You can see the range of check boxes in the Table Style Options section of the Ribbon, and how you can pick and choose which aspects of the style you want to apply. This has ramifications for us when we are assembling styling information for a cell. We know the table style for the table, and we also know the values of those check boxes, so we have to apply the various aspects of the table style per the user's preferences from those check boxes.

Before we dive into table styles in depth, we need to cover toggle properties, which play a part in how table styles work.

Toggle Properties

Toggle properties consist of a set of run properties that have a little twist in their semantics when assembling formatting information in preparation to rendering paragraphs in some fashion. The w:b element (which styles a run as bold) is a good example of a toggle property.

Here's how toggle properties work:

Toggle properties only have their toggle behavior when associated with table styles, paragraph styles, and character styles. If a run has been made bold per the table style, and the user applies a paragraph style that also has the w:b element, the net result is that original bolded text is now made not bold. And if some portion of that paragraph has a bold character style applied to it, that portion is now made bold again.

This makes sense. The table style designer designated that a cell be bold. The paragraph style designer had the intention of making text in the paragraph stand out. But the text is already bold, so that intent won't be satisfied, so to make it stand out, we reverse the boldness of the text. The same reasoning also applies to a character style that has the w:b element.

It's just these three types of styles (table, paragraph, and character) that we need to process in this fashion. If the user subsequently selects that text and presses the bold button on the toolbar, setting the properties on the run itself (not a style), we honor his or her intention, regardless of the boldness of the table, paragraph, or run styles. Also, the global run properties completely override the toggling behavior (but not directly applied formatting). If the w:b element is set on the global run property, effectively making the entire document bold, the entire document remains bold, unless formatting is set directly on a run.

The set of toggle properties are: §2.3.2.1 (Bold), §2.3.2.2 (Complex Script Bold), §2.3.2.4 (Display All Characters as Capital Letters), §2.3.2.11 (Embossing), §2.3.2.14 (Italics), §2.3.2.15 (Complex Script Italics), §2.3.2.16 (Imprinting), §2.3.2.21 (Display Character Outline), §2.3.2.29 (Shadow), §2.3.2.31 (Small Caps), §2.3.2.35 (Single Strikethrough), and §2.3.2.39 (Hidden Text). The section numbers are for Ecma-376 version 1.

Assembling Styling Properties for Cells in a Table

Due to the richness of table styles, as shown above, table, row, cell, paragraph and run properties can be stored in multiple places in a table style. Determining the properties for a table style involves rolling up those styles, in the exact same fashion as I described for rolling up style properties in the previous blog post. While rolling up that information, we need to either merge attributes, merge child elements, or replace elements.

Shading of the table cells comes from the table cell properties (w:tcPr). Formatting of the text in table cells comes from the paragraph properties (w:pPr) and run properties (w:rPr). Other necessary properties for rendering come from the table properties (w:tblPr) and table row properties (w:trPr). The process for assembling the correct table styling information for a cell is the same for each of these. In the following section, I describe the process of assembling styling information for runs in a table per the table style, but the same approach applies to assembling styling information for the other aspects of a table style (table, row, cell, and paragraph properties). When I write code to do this, of course, I'm going to write only one set of methods to do this assembling of styling information, and parameterize those methods so that I can use it for assembling all aspects of conditional table formatting properties.

To determine the run properties from a style for a cell in a table, we do the following, in order:

We first roll-up all table styles in the table style chain, per my post, Open XML WordprocessingML Style Inheritance.
We retrieve the value of the w:tblLook element from the table that we're rendering, which indicates which of the conditional table formatting properties we will apply to the table.
We create an empty list of the run style properties (the w:rPr element). In the following steps, we will be adding run style properties to this list, based on the circumstances, and after assembling all the items in the list, we will roll them up to give us the appropriate styling information for the cell. Note that in the following steps, if the w:tblStylePr element does not exist, it is not an error. It just means that we don't need to do anything for that particular step.
We add to the list:

The run style property for the whole table style from w:tblStylePr[@w:type = 'wholeTable'].
If we should apply column banding, per the w:tblLook element

If the cell is an odd banded column cell, then add the run style property from w:tblStylePr[@w:type = 'band1Vert']
If the cell is an even banded column cell, then add the run style property from w:tblStylePr[@w:type = 'band2Vert']

If we should apply row banding, per the w:tblLook element

If the cell is an odd banded row cell, then add the run style property from w:tblStylePr[@w:type = 'band1Horz']
If the cell is an even banded column cell, then add the run style property from w:tblStylePr[@w:type = 'band2Vert']

If we should apply the first row formatting, per the w:tblLook element

If the cell is in the first row, then add the run style property from w:tblStylePr[@w:type = 'firstRow']
In addition, if the cell is in a row with the w:tblHeader element, then add the run style property from w:tblStylePr[@w:type = 'firstRow']

If we should apply the last row formatting, per the w:tblLook element

If the cell is in the last row, then add the run style property from w:tblStylePr[@w:type = 'lastRow']

If we should apply the first column formatting, per the w:tblLook element

If the cell is in the first column, then add the run style property from w:tblStylePr[@w:type = 'firstCol']

If we should apply the last column formatting, per the w:tblLook element

If the cell is in the last column, then add the run style property from w:tblStylePr[@w:type = 'lastCol']

If the cell is the top left cell, then add the run style property from w:tblStylePr[@w:type = 'nwCell']
If the cell is the top right cell, then add the run style property from w:tblStylePr[@w:type = 'neCell']
If the cell is the bottom left cell, then add the run style property from w:tblStylePr[@w:type = 'swCell']
If the cell is the bottom right cell, then add the run style property from w:tblStylePr[@w:type = 'seCell']

Now that we have a list of run properties, we roll them up. We now have a set of style run properties that we can apply to the cell.

Note that this only gets the run properties for a table style. Once we have rolled up the run properties for the table style, we assemble the following, in order:

The run properties for the table style (per the above procedure)
The run properties for the paragraph style for the paragraph that contains the run
The run properties for the run style applied to the run

We then roll these three up, implementing the toggling behavior for toggle properties that I described earlier. Once we have done this process, we assemble the following, in order:

The global default run properties.
The rolled up run properties from the table styles.
The rolled up run properties from a directly applied run style.
The global defaults, with all properties except toggle properties removed. (This will provide the behavior that global properties trump style toggle properties.)
The run properties that are applied directly to a run.

We roll these up, and we finally have the run properties that we can apply to the run.

When we're assembling the paragraph properties for a table style, we follow a similar procedure. Once we have that rolled-up property, we need to assemble a new list of paragraph properties, in the following order:

The global default paragraph properties
The table style paragraph properties (per the above procedure)
The paragraph properties applied directly to a paragraph

We then roll up these three sets of paragraph properties, and we have the paragraph properties that we can apply to the paragraph in the cell.

This seems harder than it actually is. While this is a bit involved, this is what enables the very cool table styling capabilities that we see in Word. I just have to say, this is one of those cases where I really appreciate LINQ to XML. I personally really would not want to write old-style imperative code to do this.

One more point about this – I mentioned in an earlier post about an approach of adding paragraph and run properties with ordering applied to every paragraph and run in the document. I still think that this approach will work best. It means that I can assemble the style paragraph properties for a cell, then add them to every paragraph in the cell. I can assemble the style run properties for a cell, then add them to every run. This means that I'll only need to compute the style paragraph properties for a particular cell once, not for every paragraph in the cell. Same holds true for runs also.

SharePoint 2010 and Office 2010 Developer Training Courses Launched on Channel 9

EricWhite — Tue, 10 Nov 2009 06:46:00 GMT

Channel 9 launched new developer training courses for SharePoint 2010 and Office 2010. I know the folks who produced this, and personally seen a lot of it. This is good stuff. The training consists of extensive recordings from top MVPs/experts on how to develop with both SharePoint and Office 2010. As a developer, I'm personally particularly enthused about three developer aspects of SharePoint 2010: Client Object Model, Sandboxed Solutions, and LINQ to SharePoint, but there's a lot more there than that. If you haven't seen what the buzz is about, check it out.

SharePoint 2010 Developer Training: SharePoint 2010 has evolved into a first-class developer platform. Visual Studio 2010 integration is fantastic.

Office 2010 Developer Training: There are a number of new features and UI extensions that you'll want to know about.

Also while I'm at it, want to let you know about Windows Server 2008 R2 training. I really appreciate W2008 R2.

Eric White's Blog : OpenXML

Working with Numbering in Open XML WordprocessingML

Markup for a Simple Numbered List

Markup for a Simple Bulleted List

Markup for a Multi-Level List

Markup for Numbering that is Linked to Styles

Overriding a Number Format in a Multi-Level List with a New Number Format

Overriding a Number Format in a Multi-Level List, creating a new Multi-Level List Format

The w:startOverride Element

Defining a new List Style

Alternatives for the List Item Suffix

The w:lvlRestart Element

The w:isLgl Element

Algorithm to Assemble List Item Text

Implementing 'Inheritance' in XML

Using the SharePoint 2010 Client Object Model with Open XML

Table of Contents

Overview

Retrieving a Document from a Document Library

Modifying a Document in a Document Library

Uploading a Document to a Document Library

Creating a New Document in Memory and Adding it to a Document Library

Processing all Documents in a Library

Creating an Open XML Word-Processing Document from a SharePoint Wiki

Conclusion

Additional Resources

Assembling Paragraph and Run Properties for Cells in an Open XML WordprocessingML Table

Table Styles

Toggle Properties

Assembling Styling Properties for Cells in a Table

SharePoint 2010 and Office 2010 Developer Training Courses Launched on Channel 9