[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: limits of the generic

dt parse
> >> 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 

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.
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/w


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.