Reusable data markup language

Abstract

Methods and systems provide a computer markup language, referred to as Reusable Data Markup Language (“RDML”), and a data viewer for retrieving, manipulating and viewing documents and files in the RDML format that may be stored locally or over a network (e.g., the Internet). Generally, RDML permits the browsing and manipulation of numbers, as opposed to text and images like in HTML, and does so by including attributes describing the meaning of the numbers to be attached to the numbers. Documents compliant with the markup language encapsulate machine-readable documentation with numbers and data, and permit the data viewer to act as a combination web browser and spreadsheet to automatically read, interpret and manipulate the numbers and data.

Description

BACKGROUND[0001]1. Field of the Invention[0002]The present invention relates generally to data processing systems and, more particularly, to a computer markup language for use in a data browser and manipulator.[0003]2. Related Art[0004]Currently on the Internet, transmissions and communications are commonly conducted using a communication protocol called the HyperText Transfer Protocol (“HTTP”) which can be used to pass files and documents formatted in the HyperText Markup Language (“HTML”). A markup language is a way of embedding markup “tags,” special sequences of characters, that describe the structure as well as the behavior of a document and instruct a web browser or other program on how to display the document. Typically, documents or web pages formatted in HTML are simply ASCII text files that mix ordinary text with these markup tags.[0005]HTML has a relatively limited structure that defines a fixed set of tags with specific purposes. Further, HTML typically only works with t...

AI Technical Summary

Benefits of technology

"The present invention provides a markup language, called RDML, which allows users to easily browse and manipulate numerical data online. Users can use RDML to create a single data set by combining multiple numerical documents, and the data viewer automatically displays the combined data on a single screen. The data viewer also allows users to add their own tags to the numerical data to describe its characteristics. The invention also provides a chart view that automatically manipulates and displays numerical data based on its attributes, and a tree view that allows users to display different series of numerical data simultaneously and automatically displays descriptive textual components. Overall, the invention provides a more efficient and user-friendly way to work with numerical data."

Problems solved by technology

Further, HTML typically only works with text and images and typically only instructs a browser on how to display a document: the browser may read and display characters but does not “understand” the data content.

Consequently, conventional analytical programs allow for ad hoc review and manipulation of abstract numbers (e.g., a spreadsheet program or database program), but do not directly read their data from online sources.

Although XML's free-form structure permits the development of markup languages, such individualized markup languages are not compatible with each other because the use of the tags is not standardized in that different users use the tags for different purposes.

In today's business world, problems that typically accompany data manipulation often increase expense and difficulty.

One such problem is that often data and the documentation that describes the data are not both in electronic form.

This conventional approach to database and spreadsheet information often dictates that expensive database administrators are required to make transformations anytime data is being transferred from one system to another, expensive analysis of printed documentation is required in connection with any programming tasks, and the output rarely contains any indication of the original sources, structures, and manipulations that created that output.

Another obstacle impeding efficiency in conventional databases and spreadsheets is that calculations occur at too low of a conceptual level.

Analytic operations on single values at a time can be slow and prove costly when many different cells or record values are involved.

The lack of a standard markup language facilitating the browsing of numbers leaves no way to read, automatically manipulate and display differing types of numerical data read from multiple online sources on a single chart.

The computer industry is further hindered by the fact that data and analytic routines are not standardized.

While the computer industry has developed standards for file formats and function-level interfaces, it has not developed a general data format or content-analysis standards.

This results in expensive translation of data between systems, industries, companies and users using different protocols.

But the great investment in spreadsheet macros has generally been underutilized because such macros are “write once, use once” types of software; they are rarely reused by others.

One such problem is that spreadsheet data references usually are based on physical locations.

Another related problem is that numbers in spreadsheets have no measurement or semantic designators describing their meaning.

Absent a standard location and vocabulary, those indicators are useless.

An additional problem with conventional spreadsheet macros is the lack of documentation.

Because macros are typically only usable by their creators on the single spreadsheet they wrote them for, they tend to be totally undocumented: no common-language description, no help files, no data standards as to permissible values, source contact list, license information, etc.

Furthermore, there is no mass distribution mechanism for macros.

Spreadsheet macros are not web-friendly: they are generally limited to one spreadsheet brand and one platform, do not support hyperlinks, and cannot be searched by search engines.

Also, they are not supported by directory or classification system, and have no ready market.

Even further, users typically do not include unit testing, validity testing, error handling, and other end-user protections on the macros that they write.

The result is that users may be wary of the output of macros that they might try to add to their spreadsheets.

Conventional spreadsheet macros have difficulty making graphical interfaces to the data.

The lack of related graphical components further fuels this problem.

Finally, conventional spreadsheet macros are either too small to be worth a marketing effort, or too difficult to use to find a large audience.

This results in a lack of a business incentive to make them.

Images