[
Lists Home |
Date Index |
Thread Index
]
> >> 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@w3.org 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
|
