Moving Sensor Data Onto The Internet With SensorML

Roland Piquepaille writes "According to this Sensors article, a new XML encoding scheme may make it possible for you to remotely discover, access, and use real-time data obtained directly from Web-resident sensors, instruments, and imaging devices. By describing sensors using SensorML, anyone can put sensors or sensor data online for others to find and use. And because it's XML-based, it means all this data will easily be searchable. "For example, searching for particular kinds of sensors and data in a particular geographic region, with data collected within a particular time window, will be easy. This has significance for science, environmental monitoring, transportation management, public safety, disaster management, utilities operations, industrial controls, facilities management, and many other activities." In this column, you'll find a summary of the Sensors' story which contains more technical details about the technology. And if you're really interested, please visit the SensorML homepage."

Comments

SensorML

[Jason1729]

They didn't shorten it to SML because everyone will pronounce it smell. Then half their FAQ will have to explain that smell sensors don't exist yet.

Jason
ProfQuotes

Re:SensorML

[Anonymous Coward]

Am I the only one sick and tired of all these *ML languages, there seems to be a new one every month popping up.

Objective CAML is quite nice anyway.

There seems to be lots of people that like this open source businessmodel.

1) Do free stuff.
2) ?
3) Make another *ML language.
4) Profit!

Re:SensorML

[Soko]

They could have justifiably named it Sensor Equipment eXtensible Markup Language. Imagine the FAQ for that one, though.

Soko

Re:SensorML

[rmolehusband]

Also, the functional programming language which made my university existence sheer hell, Standard ML already exists as is widely (within long beardy circles at least) known as SML.

Re:SensorML

[netsharc]

what else...

Re:SensorML

[Vengie]

Actually, they didn't shorten it to SML because that is Standard ML.

SML/NJ *cringe*

Disclaimer: I took a compilers course with Zhong Shao, who together with Appel of Princeton, made ML into a useable language. CURSE THEM BOTH.

Well, this makes for some interesting Flash Apps

[JasonKey]

With Flash's native XML interfaces, looks like some fun with graphing coming up. Anyone have any examples of this in use yet?

An application

[utopyr]

<I>
<have fallen="true">
<can>
<get up="false">
</can>
</I>

Re:An application

[Anonymous Coward]

that should be:

<I>
<have fallen="true"/>
<can>
<get up="false"/>
</can>
</I>

trust

[kilf]

It might be difficult to establish trust for these technologies. If I want to know the temperature in some distant city, how can I be sure that the sensor I address is correctly calibrated, or not resting near a air-con outlet? In fact, there would be no way to tell if the damn thing even exists- it could be a textfile sat on the sever or the local tourist office...

Re:trust

[SteveDob]

Surely, unless you knew for certain that individual sensor results could be trusted, and possibly not even then, you would sample several devices in, or near, the location of interest.

Re:trust

[Bertrum]

And so you would use the data you get accordingly. The problems you foresee already exist for any kind of data gathering. Unless you do it yourself, you don't know how accurate it is (and even then you can delude yourself).

Re:trust

[Anonymous Coward]

...
</sensor>

Re:trust

[Anonymous Coward]

Thank you, Mr. Anonymous Coward! You have shown us how easily XML solves yet another problem! The power of XML is truly amazing! Moreover, perhaps you can address the problems of people not bothering to fill all the fields correctly? And how do we know when the calibration was done, by whom, and how accurate it was?

Re:trust

[Anonymous Coward]

XML schemes, despite looking like semantic information, are syntactical definitions. The semantics are only in the names and other "human-readable" documentation. XML can't ensure that the data is valid, only that it is syntactically (formally) correct. It is possible to verify that all required fields are listed and that all given fields are filled with the right type of data, but obviously not that the data is correct. Certain values may allow verification of "correctness" (for example a digital signature of the person who calibrated the sensor), but that is beyond the scope of XML.

