The document describes the different components that make up WordprocessingML, which is used to represent word processing documents. It outlines the main sections like paragraphs, tables, styles, and fields. It then focuses on the different methods for adding custom markup: smart tags for inline semantics, custom XML for embedding additional structures, and structured document tags for associated properties and behaviors. Each method of custom markup allows adding unique semantics to content in WordprocessingML documents.
3. Custom Markup
• WordprocessingML fully defines the set of
presentation information needed to present a
word processing document
• However, there are many scenarios where the
document 'type' dictates that additional
semantics are required
– For example, a customer name within an invoice.
The server shouldn't have to try to use string
matching or regular expressions to find that name
4. Custom Markup
• To satisfy this need, WordprocessingML
defines three built-in mechanisms for storing
this custom markup:
– Smart tags
– Custom XML markup
– Structured document tags (content controls)
• Each of these mechanisms provides a unique
way of putting semantics to content in
WordprocessingML
5. Smart Tags
• Smart tags provide a way of adding semantics
to a run (or runs) of text
The purple underline
is application
defined, but the
semantics are
shared
6. Smart Tags
• Smart tags store two pieces of semantic data:
– A URI (namespace) for the smart tag
– A name for the smart tag
• The first specifies the 'family' to which the
smart tag belongs, the second specifies the
type of this specific smart tag within that
family
7. Smart Tags
• Optionally, producers can also embed
arbitrary name value pairs onto a smart tag
using the smart tag properties
– This is defined by the smartTagPr element
• Once embedded, consumers can ignore the
semantics without affecting the presentation
of the document, or use the smart tag data to
provide context sensitive functionality
8. Custom XML
• Custom XML markup provides a facility for
embedding the structure from any XML
schema file into a WordprocessingML
document
• This embedded custom XML can (but is not
strictly required to) follow the structures set
forth in that XML schema file
– We don't want to block load based on invalid
custom XML
9. Custom XML
• Custom XML can appear in two locations in
WordprocessingML
– Block level (around and/or sibling to paragraphs)
– Inline (around and/or sibling to runs)
12. Custom XML
• Custom XML element require two pieces of
semantic data:
– A namespace
– An element name
• Both are required to define/reference the
XML element within its XML schema
13. Custom XML
• Depending on the XML schema, the element
can also optionally specify any number of
attributes
• Once embedded, consumers can ignore the
semantics without affecting the presentation
of the document, or use the custom XML
markup to provide context sensitive
functionality
14. Custom XML
• Note: Why not just embed the custom XML
directly in the WordprocessingML document?
– Why do we use a customXml element in our
namespace to abstract away the real custom XML
element?
15. Custom XML
• Answer: This allows files with custom XML to
be strictly validated against the schemas we
provide
– If custom markup were in its own namespace, our
schema would need to declare an xsd:any at this
point
– That custom XML schema would then need to be
defined such that it allows WordprocessingML
within it, which is not desirable
16. Structured Document Tags
• Both methods of custom markup discussed
above add the semantics, but otherwise do
not have any effect on presentation
• This, however, is often not what you want
– e.g. you want user interface or behavior
restrictions as well as semantics
17. Structured Document Tags
• Defined using the sdt element
• Structured document tags provide customer-
defined semantics, as well as the ability to
define presentation/behavior information
18. Structured Document Tags
• A structured document tag has two child
elements:
– The structured document tag properties
– The structured document tag content
20. Structured Document Tag
Properties
• The XML representation of a structured
document tag is analogous to other
WordprocessingML structures – all properties
are contained in the sdtPr element
• Four types of properties:
– Shared properties
– Locking properties
– SDT 'type'
– Type-specific properties
21. Structured Document Tag
Properties
• Shared Properties
– Title
– ID
– Placeholder text
• This is reference to a document building block, which
will be discussed in the future
– Showing placeholder text?
• Locking Properties
– Cannot be deleted
– Cannot be edited
22. Structured Document Tag
Properties
• Locking Properties
– Cannot be deleted
– Cannot be edited
• These are runtime behaviors applied to this
structured document tag
23. Structured Document Tag
Properties
• Types
– Plain text
– Rich text
– Date picker (plain text)
– Combo box (plain text)
– Drop-down list (plain text)
– Picture
24. Structured Document Tag
Properties
• Type-specific properties
– Plain text: Allow multiple lines, remove when
edited
– Date picker: Date format, date locale
– Combo box: combo box entries
– Drop-down list: drop-down list entries
• To ensure these are only set when valid, they
are stored under the type's element
25. Structured Document Tag
Properties Example
Shared properties
Date type + date specific
properties - note that
dateFormat and lid are
under the date element
26. Structured Document Tag Content
• Stored underneath the sdtContent element
• Specifies the contents of this structured
document tag
– Like custom XML markup, structured document
tags can be either inline or block-level as defined
by the WordprocessingML schemas
27. XML Mapping
• Technically a property on the structured
document tag, but a special one
– Specifies that that contents are a cache of data
stored in another part (a custom XML data
storage part)
• Specifies the part as well as an XPath
expression used to find the 'real' data
28. Disclaimer
This presentation is for informational purposes only, and should
not be relied upon as a substitute or replacement for Microsoft
formal file format documentation, which is available at the
following website: https://msdn.microsoft.com/en-
us/library/cc313118(v=office.12).aspx. Any views or opinions
presented in this material are solely those of the author and do
not necessarily represent those of Microsoft. Microsoft
disclaims all liability for mistakes or inaccuracies in this
presentation.