Domain Transformation Languages for Universal Document Editing

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current applications for viewing and editing documents from different domains require separate tools, burdening users and developers with the need to learn multiple applications and maintain custom software, leading to increased programming errors and delayed availability of features for new domains.

Innovation Solution

A transformation system that converts documents into a common representation using intermediate languages (abstract, concrete, and graphical) to enable shared viewing and editing facilities across domains, reducing the need for custom software and allowing reuse of source code.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If separate viewing and editing applications are used for each document domain, then domain-specific functionality is optimized, but user burden and application complexity increase

Engineering Contradiction:

Improvedomain-specific functionalityVSAvoidapplication complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal viewing and editing application that can handle multiple document domains through domain transformation languages. The system transforms documents from various domains (word processing, programming, mathematical) into a common internal representation, allowing a single application to serve multiple purposes without requiring separate domain-specific applications.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent introduces domain transformation languages as intermediary layers between domain-specific documents and the common viewing/editing application. These transformation languages act as mediators that convert domain-specific syntax and concepts into a standardized internal representation, enabling the universal application to understand and process diverse document types without direct domain-specific code.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Adaptability or versatility

If separate viewing and editing applications are used for each document domain, then domain-specific features are optimized, but the burden on users to learn multiple applications increases

Engineering Contradiction:

Improvedomain-specific featuresVSAvoiduser learning burden

Core Design Contradiction:

Adaptability or versatilityVSEase of operation

Solution Approach 1:

The system provides a single universal application interface that works across all document domains. Users learn one set of operations and commands that apply consistently regardless of whether they are viewing word processing documents, programming code, or mathematical expressions, significantly reducing the learning burden while preserving domain-specific functionality through transformation.

Inventive Principle:

Principle #6Universality (Multi-functionality)

3Adaptability or versatility

If separate viewing and editing applications are used for each document domain, then domain-specific capabilities are optimized, but developer effort and programming errors increase

Engineering Contradiction:

Improvedomain-specific capabilitiesVSAvoiddevelopment effort

Core Design Contradiction:

Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The patent enables developers to build a single universal viewing and editing application that serves all document domains, eliminating the need to create and maintain multiple separate applications. This reduces development effort and the likelihood of programming errors while preserving domain-specific capabilities through the transformation language layer.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The domain transformation languages serve as an intermediary abstraction layer that isolates domain-specific logic from the core viewing and editing functionality. This separation allows developers to implement domain-specific transformations once and reuse the same core application across all domains, significantly reducing development effort and maintaining consistency.

Inventive Principle:

Principle #24Intermediary (Mediator)

4Adaptability or versatility

If custom software is created for each domain, then domain-specific requirements are met, but the time to availability of features for new domains is delayed

Engineering Contradiction:

Improvedomain-specific requirementsVSAvoidfeature availability time

Core Design Contradiction:

Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent segments the system into two independent parts: domain-specific transformation languages and a universal core application. When a new domain is needed, only the transformation language layer needs to be developed, while the universal core application with its features (editing, viewing, navigation) is immediately available and reusable, significantly reducing the time to availability compared to building custom software from scratch.

Inventive Principle:

Principle #1Segmentation

Data Source

PatentUS9158507B2Domain transformation languages

Publication Date: 2015.10.13 MICROSOFT TECHNOLOGY LICENSING LLC

AI summary

A method and system for transforming documents from different domains into a common representation for viewing and editing is provided. The system prepares the domain-specific document for visual representation by performing a series of transformations in a pipeline that convert the document from its domain-specific input state to a series of intermediate languages. The intermediate languages share the same syntax regardless of the domain of the document being transformed.