Re: limits of the generic
> 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format