Lists Home |
Date Index |
- From: "Griffith, Adrian, CON, OASD(HA)/TMA" <Adrian.Griffith@tma.osd.mil>
- To: firstname.lastname@example.org
- Date: Tue, 12 Jan 1999 08:06:01 -0500
it is happening: Microsoft, IBM get XML to users
unfortunately, xml is not going to live a sexy life. it will become the
data format of choice for distributed systems, objects, and the web.
hopefully the users of microsoft products have been filling out the
"properties" form when saving a document. combine that with an xml based
search engine and viola, the data at cubicle XX is available. of course a
xml based search engine, capable of viewing information in "context" of the
> From: Rob Schoening[SMTP:email@example.com]
> Sent: Tuesday, January 12, 1999 5:25 AM
> To: David LeBlanc; firstname.lastname@example.org
> Subject: RE: XML standards coherency and so forth
> > Excuse me if they're naive.
> Not at all.
> > Firstly, the idea of xml needing a "killer app". I thought xml _is_ the
> > killer app?
> To the minds of the people reading this list, it probably is. But the
> subscription to this list isn't a good cross section of *any* population!
> XML is certainly the enabling technology for a lot of potential "killer"
> information systems. Unfortunately, it is applicable to so many different
> problem domains that it lacks the punch of a killer app. The story of
> Visicalc is that when shown to the computer geeks, they said "computers
> already do that" and when shown to accountants, they said "this is it!"
> it seems that the roles are reversed. The geeks are saying about XML,
> is it!" and the rest of the world is saying "computers can already do
> I believe that Java would have followed the same path were it not for the
> gratuitous applets that served no practical purpose whatsoever. Without
> applet, the world would have said "computers can already do that...and 10
> times faster to boot". But once you play tic tac toe on a web page, it is
> patently obvious that "computers *couldn't* already do that."
> >It sure seems to be being adopted as fast of or in advance of
> > released standards for a lot of different products (Ms Word's
> > adoptation of
> > xml in it's next release comes to mind as a non-web product).
> This is, IMHO, a really big deal. I've seen various figures that report
> of corporate data resides on the filesystem of Windows desktops in the
> of Excel and Word documents. The number of people that spend 40 hour
> creating such documents only to have them printed and filed away in the
> departmental closet is staggering. What is more staggering is that this
> fantastic information that is completely inaccessible to almost anyone
> except those who generated the data. It doesn't surprise me one bit that
> is pursuing XML as hard as they are. If that data were less opaque, the
> value of the MS products would rise significantly. If cubicle farms could
> be mined for data, that would place XML in the "this is it" category.
> > Third, about patterns etc. Um... isn't a dtd a pattern for a
> > collection/class of documents that adhere to that dtd if they are valid
> > instances of it?
> Yes, but there is no convenient way to apply logic to these collections.
> Set-building among collections of XML documents is very difficult.
> Set-building is the mainstay of corporate information systems: reports
> reports reports. XQL isn't much help either. It's great for extracting
> information from a few large documents. But it doesn't do much good for
> sifting through enormous numbers of small documents. That's great for
> SGML-ish applications, but for lightweight documents that represent
> transactions, the utility is wasted.
> > I recall when rdms' where the ugly step children due to the overhead
> > use entailed and a lack of understanding of their benefits etc. Now they
> > are the entrenched majority trying to fend off the next inovation and
> > maintain the status quo. Deja vu all over again.
> Is there a clear "threat" to the RDBMs? OO databases are maturing, but
> suffer from the same problem as I mentioned previously: reporting! Set
> processing is very difficult since the stored objects are opaque. OODBMS
> great for the OO programmer, but not so for the CIO. I can't imagine any
> system that can process sets of documents that wasn't (at the lowest
> a set-theoretic RDBMS. (Please, prove me wrong!!) I'm really interested
> see Oracle's forthcoming XML support. If XML was a neo-first-class
> for a RDBMS, I can see fantastic things to come. But if the XML data is
> stored as a blob and run through a parser to and fro, it will be a
> bust. I'm not holding my breath just yet.
> > Now, permit me to digress a bit. Having been studying and working with
> > for the last 18 months or so, it seems to me this market is
> > coming together
> > very slowly. There are not yet any decent (at least not inexpensive)
> > out for the average consumer-programmer that seem worth a darn. I
> > implemented a small xml application for a commercial product, and we
> > unable to find usable off the shelf tools at any (reasonable) cost.
> > for commercial C++ drop in parsing tools.
> I agree and I also understand that this is the responsibility of the
> and organizations represented on this list. Or perhaps we need an
> xml-app-dev list??? Or some kind of grass-roots organization that can
> affect some kind of change....
> Rob Schoening
> xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To (un)subscribe, mailto:firstname.lastname@example.org the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:email@example.com the following
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)