Home ::About InfoWorld :: Advertise :: Subscribe :: Contact Us :: Awards
InfoWorldHomeNewsTest CenterOpinionsTechIndex
 SUBSCRIBE  E-MAIL NEWSLETTERS  WEBCASTS  SPECIAL REPORTS  RSS FEEDS
powered by Google  
 


Top 10 hits for xquery on..
Google
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

Help link
 2/22/2005; 9:14:46 PM.

Strategic Developer
wedgeUnsung heroes of open source
wedgeManagement by objects
wedgeThe network is the blog
wedgeThe semantic web, digital identity, and Internet governance
wedgeTales from the data-entry trenches
wedgeWhatever happened to SVG?
wedgeSpeech recognition circa 2004
wedgeCan rich Internet apps be web-friendly?
wedgeIntroduction to MSH
wedgeUnder Gmail's hood
wedgeThe Wiki way
wedgeComputer telephony: why wait?
wedgeMaking old technologies new
wedgeFrom access control to accountability
wedgeDoing the impossible
wedgeThe TiVo Olympics
wedgeCollaborative knowledge gardening
wedgeThe architecture of participation
wedgeA strategic vision for dynamic languages
wedgeTragedy of the network commons
wedgeFederating identity the Shibboleth way
wedgeWeb standards on the move
wedgeThe Google PC
wedgeThin client, rich data
wedgeOptical illusions
wedgeThe artful logger
wedgePush me, pull you
wedgeGoogle's supercomputer
wedgeAttack of the killer accountants
wedgeJack of all trades
wedgeProxy power
wedgeScribbling in the margins
wedgeHuman interface guidelines for the Internet
wedgeMaking email identity work

CxO bloggers
wedgeAdam Bosworth, BEA Google
wedgeChad Dickerson, InfoWorld
wedgeClemens Vasters, newtelligence AG
wedgeDave Winer, UserLand Harvard
wedgeEdwin Khodabakchian, Collaxa
wedgeEugene Belyaev, JetBrains
wedgeGraham Glass, The Mind Electric webMethods
wedgeJamie Lewis, The Burton Group
wedgeJeremy Allaire, Macromedia General Catalyst Partners
wedgeJohn McDowall, Grand Central Communications
wedgeJonathan Schwartz, Sun Microsystems
wedgeJorgen Thelin, Cape Clear Software Microsoft
wedgeKingsley Idehen, OpenLink Software
wedgeMark O'Neill, Vordel
wedgeMike Cannon-Brooks, Atlassian
wedgeOmar Javaid, Wireless Knowledge
wedgePaul Brown, FiveSight
wedgePaul Everitt, Zope Corporation Zope Europe
wedgePhil Libin, CoreStreet Technologies
wedgePhil Windley, State of Utah
wedgeRay Ozzie, Groove
wedgeRoss Mayfield, Socialtext
wedgeSean McGrath, Propylon
wedgeTim Bray, Antarctica Systems Sun
wedgeTim O'Reilly, O'Reilly and Associates

BLOG MENU
 

surf jon's tags

xpath search: this blog

xpath search: jon's feeds

blog home

blog index

infoworld home

infoworld index

library lookup

send Jon an email: Click here to send an email to the editor of this weblog.
 

 
 
 
Jon Udell's Weblog

  Tuesday, June 15, 2004 

When a journalist blogs

Jeremy Mazner is asking some great questions:

  • Q: Does a quick blog entry meet the same standards and go through the same background and vetting process as a "real" story?

    A: Many (though not all) of the items I post here are as carefully written as what goes into print. None are is 1 edited by anybody but me. None are vetted by anyone at InfoWorld, but all can be vetted by everybody who chooses to comment.

  • Q: Is a blog entry equally as obligated to represent both sides of a controversy, or is it expected to only represent the journalist's point of view?

    A: For the magazine, I write features and reviews and columns. All are expected to be fair. The story types exist along a spectrum ranging from less to more personal. The blog lives at the personal end of the spectrum.

  • Q: Are blogs supposed to be more of a conversation -- and if so, should they always have comments enabled?

    A: I think blogs can't help but be a conversation. As to comments, after years of doing Web forums and discussions, I'm experimenting with taking a break from flames and spam. I'd like to think that the blogosphere's less tightly-coupled "discussions" -- mediated by logs and search engines -- delivers better signal-to-noise with less psychic strain. That said, I do miss direct comments, I do use them selectively, and I may try renabling them.

Jeremy's questions were motivated by a series of questions I've been asking about Longhorn. This is part of a strategy I've been using -- since the pre-blog era, in fact, when my medium of choice was NNTP -- to deepen the stories I research for magazines. When the subject is not a secret, I find it extremely helpful to raise some issues publicly and invite a range of interested parties to react to them. A recent example was this entry in support of this story.

