[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Maximally Consumable Data
- From: "bryan rasmussen" <rasmussen.bryan@gmail.com>
- To: "Costello, Roger L." <costello@mitre.org>
- Date: Mon, 7 Apr 2008 10:09:29 +0200
quoting from article:
>Data can be formatted in a number of different ways. A data format
may be well suited for one task, but not another; whereas a second
data format may be well suited for the later task but not the former.
I don't think that formatting of data necessarily leads to a data
format, I think the usage is often that data is formatted for
presentation.
The suitability of a data format to a task part seems phrased wrongly,
I guess the way I try to think of it is as follows (not especially
well written thoughts come next):
Various problem domains naturally lend themselves to specific data
representations, some would be most efficiently represented
hierarchically, as graphs, in a relational model, in unstructured
document formats...
There is likely some overlap between how a particular form of data
should be best represented. There are a number of ways that these
representations are generally transmitted currently, hierarchical data
is often transmitted in the form of an XML dialect as an example. Thus
it is useful to describe XML as a data format; the choice of a data
format constrains the following choice of a data structure, it is the
choice of a data structure that is often most important to
consumability of a format - as an example if one chooses a data
structure for one's XML format that will lead to extremely large XML
instances it follows that consumability of that format will be limited
to those applications, programming languages, and programming
libraries that have support for dealing with large XML instances. The
choice of a data format and the subsequent choice of a data structure
is interlocked with how well suited ones problem domain is to
representation in the chosen format, combined with how well designed
the data structure is for representing the requirements of the problem
domain.
(the above was not meant as a definite summary of how I would describe
this situation, but just points I would think of as being most
salient)
quoting again from article:
>List of Consumable Items
> * XHTML Version: format your data using XHTML. That will make
your data consumable by browsers, and a variety of other devices.
I don't know that I feel consuming would be the best way to describe
what a browser does with XHTML.
> * XML Version: format your data using XML. That will make your
data consumable by machines.
See above descriptions, formatting your data as XML will at least in
theory make your data consumable by machines, but if the chosen
structure and limitations set on the structure are such that many
actual instances of your data will cause DOM parsers to crash the
consumability of the structure you have defined is limited by exactly
that extent of its tendency to crash applications made for consuming
it.
> * JSON Version: format your data using JSON. That will make your data consumable by JavaScript and Ajax applications.
XML is generally consumable by the same environments that JSON is
consumable by, furthermore both JSON and XML are hierarchical in
nature. The only benefit on consumability of these two formats are, I
think, that choosing one or the other would lead to developer
productivity increases in writing particular applications that need to
consume the actual data being sent. But that is really only
supposition on my part.
Cheers,
Bryan Rasmussen
On Mon, Apr 7, 2008 at 1:02 AM, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
>
> Goal: maximize the consumability of data.
>
> Here's a short article I wrote on how to achieve this goal:
>
> http://www.xfront.com/maximally-consumable-data/index.html
>
>
> Comments welcome.
>
> /Roger
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]