Re: limits of the generic
> >> 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. > > I didn't want to frighten Jonathan off with XSLT syntax for doing the > comparison function. As for the component-referencing, what were you > intending? I guess that a tree structure would be another option, > something like: > > <dt:parse> > <day><xsl:value-of select="substring(., 1, 2)" /></day> > <month><xsl:value-of select="substring(., 4, 2)" /></month> > <year><xsl:value-of select="substring(., 7, 4)" /></year> > </dt:parse> > > <dt:compare> > <xsl:param name="d1" /> > <xsl:param name="d2" /> > <xsl:variable name="result"> > <xsl:choose> > <xsl:when test="$d1/year > $d2/year">1</xsl:when> > <xsl:when test="$d1/year = $d2/year"> > <xsl:choose> > <xsl:when test="$d1/month > $d2/month">1</xsl:when> > <xsl:when test="$d1/month = $d2/month"> > <xsl:choose> > <xsl:when test="$d1/day > $d2/day">1</xsl:when> > <xsl:when test="$d1/day = $d2/day">0</xsl:when> > <xsl:otherwise>-1</xsl:otherwise> > </xsl:choose> > </xsl:when> > <xsl:otherwise>-1</xsl:otherwise> > </xsl:choose> > </xsl:when> > <xsl:otherwise>-1</xsl:otherwise> > </xsl:choose> > </xsl:variable> > <xsl:result select="number($result)" /> > </dt:compare> This seems to indicate that I didn't understand what you meant in your first message. I don't want a new template language for defining DT operations. Nor do I want to overload XSLT to this task. Why do we need such a language-neutral language, anyway? All I want is a simple means of mapping lexical values to host language stubs, and a means of naming the operations for operating on the resulting value spaces. The basic building blocks I mean in XPath and XSLT are simply FunctionCall and the related extension mechanisms. Maybe one could find a useful way to take advantage of the pattern matching infrastructure as well. > >> 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. > > I think that maybe from the optimiser's point of view, they don't want > to have to switch context into some XSLT/XQuery function definition > in order to know how to test whether two numbers are equal to each > other. But then again I don't see any problem with processors that > choose to build-in support for the W3C XML Schema data types rather > than relying on external user definitions. I don't have a problem with this either. TCP/IP and HTTP are separate specs with distinct layers. I don't have a problem with TCP/IP processors building in HTTP support (for instance, tcpdump can stitch HTTP packets together in a friendly way for the user). The key thing is that the base specifications are properly layered. > Plus (a) of course these implementations are going to have to look at > some external data type definitions *anyway* -- those defined by the > user in whatever schema they're using and (b) something along these > lines would be a nice way to support custom collations. > > By the way, I know that you're hoarse, but shouting in the direction > of public-qt-comments@w... is probably the best way to prompt > changes. Apologies if you've already sent this suggestion there and I > missed it. You're right, of course. I have been hoping to sharpen my thoughts and have a strong counter-proposal. If I get around to the EXSLT proposal, this would help. So far, I've just resigned myself to ignoring XPath 2.0, XSLT 2.0 and XQuery. -- 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