In that spirit, I owe Jeremy a response to his questions about my take on WinFS. He asks: "What is an 'XML-centric database' anyway?" A good example of the basic idea -- and the one I've been working with -- is Berkeley DB XML (which has also been adopted by the Chandler project). DB XML supports indexed XPath search, a poweful capability that's now being woven into both RDBMSs with XML support, and "native" XML databases. An even more powerful standard is XQuery, which though not a final recommendation is implemented provisionally in both conventional RDBMSs and native-XML dbs.

We have standard query languages (XPath, XQuery), and standard ways of writing schemas (XSD, Relax), and applications (Office 2003) that with herculean effort have been adapted to work with these query and schema languages, and free-text search further enhancing all this goodness. Strategically, why not build directly on top of these foundations?

Tactically, why do I want to write code like this:

public class Person
  {
  [XmlAttribute()] public string Title;
  [XmlAttribute()] public string FirstName;
  [XmlAttribute()] public string MiddleName;
  [XmlAttribute()] public string LastName;
  ....
in order to consume data like this?
<People>
  <Person
    DisplayName="Woodgrove Bank"
    IMAddress="Support@woodgrovebank.com"
    UserTile=".\user_tiles\Adventure Works.jpg">
    <EmailAddresses>
        <EmailAddress
            Type="Work"
            Address="mortgage@woodgrovebank.com"/>
        <EmailAddress
            Type="Primary"
            Address="Support@woodgrovebank.com"/>
   </EmailAddresses>

I believe two things to be true. First, we have some great XML-oriented data management technologies. Second, the ambitious goals of WinFS cannot be met solely with those technologies. I'm trying to spell out where the line is being drawn between interop and functionality, and why, and what that will mean for users, developers, and enterprises.


1 David Clarke, of CapeClear, points out that "this statement, precisely by virtue of its obvious lack of sub-editing ('are', not 'is'), re-inforces the very point it seeks to make!" Delightful! As David mentioned to me in email, there ought to be a word for this reflexive case.

 

Thin client, rich data

Current approaches to taking browsers offline typically enqueue messages that later update a server-based data model. An Alchemy application, though, always works with a genuine local data model that it stores as sets of XML fragments and navigates in a relational style. Bosworth's hunch is that a Web-style thin client, driven by a rich data model intelligently synchronized with the services cloud, could do most of what we really need -- both offline and online. Nothing prevents Java, .Net, and Flash clients from adopting the same strategy, by the way. But if Bosworth is right, the universal client that we know and love could get a new lease on life. [Full story at InfoWorld.com]

In the story as printed, this sentence:

BEA's Alchemy relies on a server component for the same reason that Macromedia's Flex does: both companies want to sell servers.
was abbreviated to this:
BEA's Alchemy relies on a server component for the same reason that Macromedia's Flex does.
Things get left on the cutting room floor, that's just life in the print medium, but I do want to restore (and expand on) the original point. Adam Bosworth is a guy who knows an awful lot about building client software -- Quattro, Paradox, Access, IE. But he is not now selling client software. Rather, he's selling infrastructure based on principles -- asynchronous coarse-grained XML messaging -- that he has forcefully and consistently evangelized. From our interview, here are some quotes that restate why such infrastructure must be:

Clustered People who build services tend to assume they don't know who's going to use them, and how often.
Metadata-driven So you can change the behavior without recompiling and redeploying the code.
Asynchronous We're still trying to convince the industry of this, but it's a lot better if you do this asynchronously, because a lot of time the thing you're trying to talk to can't respond right away, either because it wasn't written to handle the load or because the thing you're asking it to do takes time.
Intermediated The problem is that your credit approval service got bought by BFA and they consolidated the thing, so now it's a different address with a different message, and you don't want to redeploy your app. So you want everything to go through some fabric that is essentially modifiable. Call these things intermediaries, enterprise service buses, fabrics, I don't care, but you need one of these things. We've announced one called QuickSilver, BlueTitan does a nice job with this, there's Confluent...

Nothing controversial here. But there are wildly different approaches to the construction of the client-side systems that we'll attach to this infrastructure. Microsoft's Longhorn must try to extend the Windows franchise. BEA's Alchemy is free to extend the Web. This isn't an either-or deal, of course. Both strategies can succeed and co-exist. It helps, though, that the Web has found a powerful new ally.

 




 HOME  NEWS  TEST CENTER  OPINIONS  TECHINDEX   About InfoWorld :: Advertise :: Subscribe :: Contact Us :: Awards :: Events 

Copyright © 2004, Reprints, Permissions, Licensing