[
Lists Home |
Date Index |
Thread Index
]
Title: RE: [xml-dev] XML-with-datatypes (was....)
Always pleasant to play the game with you, Michael.
<shamelessPlug>
I very much look forward to the XML Document Formats Town Hall
at XML 2005 next month when some of these same issues may
come up for community gnashing and tearing.
</shamelessPlug>
XSD *IS* a layered approach. Rather than welding datatypes into
XML, they are bolted into the application layer. I think that a
much better approach than to attempt to make an object-oriented
programming language out of XML itself. IOW, I've no problem
with multiple schema application languages that include datatypes
even if bewildering to the application programmer; I've objections
to refactoring XML to weld strong-typing to it.
As far as the Evil Empire stuff goes, I will post something to
my blog tonight about the competencies of evil, rewards to be
had, and how Balmer could better advance his hegemonic agendas. :-)
len
From: Michael Champion [mailto:michaelc.champion@gmail.com]
On 10/13/05, Bullard, Claude L (Len) <len.bullard@intergraph.com> wrote:
>
>
> Every semantic level added to XML that closes it to other
> applications reserves the future to the deep pockets of
> corporations and global shareholders. What you
> offer as a minor version increment is a very large step into
> the past when such events not only went unnoticed, they
> were expected and applauded. For the last decade,
> the openness of web technologies and web standards provided
> a short breath of freedom that has resulted in innovation
> and prosperity at unimagined scale.
>
> You would give it up to make it two groats easier to
> spot bugs earlier. Don't be too surprised if the applause
> from the bleachers here is muted for the moment.
As much as I agree with the general assessment of how XSD turned out,
I don't see it as the first step on the road to Apocalypse. The way I
have come to see it -- after several years in the service of an
enterprise-focused mainframe-funded company and almost a year in the
Evil Empire (tm) -- the typical developer who is not an XML geek hits
a brick wall when confronted by untyped XML data. (OK, unless it is
human-oriented text that just needs to be run thru a stylesheet and
shown to the user, of course). XSD has few loyal friends in the
trenches AFAIK, but the idea of having to deal with the hassles of
comparing dates, floats, etc. as strings, or tediously converting them
to programming language datatypes one by one, and learning XPath/XSLT
in order to handle arbitrary variations in data structure, is even
worse. In my heart of hearts I think they would be better off if they
*did* learn all this wonderful, open, XML stuff, but the fact seems to
be that they would prefer to just map it to objects as quickly as
possible. "It's a price in an invoice, don't make me deal with it as
a node in a tree!!" is their complaint against untyped XML. By binding
to objects, they get the benefits of XML
(vendor/platform/application-neutrality, the network effect, etc.)
without the costs of diving into all the confusion and complexity that
we somewhat happily wallow in.
My colleague Erik Meijer prostelytizes what *I* think the overall
trend in both programs and data is going to be: "static typing where
possible, dynamic typing where necessary." In the short run, W3C XSD
plays a possibly lamentable but undeniably practical role in this.
In the long run it would be nice to refactor or replace the &*^%
thing, but those who would do so need to understand the very real use
cases to which it is being applied, and not just wish that they would
go away.
|