So what's the XML hype about? Parsers are not that hard to code, are they? Two things: Writing parsers is boring and all boring tasks are error-prone. Therefore do it once and do it right. Second, having a common syntax definition language on top of a simple and reusable verifying parser creates the possibility to create interoperable schemes. Using XML only makes sense as a first step, if it is followed by the second step: Agreeing on which information a sensor can/should/must provide. Without a common syntax (data format), that agreement would only result in a small fraction of the benefit. This second aspect of the importance of XML however is very likely to go wrong: Competing schemes for the same topic destroy interoperability. Just take a look at what happened to HTML during the "browser war" between Netscape and Microsoft.

Re:trust

[Citizen of Earth]

<sensor exists="true" iscalibrated="yeah">

I think you also need a youCanTrustMe="true" attribute.

Re:trust

[James.B]

This is the sort of thing that could be included in the XML format. If for instance you had a temperature sensor calibrated against a standard in a Telarc registered lab, the lab could provide along with the calibration certificate a digital certificate that could authenticate the sensor.

Now that would be usefull.

Yes, Possibilities...

[Dracos]

Just think of what could be done when Lego updates Mindstorms to use this.

Re:Yes, Possibilities...

[AntonyBartlett]

Just think of what could be done when Lego [lego.com] updates Mindstorms [lego.com] to use this.

Yes, I'm sure there are many many imaginative ways of encoding the three bits of sensor data that the Mindstorms RCX can recieve as XML

000 001 010 011 100 101 110 111
Those are all the possible states. Add tags to taste.

Re:Yes, Possibilities...

[hklingon]

actually, each input is analog. I have muxed one of them before to get 8-bits of input. The RCX isn't bad, once you put J2ME on it, or something decent. Here is a page where someone did the same thing with 6 inputs: http://members.axion.net/~rduff/rcxinput.html

Re:Yes, Possibilities...

[AntonyBartlett]

actually, each input is analog. I have muxed one of them before to get 8-bits of input. The RCX isn't bad, once you put J2ME on it, or something decent. Here is a page where someone did the same thing with 6 inputs: rcxinput.html

Cool, thanks for putting me right. Electronics has always fascinated me. Pity I keep falling asleep right at the beginning when they explain what all the coloured bands on the resistors mean.

Cute post, except smell sensors DO exist.

[jerryasher]

Google on smell sensors faq

Smell with a digital sensor

cyrano sciences

How Smell Sensors Work

. . .

I'd love to speak FML

[Anonymous Coward]

I've been trying but with limited success to speak FML.

If I'm brave and loaded, I can open a tag, but just can't quite seem to close one.

ESR can you help me?

Mod this up!

[jerryasher]

This is an incredibly insightful post. Funny, Interesting, and Underrated. Mod this one up!

world.sensors.find("Osama")

[Anonymous Coward]

This will incredibly simplify work of many
people:

if sensor=world.sensor.find("Saddam"):
print "Saddam is alive!"
for msgtype in voice,sms,im:
CIA.leavemessage(msgtype,"Saddam is at"+sensor.location)
else:
print "Saddam is dead!"
CNN.call("Saddam is dead!")

Re:world.sensors.find("Osama")

[sketerpot]

Ah, yes. Just think of the applications!

