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] limits of the generic

[ Lists Home | Date Index | Thread Index ]

> I'd view the W3C XML Schema Datatype library as being a
> prescriptive/procedural set of data types, because they do explicitly
> specify how they should be processed. You can treat them just as
> labels if you want, of course, and use some generic data type
> processing to manipulate them. That would be like treating XSL-FO as
> just another XML markup language -- displaying a document written in
> XSL-FO as a tree rather than in the layout that the XSL-FO specifies.
> Extending the analogy, it seems to me that XQuery/XPath 2.0 is like an
> XSL-FO processor, in that it's specifically designed to be able to
> operate over a particular set of data types.

Yes.  Which is my problem with WXS, XQuery and co.

> I'm wondering how far you could get with a processor that took a more
> generic view of data types. Perhaps one where the way in which
> operations can be performed over values of particular data types was
> described in an external specification, a bit like the way you can
> define how to display an XML document using CSS. It would need to have
> some basic building-blocks that it knows how to manipulate, such as
> "number", "string" and "boolean", in the same way that CSS has some
> basic building-blocks that it knows how to display, such as "block",
> "inline" and "list-item".

This is what I've been making myself hoarse calling for.  As I mentioned, I 
hope to figure out how to propose this sort of thing for EXSLT.

> I'm thinking of something where a data type library could provide a
> formal specification of how to perform operations on a type, which the
> processor would then read and use when performing those operations.
> For example:
> <dt:datatype name="my:UKDate">
> <!-- a date in the format DD/MM/YYYY -->
> <dt:components>
>   <dt:component name="day" select="substring(., 1, 2)" />
>   <dt:component name="month" select="substring(., 4, 2)" />
>   <dt:component name="year" select="substring(., 7, 4)" />
> </dt:components>
> <dt:compare to="d"
>   select="if (#year > $d#year) then 1
>           else if (#year = $d#year) then
>             if (#month > $d#month) then 1
>             else if (#month = $d#month) then
>               if (#day > $d#day) then 1
>               else if (#day = $d#day) then 0
>               else -1
>             else -1
>           else -1" />
> ...
> </dt:datatype>

Hmm.  in my approach, the basic building blocks are simple XSLT and XPath 1.0. 
 A set of new extensions is necessary, but no new syntax.

> Of course there's always a trade-off to be made between generic
> processors and specific processors (gosh, I've even managed to make
> this email relevant to the subject line again!) but if data types are
> nothing more than labels, are really declarative, then I think that
> generic processing is a real option. Certainly one that would be
> interesting to explore.

This trade-off is why I've also been making myself hoarse calling for 
layering.  I don't object to someone plugging in one of those shiny fancy 
optimizers Jonathan is always talkign about.  I just don't want the socket for 
that optimizer to be so big and intrusive that it leaves no room for a simpler 
layer of generic processing.

Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Apache 2.0 API - http://www-106.ibm.com/developerworks/linux/library/l-apache/
Python&XML column: Tour of Python/XML - http://www.xml.com/pub/a/2002/09/18/py.
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/w


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

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