[
Lists Home |
Date Index |
Thread Index
]
> This clearly deserves a thread of its own ...
I think so.
> The impedance mismatch between programming objects and relational
> databases has been a serious issue for ordinary mortals for decades.
> One approach that largely failed was OODBMS;
The fact that OODBMSs failed means nothing to the potential
success or failure of native XML programming languages. A good idea
may fail due to wrong timing, but may succeed years later in a different
context.
Times are different now. This thing called the "Internet" happened in
the
meantime, and changed all the rules :-)
>
>
>> • The notion that there is an "XML data model" is silly and
>> unsupported by real-world evidence.
After spending around 8 years of my life trying to define a data model
first
for semi-structured data and then for XML, I think I have the right to
disagree.
XQuery and XSLT do have a data model that will stay at the foundation of
XML processing in the future. I think it is too late by now to deny
that.
>> I still don't understand why something like this would be silly.
>
> I guess the non-silly answer (according to
> http://www.tbray.org/ongoing/When/200x/2003/12/31/HeWantsEverything
> anyway) -- we just have to get used to the fact that programming
> languages, database systems, and data interchange formats are three
> different things and learn to work with all three comfortably and
> (presumably) build code that efficiently builds domain-specific
> mappings across them. That's quite practical advice in the short run,
> but it seems unnecessarily pessimistic over the longer term.
I don't know about other people but I personally will never
get used to such a terrible technical situation. I am stupefied every
day that programmers can peacefully implement in such conditions
and not complain.
The ability of human beings to adapt to the worst possible conditions
is,
granted, a guarantee of the survival of the specie, but otherwise a
terrible
habit. It will never stop to surprise (and upset) me to see how people
adapt
to the worst imaginable conditions and never ask:
"Isn't there a different/better way to do this !!??"
How developers can implement with their PurchaseOrders represented in
three
different ways (XML, Java/C# and tuples) and spend so much time
maintaining the consistency and writing mappings, and so much time
copying data from one format to another is a total mistery to me.
This "three legs animal" as someone called it is a technical aberration.
There are no technical reasons for things to be that way.
I don't think the situation can continue like this for a long time.
> There is
> a LOT of interesting stuff going on
> ... XL of course, but also:
>
> XQuery itself (and XSLT for that matter) are Turing-complete
> programming languages ...
> E4X http://xml.coverpages.org/ECMAScript-XML.html
> Microsoft Xen / X Omega
> http://www.microsoft-watch.com/article2/0,4248,1529588,00.asp
And there are many others of course. The main difference between
XL and Comega or ECMAscript for example is that XL advocates
for a language where the XML data models and type system are the
ONLY data models and type systems. The other two languages do ADD
XML to some existing infrastructure.
As a programmer, I do not believe in that.
XML Schema and XQuery are THAT big, and my brain is only THAT small.
I cannot mentally handle BOTH C# and XML data models in the same
time; two different kinds of strings, gazzilions of different kinds of
numerics,
all similar but DIFFERENT. My brain isn't big enough for that (and I
don't see
why it should be...)
But you are right: there are many people that want to see XML natively
supported in programming languages. It's the most natural thing, for me
at
least.
> Anyway, I certainly agree that this is not at all a silly topic.
Here are the main reasons why I believe that a new programming language
that natively
manipulates XML and it specially designed for Web Services will
eventually
emerge:
1) building Web Services today is a big pain. Unless we find a easier
way to build them,
they'll never catch on in large scale.
2) XML itself didn't catch on large scale yet either (see Jonathan's
question about why young
guys don't get excited by XML). My explanation to that is: because we
cannot DO anything
with it. Granted, we can query and transform using XSLT or XQuery, but
you have to admit
that you need a weird sense of humor to have fun querying and
transforming. Programmers
have fun programming. Or today, we cannot program with XML. Hence, no
fun for most
programmers with XML....only pain.
The day when programmers will start having fun programming with XML,
XML will really
emerge.
> It
> would be interesting to hear from the other side ...
Well, no answer yet..... :-)
Best regards,
Dana
|
