Lists Home |
Date Index |
Jeni Tennison wrote:
> The kind of model I favour is one where XPath is broken down into
> modules that can be combined when XPath is used in XQuery, XSLT, W3C
> XML Schema, XForms, XPointer, user-defined languages and so on. The
> most basic module would support only the basic axes, for example;
> other modules would build on top of it to add the support required for
> the other languages' uses of XPath.
I've been wondering for quite a long time now why that isn't compulsory
for specs that go beyond the simplistic. DOM has chapters: it's much
more manageable that way than if you had to implement all of them and at
the same time it still answers its requirements.
SVG and XHTML went the same route, and again the result is imho very
good. XForms acknowledged that
Wouldn't XML Schema be more palatable that way? It might even become a
worthy solution if one could eliminate some module to create his own
WXS-NoBloodyBrainDeadUnqualifiedLocals-mod. It wouldn't break the deal
that the WXS WG made with RSI care purveyors, but it'd already be better.
Every spec ought to have a big red "Bloat Button" which would be hit
whenever it gets too bloated. Starting from that point, knowing that a
committee will never manage to reduce requirements, a number of modules
would be created.
Robin Berjon <email@example.com>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488