Markup Compatibility & Extensibility Doug Mahugh, Microsoft
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Markup Compatibility &
Extensibility Doug Mahugh, Microsoft
Definitions
• Markup Document
– XML Docs which conform to a markup specification
• Markup Specification
– aka ISO29500, Part 3
Dramatis Personae
• Markup Consumers – Readers of Markup Documents
• Markup Producers – Writers of Markup Documents
• Markup Editors – Tools which both read/write Markup Documents
– For simplicity: this presentation presumes “app”, “client” == Markup Editor
– Examples: Word, Excel, PowerPoint
MCE Problem Statement
• Two Apps: A and B • A & B have features
common to both Produce some markup subset
both apps can read and understand
• A & B have features (or variants) unique to themselves Produce markup consumable
by A or B only
Want documents (markup) to be interoperable amongst A & B
App B
App A
What does “interoperable” mean?
• What behaviors must markup editors implement to be interoperable?
• What level of user experience constitutes interoperable?
Answers which markup constructs we use
Base Case: Ignorable
Namespaces • App B produces some markup App A doesn’t
understand
– Expectation: App A can still open App B documents
• Example
– App B: Microsoft Word 2010
– App A: Microsoft Word 2007
– Feature: Glow on Text
Example: Word Glow on Text
The mc:Ignorable attribute can occur anywhere The mc:Ignorable attribute can occur anywhere
Quiz Questions
• What happens when Word 2007 opens this Word 2010 document?
– What do I see visually?
– Editability
• Can I edit the “Glowing Text”
Richer Interoperability:
Requirements
Interoperability Requirements
Interoperability Requirements
Data Integrity
Data Integrity
Editability Editability Visual
Fidelity Visual
Fidelity
• 3 Design Pillars
– Data Integrity
– Visual Fidelity
– Editability
Pillar: Visual Fidelity
• Visual Fidelity expresses desire for A and B to see the same visual representation
• Recall: A & B may have different capabilities
• Problem: Can't always represent uprev feature in downrev software
• Visual Fidelity Solutions
– Raster Representations
– Express in terms of downrev features
Pillar: Editability
• Editability expresses desire to edit documents cross app
• Problem: Equivalent or similar features might not exist cross rev
• Editability Solutions
– Express as lowest common denominator of both revs
Pillar: Data Integrity
• Motivation: – To get around visual fidelity and editability problems,
create multiple representations of same data
• Data Integrity expresses desire to have multiple representations of data synchronized
• This is also a security issue in some cases: – Example: Delete nasty paragraph written about my boss
– Security Leak if data persists in alternative representation
• Data Integrity Solutions – Delete multiple representations
Pillar Interconnectivity
• Data Integrity Vs. Editability – More Secure
• No multiple versions • Lose up-level features (i.e editability) on down-rev
– More Editable • Need multiple versions (less secure)
• Data Integrity Vs. Visual Fidelity – More Secure
• No multiple versions • Can only represent in terms of lowest common denominator (less visual fidelity)
– More Visual Fidelity • Need multiple versions
• Editability Vs. Visual Fidelity – More Editable
• Represent as closely as possible using down-rev primitives
– More Visual Fidelity • Represent using raster image (no edits)
Future Extensibility
Requirements
Future Extensibility
Requirements
Data Integrity
Data Integrity
Editability Editability Visual
Fidelity Visual
Fidelity
Extension Lists
<extLst>/<ext> • Straight-up add-on extension to a schema
– Referred to in ISO/IEC 29500 Part 3 as “application-defined extension points”
– Included in the schemas as a child element of objects that would likely benefit from extensions
– Intended for orthogonal extensions: those that do not change the meaning of the extended object
• No alternative representation desired
• Expected use locations – Non-Visual Properties
Extension List Syntax
<extLst>/<ext>
Extension Block
URI identifier <extLst > <ext uri= “ http://schemas.open formats.org/presentationml/someextensionpoint ” > <p14 :foo
xmlns: p14 = “ http://s chemas.openformats.org/presentationml/2008/presentaionml ” >
… </p 14:foo> <ext> <ext uri= “http://schemas.somevendor.com/ presentationml/ s omeextensionpoint ” > <somevendor :bar
xmlns: somevendor = “ http://schemas.somevendor.com/ V20 /our n ame space ” >
… </somevendor :bar > </ext> …. <extLst>
Extension List Processing
• Each <ext> block examined in turn
• <ext> block is processed if uri identifier indicates it’s a known extension – The uri/guid identifies the particular effect
– This is a more granular approach that the namespace-based approach of ACBs
• Else <ext> block is saved in its entirety – So long as parent element continues to exist
• Processed <ext> blocks are unpreserved
Extension List Example
• Simplistic Scenario:
– Office 2009 Adds Notion of Security clearance needed to view a shape
– Foovendor decides to categorize shapes
Extension List Preservation Model
Document Document
Round-Trip Through Office 2007
Extensions Preserved Extensions Preserved • <extLst> deleted only if shape itself deleted
• Always preserved if parent element still exists • Used for behavior that remains valid even after
editing of parent element by down-level software
<AlternateContent> Blocks
• <Choice> amongst various options
• Used where visual fidelity/editability a concern
– One representation maximizes editability
– One representation maximizes visual fidelity
• Expected use
– Extensions of a Visual nature
– Multiple representations that may include multiple behaviors for the same element. (For example, down-level equivalents.)
<AlternateContent> Syntax
Alternate Content Block
Choice Block
<mc:AlternateContent>
<mc:Choice Requires="v3">
<v3:Circle Center="0,0" Radius="20" Color="Blue"
Opacity="0.5"
Luminance="13" />
<v3:Circle Center="25,0" Radius="20" Color="Black"
Opacity="0.5" Luminance="13" />
<v3:Circle Center="50,0" Radius="20" Color="Red"
Opacity="0.5"
Luminance="13" />
<v3:Circle Center="13,20" Radius="20" Color="Yellow"
Opacity="0.5" Luminance="13" />
<v3:Circle Center="38,20" Radius="20" Color="Green"
Opacity="0.5" Luminance="13" />
</mc:Choice>
<mc:Fallback>
<LuminanceFilter Luminance="13">
<Circle Center="0,0" Radius="20" Color="Blue"
v2:Opacity="0.5" />
<Circle Center="25,0" Radius="20" Color="Black"
v2:Opacity="0.5" />
<Circle Center="50,0" Radius="20" Color="Red"
v2:Opacity="0.5" />
<Circle Center="13,20" Radius="20" Color="Yellow"
v2:Opacity="0.5" />
<Circle Center="38,20" Radius="20" Color="Green"
v2:Opacity="0.5" />
</LuminanceFilter>
</mc:Fallback>
</mc:AlternateContent>
Requires Attribute
<AlternateContent> Processing
• Each <choice> block examined in turn
• Requires=“” lists a set of namespaces that must be understood to take that choice
• <choice> block is taken if requires namespaces matched
• First matched <choice> is taken
• <Fallback> taken when no choices matched
<AlternateContent> Example
• Example: Adding labels onto connectors
– A connector may have a label associated with it
Here is some label
Before Extension After Extension
Labels on Connectors
• Downrev Representation as connector + text
• Uprev Representation extends connector natively
Two objects in downrev
Just one in uprev
Downrev <Choice>
• Downrev Representation as connector + text
CONNECTOR
TEXTBOX
Note use of “p” to denote 2007 DrawingML namespace
Uplevel <Choice>
• Uplevel native extension
LABEL EXTENSION
“p14” denotes post-2007 DrawingML namespace
New “cntrLblPr” (Connector Label Property) introduced under connector Shape
Putting <Choices> Together
AlternateContent Block
Uplevel Choice
Downlevel Choice
<Choice> Preservation
• Word
– Untaken Choices Lost (No Preservation)
• XL
– Untaken Choices Lost (No Preservation)
<Choice> Preservation Model
(PPT)
Document Document
Round-Trip Through PPT 2007
Extensions Preserved only if
NO EDIT on affected choices
!NO EDIT
affected choices
Loose Ends: MCE Attributes
• PreserveElements and PreserveAttributes
– Hints on what to keep
– Behavior is implementation dependent
• Section 10.1.3: “A markup editor might use the presence of PreserveElements and PreserveAttributes
• Note that these are merely recommendations, whereas extLsts and ACBs are requirements.
Related Documents
