Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|
|||||||||
