[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Paul T [mailto:pault12@pacbell.net]
> Sent: Sunday, December 30, 2001 2:16 AM
> To: Jonathan Robie; Champion, Mike; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] W3C's five new XQuery/Xpath2 working drafts -
> Still missing Updates
> > During validation, wouldn't you like the xml processor to notice that
the
> > given text is not a valid birthdate?
>
>
> Bringing types to XML, ( based on 'it looks like' ) would bring
> plenty of madness. And the service, provided by that validation layer
> is virtually not-existant. People, who do not validate their data for
> consistency before placing the data into the database can not be
> saved with a complex ( XSD is complex ) layer that 'helps' them,
This thread very clearly illustrates that there are polar opposite ways of
thinking about how to use XML in software applications. Most of us probably
live and work in the temperate zone between them, but I think it's useful to
keep in mind what the ideal types at each pole look like, and to lay out
decision rules for when one might gravitate toward one pole or the other.
Or maybe I've projected some orthogonal dimensions onto one, so it might be
fruitful to discuss other dimensions and what their "poles" look like ...
but let me get the ball rolling by describing the two poles that I see --
Strongly typed, centralized, query-oriented: "Do the right thing"; design
complex applications up front and use rigorous engineering techniques to
make everything work right. Strongly typed XML views or repositories can be
a "hub" connecting disparate databases, programming objects, and XML
documents to application developers, and these developers can use an XML
type system to catch data and programming errors early in the process. To
provide the tools powerful enough to do all this, it is critical for the W3C
to develop specs such as XSD and XQuery that incorporate the cutting edge of
the relevant academic theories and research lab experiments.
Loosely typed, loosely coupled, flow-oriented: "Interesting emergent
properties evolve"; grow complex systems from simple components and use
"gardening" techniques to kill off the bugs and weeds and rigorously prune
unwanted tendrils. XML is just "smart text", putting the information into
XML format simply allows us to "pipe" it between decoupled processes that
use XML tools look for patterns in the messages, insert new information in
the messages, and/or transform the messages to add value for some downstream
process or user. To provide the most generally useful and reliable tools to
do all this, the W3C (or some other standards organization) should focus on
making individual specs as simple, solid, and modular as possible,
continually incorporating feedback from the field to correct and clarify the
specs.
I would not begin to argue that one pole is "better" than the other. XML
owes a lot to both SGML (clearly a tool that favors up-front design, insists
on defined "document types", and generally worked best in tightly coupled
systems) and the Web (where surprising things happened when simple, modular,
loosely coupled components were connected and used in unanticipated ways).
Likewise, my employer very definitely supports both poles, from
strongly-typed XQuery to our EntireX Orchestrator dataflow
transformation/routing product with an "emerger" component to help bring
emergent properties to the surface.
So, what might the decision tree to steer someone to the "strong" pole or
the "loose" pole look like? I'll just throw out a few criteria that would
tend to point in one direction or the other, and maybe others can add to or
critique them:
Are your requirements and environments predictable and stable? -> strong
Is everything changing faster than you can cope? -> loose
Is it most important to know your system is correct? -> strong
Is it most important to know your system is flexible? -> loose
Are you importing/exporting strongly typed data? -> strong
Are you importing/exporting loosely structured data? -> loose
Can you reject input data that is not schema valid? -> strong
Can you ignore input data that you don't understand? -> loose
Are you developing with Java or C++/C#? -> strong
Are you developing with script or VB? -> loose
Do you think you should "Do the Right Thing?" no matter what? -> strong
Do you (maybe reluctantly) accept that "Worse is Better" -> loose
Do you have authority to make others do the right thing? -> strong
Are you at the mercy of folks who live by Murphy's Law? -> loose
The less easily resolved problem made clear in the recent thread is simply
that the W3C has finite resources. It can't simultaneously incorporate the
cutting edge stuff from academia in ever more powerful specs on one hand,
and iteratively standardize and clean up simple best practice from industry
on the other. I'm not so sure I have a decision tree for handling that ...
|