terrorists = world.sensor.find_by_attr("terrorist")
terrorists = filter(terrorists, lambda t: t.country == 'USA'
for terrorist in terrorists:
CNN.call("%s might be a terrorists! Panic, and watch your most trusted news source!"%terrorist.name

What?!

[Anonymous Coward]

This is an outrage. What about the First Amendment? Our civil rights? I'm opposed to sensorship of any kind!

Why oh why XML?

[leandrod]

Why XML with all its verboseness and hierarchy?

What I want is a relational or SQL schema. Then a much slimmer data transfer format would be possible.

Sure enough I can get XML data and input into a more useful SQL or relational database. But why go thru a verbose, hierarchical format, I can't see enough reason.

Re:Why oh why XML?

[alext]

Surely it's obvious that adding angle brackets can turn any dull old sequence of name/value pairs into a powerful data warehouse?

Re:Why oh why XML?

[leandrod]

> adding angle brackets can turn any dull old sequence of name/value pairs into a powerful data warehouse

Nice irony...

Re:Why oh why XML?

[Anonymous Coward]

I think a great advantage of XML is it's durability. Rather than a binary based format, even a well documented one, the text only nature of XML makes it easy in the future to access the data - there's no problems with changing binary specs etc.

Re:Why oh why XML?

[jon077]

Wait! Hold on, back up. HTML is XML, so it obviously is working for the majority of data transfers. Secondly, why would anyone give direct access to a DB? The slow connections of a DB are not suitable for presenting data to the public. I am sure many of the Web Services, extract the data, then cache it, or write it to disk, then present the same data to the world. Sure a better solution to XML may exist, but it is not reading directly from a DB. For now, Vive Le XML.

Re:Why oh why XML?

[Anonymous Coward]

XML has provided a set of rules for developing file formats. If you have ever had to sit down and think about how to make your information available to other people to use in their applications it's great. If you are dealing with semi-structured data like recipes it is ideal.

Yes it is verbose and overkill for highly structured data but until someone develops/markets a method of developing file formats that are not verbose more suited to machine transfer its the best I am aware of.

I do think we need this extensible binary formatting language or what-ever it would be, but until then XML is allowing groups of people to agree on standard file/data formats a lot quicker and easier than starting from a blank piece of paper.

Islay

Re:Why oh why XML?

[leandrod]

> HTML is XML, so it obviously is working for the majority of data transfers

HTML is not data transfer, but presentation. XML is not a data format, but text markup. Different tools for different jobs.

> why would anyone give direct access to a DB

That is not what I called for. What I said is that instead of defining a hierarchical, verbose data format, we should have database schemas, possibly ANSI SQL ones if we can't get our act together around a really relational model. Then one can define data exchange formats that will be much faster, logical, than XML-derived ones, and require far less machine processing and programming.

Perhaps you will need some background. I would recomment DBDebunk.

Re:Why oh why XML?

[csbruce]

I do think we need this extensible binary formatting language or what-ever it would be, but until then XML is allowing groups of people to agree on standard file/data formats a lot quicker and easier than starting from a blank piece of paper.

OGC (Open GIS Consortium), an organization that was involved in the development of SensorML, has also developed a open straightforward binary representation for XML documents that features the direct, raw, binary representation of arrays of numbers that makes it well suited for representing scientific data. Unfortunately, bureaucratic processes prevent me from giving you a pointer to the document (it's in the early stages of any receiving any official endorsement).

There are also some other binary encodings for XML out there that are either inadequate (WAP-XML) or which are propietary or highly complicated.

Re:Why oh why XML?

[2short]

In short, you want us all to use the same database schema definition system, because then we can create a data exchange format that's more consise than XML, and get everyone to standardise on that. Sounds great. Let me know when everyone agrees and you've got it running. Until then I guess I'll have to stick with XML. XML is pretty good for a huge number of things. For any one of these things, something else is better. I'd rather have 1 pretty good thing than a huge number of better ones.

I don't think you appreciate the wide usefulness of XML. None of the things I use it for are spoken to by your solutions.

Re:Why oh why XML?

[leandrod]

> you want us all to use the same database schema definition system, because then we can create a data exchange format that's more consise than XML, and get everyone to standardise on that. Sounds great. Let me know when everyone agrees and you've got it running.

The point is exactly that people don't know data enough. I want people to be educated; I can't bring this change about by myself. In this domain (sensors) I have no interest.

> I'd rather have 1 pretty good thing than a huge number of better ones.

If all you have is a hammer, anything looks like a nail.

> I don't think you appreciate the wide usefulness of XML.

I do. I just think XML carried us from the 50s to the 60s, that is from sheer incompatibility to hierarchical systems. We still have to arrive to the 70s, that was when the relational model was established.

Now for text markup it is lovely, I use it very much.

Re:Why oh why XML?

[Chris Burkhardt]

Wait! Hold on, back up. HTML is XML

No, XHTML is XML. HTML is an application of SGML.

http://www.w3.org/MarkUp/

Re:Why oh why XML?

[2short]

I too want people to be educated, but I don't want to have to educate them. I use XML for APIs because I can tell people "send in some XML that looks like this example, and you'll get some back that looks like this example" and they say "OK". End of conversation.

I use XML a bunch of other places too, and none of them are text markup or data storage. A relational model is great for data storage, but I can't say it's great for data interchange, because I don't even have a clear idea what that would mean.

Re:Why oh why XML?

[leandrod]

> I can tell people "send in some XML that looks like this example, and you'll get some back that looks like this example" and they say "OK"

I did the same think with simple, fixed-size fields sequential files.

> relational model is great for data storage, but I can't say it's great for data interchange, because I don't even have a clear idea what that would mean.

OK, let's step back and think; we're messing here.

Obviously the relational model is for data storage, not interchange.

And that you are restricting XML to interchange is a good thing in itself, as far as it goes.

My grip is that a simple COBOL file copy conveys as much information about data as a XML schema, and is much simpler and more efficient. Having a public relational (or SQL) schema, and then sequential file definitions for data exchange, would be richer than XML, much more efficient, and more natural for dealing with data as data, as opposed to as documents.

That said, XML does impose some structure... still it's not worth the price in going back to a hierarchical mindset and in waste.

Re:Why oh why XML?

[2short]

"I did the same think with simple, fixed-size fields sequential files"

But in my case the fields aren't fixed size, not all the records have the same fields, etc. Flat files are just not as expressive as XML without specifying a bunch of parsing logic.

A simple COBOL file copy is just as good? So I can send it down the wire, not knowing what language, OS, or whatever the other end is using, and everyone will be able to use it?

Show me a format I can reasonably expect pretty much anyone to be able to parse without their having to write any code (i.e. ask me questions about it) and I'll be interested. But I'll probably still want to sacrifice some efficiency in exchange for being human-readable.

"dealing with data as data, as opposed to as documents"

If I split off a chunk of data to send some one, it is a document.

I find XML fabulous for passing data around. I also use it for storing configuration information when I want the format to be understandable by anyone and editable by their favorite text editor. Since it's main competitor in that arena is the ini file, XMLs expressive power wins hands down.

"That said, XML does impose some structure... still it's not worth the price in going back to a hierarchical mindset and in waste"

It's not going back if people weren't that far along in the first place. XML is quickly replacing the previous paradigm of "everybody makes up their own new serialization format for every new problem and writes yet another parser; most of them are more compact than XML, but almost all of them suck in some way, particularly when they need to be expanded to handle new tasks". In a huge number of cases, the waste just isn't a problem. My 1K file is now 2K. But the format is readable, it's expandable, I can take my pick of several pre-exisitng parsers, and so can people on systems/languages I've never even heard of. If you've got some huge chunk of data, you'll want to store it in a compact and or nicely queryable format. When I give you a query with which to break off some small corner of it and send it to me, XML would be nice. When you're actually interchanging huge chunks of data, you'll want to do something different (compressed XML would be nice :-)

Re:Why oh why XML?

[cox075]

Because there is a great variety of possible sensor types, and (at least curently) we can't imagine how to force all the necessary description into a table straightjacket. This kind of application really is ideal for a semi-structured language, which is what XML Schema enables.

Re:Why oh why XML?

[leandrod]

> we can't imagine how to force all the necessary description into a table straightjacket

It doesn need to be all in one table...

Re:Why oh why XML?

[leandrod]

> in my case the fields aren't fixed size, not all the records have the same fields

The physical fields were fixed size, but you just made them as big as necessary... and you can do pretty much the same with field delimiters. Different tuple types are so simple too.

> So I can send it down the wire, not knowing what language, OS, or whatever the other end is using

You specify an encoding, and agree on the schema. That's all that XML ends up doing for data exchange, anyway, but verbosely.

> it's main competitor in that arena is the ini file, XMLs expressive power wins hands down

Not at all. You have all kinds of simple dbs, from GNU dbm to PostgreSQL; and I find /etc simple commented name/value pars much more useful than XML configuration files.

Re:Why oh why XML?

[2short]

"The physical fields were fixed size, but you just made them as big as necessary... and you can do pretty much the same with field delimiters. Different tuple types are so simple too."

Make them as big as necessary - that's not necessarily a finite value, so you're specifying some artificial limit on fields that could otherwise be as big as you want, and wasting all that space whenever the data is smaller. You can use field delimeters, and various sorts of tuples, but you have to specify all that markup, and everyone gets to write a parser. It's not that XML is the ultimate, best possible generalized markup system. It's that it's the standard one. We could invent better ones for specific tasks all day. We might even invent a better completely generalized one. But when a client calls me tommorow and wants to use my web service, is he going to have a parser for our new system already up and running? XML is verbose; it makes no bones about it. But I think a big reason it has gained such wide acceptance is because it realizes that for many tasks, ease of human readability is worth the bytes. I can't count the number of formats I've dealt with that make the data impossible to decipher without a specialized parser/viewer just to save a trivial amount of space. Particularly if you consider how small the XML gets when run through standard compression formats (many http clients/servers will do this automatically), I'll take the readability.

"You have all kinds of simple dbs, from GNU dbm to PostgreSQL; and I find /etc simple commented name/value pars much more useful than XML configuration files."

One of my requirements was that it be editable by an arbitrary users favorite text editor, which rules out the DBs, which are overkill in any case. Sometimes XML is overkill, and there I'll go for name value pairs. But there's a big area of middle ground where shoehorning stuff into name/value becomes overly cumbersome, and XML lets me get more complex structure, while staying in a readable, easily editable text file.

Re:Why oh why XML?

[cox075]

Correct. But if your multiple tables involves making choices as well as joins, then this is either equivalent to more than one Sensor language or you are on the path to inventing something with at least as much complexity as an XML-based solution. Discovery of the sensor that you want will require either joins or multi-DB queries.

One goal of SensorML is to reduce the number of entry points. The cost of this is (of necessity) a flexible document structure. Hence XML.

The SensorML discussed in the article grew out of satellite/remote-sensing apps, and is thus packed with stuff that is specialised for that area (mobile platform, non-geodetic coordinate systems, radiance and radar stuff). It is a live issue within the organisation through which it is being developed (OGC) as to whether it can be generalised to cover many more sensor types, or whether there should be multiple "SensorML"-like languages, each for a different style of instrumentation. I tend to think the latter, but hopefully the buckets will still be few and large rather than many and small, so using a semi-structured language will probably still be optimal.

Simon Cox

Web based sarcasm detector

[SpanishInquisition]

Now THAT would be useful!

Re:Web based sarcasm detector

[Dannon]

Yeah, right.

Like there's any sarcasm to be found on the web.

Feasibility of small implementations?

[dtmos]

From perusing the SensorML site, SensorML seems geared for satellite-based geosensing and other applications for which significant computing resources are available. I'm interested in small wireless sensor networks, which have very limited computing resources (usually just an 8-bit 8051 or HC08-based MCU, running at 4 to 8 MHz, with about 5k ROM and 1k RAM available). SensorML seems to have a lot of optional fields that could perhaps be eliminated for a "stripped down" version suitable for these types of sensors but, while I'm not an expert in the field, it's always been my understanding that XML=bloat. Can anyone comment on the feasibility of SensorML for small embedded applications?

Re:Feasibility of small implementations?

[Anonymous Coward]

No.

Re:Feasibility of small implementations?

[khuber]

Unless your embedded devices run web servers it probably doesn't make sense. You would just have another computer reading raw data from the embedded devices and then publishing that as SensorML instead.

-Kevin

Re:Feasibility of small implementations?

[quick_dry_3]

I did something similar as part of an embedded systems project at uni, the simple sensors probably would never ever be doing complex xml processing, just spitting out the same response over and over with little changes e.g.

Thermometer

<sensor type="thermometer" scale="celcius" value="20"/>

next reading might be

<sensor type="thermometer" scale="celcius" value="25"/>

the only bit that changes is the temp.

No doubt an awkward format for really limited 'smart' sensors, but they're probably not the ones doing processing of it - just simple response stuff with a few substituted values here and there.

Re:Feasibility of small implementations?

[Anonymous Coward]

Pretty much useless, and wasteful.

Just sensor and communication code is a tight squeeze for the ATTiny for example...

But wow, it would have XML !!! What a load of shit.

Re:Feasibility of small implementations?

[chiph]

You'd probably want that anyway. If all of a sudden, ten thousand people want to know the temperature in your backyard, an embedded CPU & webserver won't be able to keep up (slashdot effect on a micro scale). So it'd be better to have an n-tier sensor data reporting system that can scale as/when needed.

Which is not to say that the Sensor ML spec would be *bad* for that -- just that there are other issues besides the communications protocol to worry about.

Chip H.

Re:Feasibility of small implementations?

[cosyne]

There are decent ways around that verbosity- if you have a sensor net you want accessible, you're probably going through some manner of gateway already, which can be responsible for the XML encoding. There are XML compression schemes- I lost some of my links, but the one I was looking tended to get better compression on XML encoded data than normal compression on the un-encoded data, because it could rearrange and compress all of the metadata, as well as using the metadata to select optimal compressors for the data itslef. You can google for other XML comression schemes- I could put in links but i wouldn't know what I was talking about.

Since when...

[AntonyBartlett]

...was XML optimal for searchability?!

Re:Since when...

[khuber]

Since never. What about discovery? The article is full of XML hyperbole. The connection they didn't explain is that _if_ this stuff is tied into the SensorWeb, you could have those capabilities.

This article should have really been about SensorWeb since SensorML is just an implementation detail.

-Kevin

Re:Since when...

[jargon]

And because it's XML-based, it means all this data will easily be searchable

*boggle* XML doesn't exactly lend itself to searchability.

I mean, there exists XML:DB, but it is FAR from optimal for searching. Certainly not "easily searchable."

Unless, of course, they are accustomed the the data being processed being unlabeled; then I guess some standard markup might be useful.

this is too much

[thomasa]

How about talkML

this is useless nonsense to append brackets to
everything

It is just another layer of semantics

it is too hot in here, I guess the
temperature sensor
is broken

Re:this is too much

[thomasa]

missing >>>> >>>>>>>>>
>>>>>>>>>>>>>>>>>
brackets above

un requested semicolon added by mozilla

Web Services Based LabView Next?

[AlabamaMike]

Seems to me that National Instruments could use this recommendation to develop a web services based version of LabView. It'd be cool to have a loosely coupled, geographically independant sensor network that one could run experiments against. Now if we only had RemoteHandsML.

Re:Web Services Based LabView Next?

[Phronesis]

Seems to me that National Instruments could use this recommendation to develop a web services based version of LabView

They already pretty much have this, only they call it "DataSocket." Some folks at MIT have written a tutorial on how to put data on your web page using a Java DataSocket client.

Someone else has implemented a Python DSTP server and client, so you don't have to buy from NI.

Out of Office AutoReply: Well, this makes for s...

[Anonymous Coward]

Hi,

Sorry, I am not in the office at the moment.
However If you care to leave your name, quest and favorite colour after the tone I'll ignore you as soon as possible.

In my absence, please Read your F*cking Manual.

Beep.

*cheesey music*

Re:Minority Report

[fishfish]

I started thinking the same. Sounds all groovy when they say anyone could search for sensors. What if that turns into -- anyone with the right license, costly technology, etc. And how are we to decide if the people looking at these sensors are friends or foes (seems like some new bureaucracy will step in and clamp controls on access to many of these devices)?

And yet - how powerful for the public if they could go to a web site and see the water quality at the nearby beach for the past few days.

so glad that made this

[Anonymous Coward]

it's not like we have been getting sensor data off the internet for over 10 years now WITHOUT IT.

it's only a new way to do the same damn thing we have been doing at the uni's for years now...

Sheesh, is this place ran by microsoft calling an incremental achievement a REVELATION

k3wl, i can make a webpage to tell me when

[noogle]

my space cakes are ready.

Wow, lookit that!

[mwood]

They've invented...SNMP.

Re:Minority Report

[gregmac]

And yet - how powerful for the public if they could go to a web site and see the water quality at the nearby beach for the past few days.

I'm not sure that this technology is going to really do anything for this application. "The public" still likes to see fancy html pages with graphics and such. It's more likely that they'd go to their city website and navigate to find the beach conditions. I don't see many people learning about SensorML, finding a place to search for sensors, and then looking at the raw data for their beach (assuming they find it.. and can interpret the results).

Actually, thats really another thing too. There is no sensor that says "overcast", this is a condition determined by looking at a number of sensors.

Re:Well, this makes for some interesting Flash App

[sketerpot]

I don't have any examples of this, but it also seems like the sort of thing that SVG was designed for from the start. You could use XSLT or something to make SVG. Too bad it doesn't have better browser support....

Ignore Post

[Inexile2002]

Bookmarking Article for Later, ignore.

Re:Well, this makes for some interesting Flash App

[JasonKey]

No kidding. Was really hoping to see more native support within Mozilla by now, but alas, it seems to be still relatively quiet on the SVG / Mozilla front.

By the time they get around to it, I am afraid the XML generated content within Flash will overcome the in some ways.

Re:Well, this makes for some interesting Flash App

[sketerpot]

There is a natice SVG for Mozilla project, and it has some degree of SVG support, but they don't seem to have support for Phoenix (Firebird, whatever). Since the Mozilla development roadmap says that Phoenix should become the big mozilla browser, you would think that they would be trying to get it to work with phoenix.

BTW, has anybody managed to get plugin SVG to work with Phoenix?

Oh goodie....

[jemenake]

A markup language for real-time monitoring of remote events... I can see it now...

<ex-wife id=1>
<screwing>
milkman
</screwing>
</ex-wife>
<ex-wife id=2>
<screwing>
that dickhead with the Trans-Am
</screwing>
<spending>
most of my money
</spending>
</ex-wife>

Easy to add to DigiTemp

[libertynews]

It should be pretty easy to add a perl or python wrapper to DigiTemp, I'll have to look into this when I get home tonight.

bcl

Seems like they went half way

[Anonymous Coward]

Having an ML for the data is all well and good, but it's hardly a full solution. To be really useful in distributed terms, they also need to standardize a UDDI vocabulary for easy discovery/searching, and the attendant SOAP/WS interfaces for the data retrieval. This would also alleviate some of the trust issues, since the authentication/identification would be moved into the web services and DI layers.

Already been done

[mysterious_mark]

Seems like this capability has already existed with java object serialization, this is usually much more compressed than xml and does not require the significant overhead XML has for parsing.

MM

Re:Minority Report

[Anonymous Coward]

I think the poster meant the actual water quality, not the weather...like, how much feces is in the water near Coney Island today?