Lists Home |
Date Index |
> From: Dare Obasanjo [mailto:firstname.lastname@example.org]
> I'm sure any real cost/benefit analysis of XQuery will throw
> out most of it (especially the dense, unreadable and
> incorrect mess that is the formal semantics) and work with a
> small subset. Similar to how most best practice guides for
> W3C XML Schema and C++ encourage limiting projects to a
> useful subset.
Of course. The problem with languages and specifications conceived as
though they were the technological analog of finger food is not choosing
a subset (given a platter, any fool can pick and choose), but making
sure all the subsets usefully intersect. If there is a useful (that is,
interoperable) intersection to be found with such a specification, it
often becomes the basis for a future specification, the analog of a
square meal, whose creators will be praised for deciding what to leave
off the plate. Never trust a silver platter.
> > The fact that there are this many implementations indicates
> > that some people were willing to pay the cost of
> > implementation for the benefit they think XQuery will provide
> > to their users.
> The benefit _some_ of XQuery will provide to their users.
No, not even close. It will be the benefit various parts of XQuery and
W3C XML Schema will provide for various users. Finger food
specifications are a beggar's banquet. Unless you are the caterer.
Bill de hÓra