OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XPath/XSLT 2.0 concerns

[ Lists Home | Date Index | Thread 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 <robin.berjon@expway.fr>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS