[Bug 6864] MIME type for built-in datatypes

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6864





--- Comment #3 from Benjamin Carlyle <benjamincarlyle@soundadvice.id.au>  2009-05-12 12:12:20 ---
My use case doesn't involve WSDL or WS-* technologies at this stage, which is
why a mime type identifier is particularly useful. I work in the SCADA industry
where a great deal of the information we have to deal with is atomic data, or
atomic data with a few timestamps and other metadata attached. This information
is often transferred or updated in soft real-time and generally has a
safety-related aspect to it.
The main protocol I am using for interoperability between systems is HTTP,
which relies on a correct mime type both for content negotiation purposes (I
support a bare value, but will also accept a structured XML document with a
number and corresponding timestamp) and for correct parsing. In short, it's a
matter of being self-describing.
I have used text/plain as a proxy mime type for this purpose within my own
organisation alongside an internal vcalendar mime type where a known set of
metadata is used. I would like to have a more stable identifier available both
as something to make use of within my organisation and to recommend to others
who need to communicate very simple information such as numbers and strings,
the kinds of information that the built-in types codify well.
I would be inclined to have a single mime type identifier that said "one of
those xsd types". That is certainly the approach that we have taken for several
years in my organisation. Which one of those types is not important to my
application, and a bit of fuzz in this area is actually helpful to me. A server
may only support the "short" range, but a client that requests the data
expecting a long will parse the response value of "4" correctly. This allows a
single client with a sufficiently large range for its purpose to interact with
a range of different servers or resources with different ranges. The
"text/plain" == "some built-in type" rule has worked out to be sufficiently
self-describing for correct parsing and content negotiation but fuzzy enough to
allow different versions of software or independently-developed software to
exchange information effectively.
The exact purpose of the information can vary also. A major internal use case
for me is to get data onto a HMI shared between multiple services. This
requires a common data type, and again much of this data is primitive in
nature. Encoding "readiness" into the document for example would be something I
would see as counter productive in brining the information to as wide an
audience as possible. I really want everything from reports programs to
spreadsheets, to obviously other services to be able to pick this data up and
make use of it without a heavy relience on the notation that it is specifically
a defence readiness condition. To most of these clients it is just a number
they need to manipulate and output to a human or to another machine.
On the subject of making recommendations to others on how to deal with
exchanging primitive data via HTTP: I have some small regard in the REST
community, and am currently involved with writing a book for Prentice Hall -
"SOA with REST". This has been a motivator for me to I guess push some of the
internal best practices that have been developed within my organisation over
the wall to a wider standards audience.
To me this is an important building block of machine interoperability, and
attaching a mime type to it would be a useful step towards being able to
exchange these basic types easily... especially directly over HTTP.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 12 May 2009 12:12:30 UTC