[
Lists Home |
Date Index |
Thread Index
]
From: Michael Champion [mailto:michael.champion@hotmail.com]
>>From: "Bullard, Claude L (Len)" <len.bullard@intergraph.com>
>>As we used to say, "way cool", or just, frikkin wow.
>This was basically the bait that got me to sell my soul to the Dark Side
:-)
>(Although nobody talked about what is now called LINQ/XLinq at my
interview,
>I could read the tea leaves that somethin' frickkin wow was in the works)
Secret decoder rings sold a lot of cracker jacks. It's hard to resist
cool tech. How many people join the military just to wear the uniform?
Lots it turns out. Do good work and hang on to your values and you'll
do fine. Remember: all they gave you was a badge and they own that
and can take it back whenever they want to. In an at-will employment
environment, there is no such thing as true love; only the legal definition
of the duty of loyalty (see tort law).
>>The evolution of the schema-aware features will be fun to watch. I want
>>to see that work with the big beasties like GJXML which attempt to
>>use naming conventions to force object-orientation.
>Thanks for the suggested use case. Any tool that can help cage that kind
of
>beast is bound to generate some interest.
Yes, and it helps to have people around like yourself who understand how
these
beasties come to be and what kind of niches they create. Lots of small
companies want to sell services as the middle guy for other technology
companies who now are faced with negotiating IEPs (information exchange
packages) with every agency. The hope is that this smooths out the wrinkles
in the State markets. I'm not a fan of outsourcing negotiations so tools
that make it possible to create a data layer from the schema are useful.
GJXDM is a data dictionary/schema. In theory, one negotiates a real
schema for the IEP. That's a lot of negotiating. It ups the cost for
each interface, and given middleNegotiators, even more cost. So getting
rid of the midNegs and getting that negotiation time down so cutovers
occur more quickly is a good thing. Global Justice is a hard use case
but at least it is very well documented. You have partners in that
business too.
>>This will make some of our developers quite happy although it is
terrifying
>>to think about how much technology we are about to throw away..
>Hmm, like what?
A lot stringing for queries. OTW, just old stuff like Foxpro apps.
>So far the internal developer experience, and my
>experience trying to balance the DOM and XLinq story at PDC, has not
>indicated that very many people look back longingly at the XML technologies
>of the previous centrury :-)
Nor should it. Too many of those techs use obscure syntax, difficult models,
incompatible models (InfoSets, namespaces, etc.) and simply, just present
a steep learning curve. What I see the *inqs doing is chopping off a big
piece of the learning curve. That is a big help. It will have some
market effects. Today companies are selling code based on the earlier
technologies which in three years will be like selling horseless carriages
just as the automobileAsBrand emerges. Early adopter risks and so on.
>No plans or promises, but I do want to hear about real
>scenarios where we might cause developer pain as people move to or
mix/match
>XLinq with other XML technologies.
It will relieve developer pain; it will make some sales guys commit suicide.
That's a .Net gain. :-)
>>What will XLinq/DLinq do with XML Binary? (had to put a troll in
>>but actually important to the sensor web community).
>That's a serialization, XLinq is a data model. XLinq shouldn't care
whether
>the bits on the wire are XML 1.0, some proprietary binary XML thingie, or
an
>eventual EXI standard. But thanks for the reminder, I'lll try to make sure
>that there's a pluggable reader/writer architecture planned for XLinq (as
>well as SAX/DOM).
Thanks. Web sensors have to get increasingly sentient and that means
smaller footprint and faster. So far that makes this tech promising.
>>I'd like to see an overview of this fit into a web services
>>scenario. I posted a reply to a CNet news article that provides
>>an example: the domain/query aware application (Kris Kringle
>>for Windows Movie Maker).
>I agree that's an important scenario, do you have a pointer to your C|Net
>reply?
http://news.com.com/5208-1014-0.html?forumID=1&threadID=11329&messageID=8428
0&start=-163
Made up on the fly based on some hobby work at home, but the essential
points are
that applications should be *sensitive* to their own application domain and
prepared
to issue queries based on it. Schema-awareness is one possibility but it
has to
be put into a task-oriented scaffold. In English, given the tasks I am
currently
doing with some application, what are some likely queries and is Microsoft
willing
to work those like Kris Kringle (send me to Gimbels if Macy's doesn't have
it in
stock or I can't afford it: of course, the top of the list is free beer).
1. Cooperating with the customer is the best way to disrupt competitors.
2. The edge of the network is where disruptive effects emerge. In a
world of mashups, the edges are the little applications used with
big applications.
So Windows Movie Maker should know that I might want to push my little
song/video to the web or to my friendly middle supplier to iTunes because
iTunes won't do business with me directly. It should be able to recommend
a source for the tools I need next, and it might do that by smartly querying
Google services or MSN services, in fact, should simply do a superQuery.
The most useful app on my machine here at work is the answers.com widget.
You still want to support the open formats. Otherwise, the application
is robbing the user of rights. It's a bad strategy over time. Trying
to find alternatives for a 22mb wmv file started my weekend quest. A
domain-aware app knows why I am asking and rather than trying to push
me to buy off the floor knows that I need a cheaper alternative and
finds it. It sends me home with a business card and sends me another
one next year to let me know if I'm ready to upgrade, the upgrade is
an even better deal than last year. In that way, the application is
managing the relationship rather than handing that off to the CRMSecretary.
len
|
