[
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.
html
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/w
ebservices/library/ws-pyth10.html
|
