- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 12 May 2009 12:12:20 +0000
- To: www-xml-schema-comments@w3.org
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